Run
Managed Operations
Monitoring, incident handling, maintenance, agreed improvement capacity, and a monthly benefits report your CFO can audit.
The buyer problem
The build finished, everyone moved on, and now nobody is watching.
Automation does not fail loudly. It drifts. A vendor changes a field name and a sync starts skipping rows. A model that classified inbound correctly in March gets a new kind of message in July and quietly routes it wrong. An exception queue that used to hold four items holds four hundred, and the person who would have noticed left in May. Six weeks pass. Then a customer calls.
There is a second version of this where nothing breaks and the value still leaks away. The workflow was right for last year's volume. Nobody has the time or the mandate to improve it, so a system that was worth $300,000 a year on the day it shipped is worth $180,000 two years later and no one can say when that happened.
And there is a third version, the expensive one. The monthly report says everything is fine. Nobody checks whether the report is measuring the thing it claims to measure.
Conditions for fit
This is for you if
- Something we built, or something you own, is running in production and carries real volume.
- A named process owner exists on your side. We monitor and maintain; we do not become the owner.
- You want the benefit reported monthly in a form your CFO can check, not asserted in a quarterly slide.
- You have improvement work with nowhere to go. Your team is fully consumed running the business.
- The scope is one of our three workflow families.
This is not for you if
- You are looking for general IT support, a help desk, or security operations. That is an MSP and you likely already have one. We stay in the workflow layer and will work alongside them rather than compete for the same ticket.
We decline work that cannot clear its own benefit hurdle. If the arithmetic on your workflow does not show a return worth the fee, the answer is no, and you get that answer before you spend anything.
The questions we ask first
The diagnostic opens on these, in this order, before anything is proposed. If the answers do not exist, that is itself the finding.
- What is running in production today, and who watches it?
- What would break first, and how would you find out?
- What is the actual cost of an hour of downtime on this workflow?
- What improvement work is sitting in a list that nobody has time for?
- What does your leadership team want to see monthly, and what do they act on?
- Who is on call today, and is that written down anywhere?
- What did the last incident cost, and what changed afterwards?
- What third-party consumption does this run on, and who watches that bill?
- Which changes may we make alone, and which need your sign-off?
- If we stopped tomorrow, could you keep it running? That answer should be yes, and we will tell you what it takes to get there.
Deliverables
Monitoring on the workflow, not just the server
Uptime is table stakes and it is not the question. We watch queue depth, exception rate, throughput, time-in-stage, and the quality of the output -- each with a threshold, each with a named person alerted.
Incident handling
With an agreed response window, a defined escalation path, and a written post-incident note that says what happened, what it cost and what changed. No incident closes without the last part.
Maintenance
Vendor API changes, schema drift, credential rotation, dependency updates, and the small repairs that stop a working system from decaying.
Improvement capacity in hours
Agreed up front and reported against. Not a vague promise of continuous improvement -- a number of hours a month, and a monthly conversation about where they go.
A monthly operating review
What the workflow did, what broke, what we fixed, what we improved, and what we recommend next. One hour, with the process owner in the room.
A monthly benefits report
In four separate buckets, never summed into one headline number: 1. Incremental contribution profit. 2. Actual cash costs removed. 3. Capacity released, in hours, converted to dollars only where a role was actually eliminated or a hire actually avoided. 4. Cash timing, in days and working-capital effect. Our fees are subtracted so you see net. Every figure carries its baseline dates, its comparison dates, volume and mix adjustments, additional operating costs, attribution strength and known limits, and a link to the evidence. It is designed to be handed to your finance lead for checking, because eventually it will be.
Data export and exit assistance
Defined and priced before you sign rather than negotiated when you leave.
Implementation steps
- Transition
We inherit the runbook, the monitoring, the thresholds and the owner map from the build -- or write them if what you have was built elsewhere. Nothing goes under coverage until we can describe how it fails.
- Instrument
Alerts on the measures that matter, tuned so that an alert means something. An alarm everyone ignores is worse than no alarm, because it makes the silence look safe.
- Run the rhythm
Daily health check, weekly exception review with the process owner, monthly operating review and benefits report, quarterly look at whether the workflow is still the right shape.
- Handle incidents
Detect, contain, restore, then write it down. The post-incident note is short and it is not optional.
- Spend the improvement hours
Agreed monthly with the process owner, reported against, unused hours handled as the agreement says rather than quietly absorbed.
Example measures
Examples of what gets instrumented. Each row is a definition: what gets counted, the unit and the period it is counted over, and the system that holds the authoritative figure. A number without those three is not a measure. The figures come from your baseline, measured on your data.
| Measure | Unit and period | Authoritative source |
|---|---|---|
| Workflow availability and successful completion rate | Percent, per month | Monitoring checks and execution events |
| Time to detect and time to restore | Minutes, per incident | Alert and incident timestamps |
| Exception backlog, and its age | Count and age in days -- the age matters more than the count | Exception queue in the system of record |
| Quality sampling on automated decisions | Percent correct, at an agreed sampling rate | Sampled decisions reviewed with the process owner |
| Throughput and time-in-stage against the original baseline | Cases per period; median hours per stage | Status-transition timestamps, same definition as the baseline |
| Running cost, including third-party consumption | Dollars, trended monthly | Vendor usage records, reconciled to the invoice |
| Improvement hours delivered against hours agreed | Hours per month | Time records, reported against the agreement |
| Net measured benefit after our fees | Four separate buckets, per month | Monthly benefits report, checked with your finance lead |
Dependencies
What has to be true on your side. If one of these is missing, the engagement stalls and we will say so before it starts.
- The named process owner, still named. If we cannot identify that person, the coverage is not doing what you are paying for and we will raise it rather than keep invoicing quietly.
- Access that survives. Credentials that are rotated with notice rather than expiring at 2am.
- A decision on the change boundary. What we may fix alone, and what waits for you.
- Someone available during an incident on your side for business decisions we are not entitled to make.
- Visibility of your own changes. If your team changes the CRM on a Thursday, we need to know on the Thursday.
- An hour a month from the process owner for the review. If it is skipped three months running, we treat the engagement as at risk and say so.
Limitations
What this work does not do. On the page, not in a footnote.
- We are not your IT department and not your security operations team. We do not manage endpoints, networks or identity, and we do not provide a general help desk.
- We monitor and maintain the workflow. We do not take over responsibility for your operation, and we will not accept an arrangement that makes us the only people who understand how your business runs. If you asked us to leave, you should be able to keep running. Getting you to that state is part of the service, not a threat to it.
- Availability targets in an agreement are commitments we make, not performance we have already measured on your workflow. We will not dress a contractual promise up as a result.
- Benefit measured monthly still carries attribution limits. Seasonality, headcount, pricing and marketing all move at the same time as we do. We normalise what we can, disclose what we cannot, and never claim a number that is not traceable.
The engagement path
- A baseline comes first. Coverage follows a build, and a build follows a baseline. If something is already running and you want it watched, the first step is still a short diagnostic, so that we can describe how it fails before we promise to catch it.
- Then the build, or the transition into coverage. Coverage starts on a workflow whose runbook, monitoring, thresholds and owner map exist -- written during the build, or written by us first when it was built elsewhere.
- Pick a coverage level. These are alternatives, not stages. Managed Lite -- $3,500-$6,000/mo: monitoring, maintenance, quarterly review. Managed Essential -- $10,000/mo: defined coverage, monitoring, maintenance, monthly operating review. Managed Growth -- $20,000/mo: broader coverage plus agreed improvement capacity. Managed Transformation -- $30,000/mo+: multi-function program, reserved capacity, governance.
- Then the agreement. It specifies included software and usage, third-party consumption and overages, support windows, improvement capacity in hours, response expectations and the escalation path. Those are the terms an argument turns on later, so they go in writing in month zero.
- Coverage begins. The first benefits report lands at the end of the first full month, and the reviews run to the cadence the agreement sets.