Managed Services Engagement
Running systems already live, measured on self-detection rate and repeat incidents rather than on ticket volume or uptime alone.
| How it is bought | Monthly recurring |
| Duration | 12-month term, 30 days notice after month 3 |
| Written for | Organisations running production workloads without a platform team, or with one that is stretched |
Cloud estates degrade quietly. Cost creeps, patches slip, and nobody notices until the invoice or the incident.
What you receive
Named artifacts, not activities. If one of these is not delivered, the engagement is not complete.
- Monitoring and alerting we operate, with a named engineer who knows your estate
- Patching and update management against an agreed window
- Cost management: monthly review, rightsizing recommendations, and commitment planning
- Incident response to the severity targets in our published SLA
- A monthly report that states what changed, what it cost and what we recommend next
How it runs
- Month 1 is onboarding: inventory, access, runbooks and baseline. Steady state begins in month 2.
- Monthly review with the same engineer, not a rotating queue.
What this deliberately does not include
Published with the same prominence as the deliverables. A scope with no stated exclusions is a scope that will be argued about later, and the argument always happens at the worst possible moment.
- Application development and application-level support.
- Anything outside the agreed estate, which is listed by name in the order.
- Emergency work arising from changes made without telling us, which is billed separately and charged at cost.
How you know it is finished
Response and resolution against the published SLA, and a monthly report you can hand to a CFO.
What you need ready
An inventory of what is in scope, appropriately scoped access, and a named person on your side.
Every engagement starts with a written scope confirmation before any invoice is raised. Nothing here is a click-to-buy: we confirm what you need, agree the scope in writing, then invoice. If the scoping conversation shows that a smaller engagement, or none at all, is the right answer, we say so before anything is signed.
Request this engagement Talk it through first Read the SLA before you commit
Most managed service arrangements are measured on responsiveness. Tickets answered, uptime reported, an SLA met. All of it can be true while the same problem recurs every month and nobody is fixing the cause.
This is measured on whether problems get found before your customers find them, and whether they stop coming back.
What we run#
Applications, infrastructure and AI systems already in production. Monitoring, incident response, capacity and cost management, patching and the routine work that keeps something dependable.
How it is measured#
| Measure | Why this one |
|---|---|
| Self-detection rate | Share of incidents found by monitoring rather than by your users. This is the number that says whether any of it is real |
| Time to restore | Detection to service restored |
| Repeat incidents in 30 days | Restoring without fixing the cause. An automated restart is very good at hiding this |
| Cost per unit of load | Not total spend, which can fall while efficiency worsens |
| Alert-to-action ratio | Above roughly 5:1 the team has learned to ignore the channel, and the next real alert dies there |
Uptime alone is not on this list. A service can be up and serving errors, up and taking nine seconds, or up and returning stale data to everybody.
Automated remediation, and its limits#
Routine fixes run without waking anyone, from a named allowlist: restart a failed stateless service, clear a known-safe temporary directory, scale within a ceiling you set, fail over to a healthy standby.
Three rules on that list, and we will not relax them:
- Every automated action is logged with its trigger.
- Anything firing more than twice in an hour stops and escalates, because a remediation in a loop is masking the fault rather than fixing it.
- Nothing that deletes data, changes access or security posture, rolls back a release, or spends beyond your ceiling happens without a person.
What you keep#
Visibility into everything: the monitoring, the runbooks, the incident records and the automation list. No part of the arrangement depends on us being the only ones who understand it, and the handover if you take it in-house is a documented process rather than a negotiation.
What we will not do#
- Report uptime as the headline and leave detection unmeasured.
- Close an incident without a cause and a test, or at least an honest "cause unknown, here is what we are watching".
- Automate a fix into a control we do not understand well enough to reverse.
How we work, in public#
Our operations model is published, including the KPIs, the procedures and the remediation allowlist template with its four entry tests: bounded, reversible, observable and rate limited.
Get in touch with what is currently keeping someone awake.
What else is coming for Managed Cloud
The engagement Ready
What it produces and how it runs.