Managed Services
Most support contracts are priced on ticket volume or headcount, which quietly pays the vendor for the problem to persist. Worth understanding how yours is structured before asking why the same incident keeps recurring.
Incentives decide whether support improves anything
A team paid per ticket has no reason to eliminate the ticket. A team paid for a fixed roster has no reason to reduce the roster. Neither is dishonest; both produce operations that stay busy and never get better, because the arrangement rewards throughput rather than the absence of work.
We would rather agree what good looks like — incident rate, time to recovery, change failure rate — and be measured on it. That makes eliminating a recurring failure our problem rather than a reduction in our billing, and it makes the numbers a shared artefact instead of something we report about ourselves.
What we operate
Application support
Owning running software, including systems we did not build. Starts with reconstructing how it actually works, since that is usually undocumented.
Cloud operations
Infrastructure, scaling and platform maintenance across AWS, Azure and GCP, with changes made through pipelines rather than by hand in a console.
On-call and incident response
A rotation with defined severities and escalation. Every significant incident gets a written review that names causes rather than people.
Patching and upgrades
Dependency and runtime currency handled continuously. Deferred upgrades do not disappear; they turn into a forced migration at the worst possible moment.
Cost management
Finding and removing the spend nobody owns — idle environments, oversized instances, storage tiers nobody revisited since launch.
Monitoring that means something
Alerts tied to user-visible symptoms rather than to every metric a dashboard can emit. An alert nobody acts on is training people to ignore alerts.
How an engagement runs
Take inventory of the pain
Six months of tickets and incidents, sorted by what actually recurs. The top five causes are usually responsible for most of the volume, and most of them are fixable.
Stabilise before optimising
Alerting that works, runbooks for the top failure modes, an on-call rota that a human can sustain. Nothing clever until the basics stop waking people up.
Fix causes on a standing budget
A fixed share of capacity goes to prevention every month. Without it, support contracts settle into a comfortable equilibrium where the vendor is paid for the problem to continue.
Review incidents in writing
Shared, blameless, focused on cause. An incident that produces no written change to the system was a cost with no return.
Report on what improved
Ticket volume by cause, time to restore, and what changed. If the trend is flat after two quarters, that is a conversation, not a renewal.
What you are left with
Current runbooks
In your repository, updated as part of the work, usable by someone who is not us.
Working alerting
Tuned to reach a person who can act, with the noisy alerts deleted rather than muted.
Incident record
Written reviews with causes and follow-up actions that have owners and dates.
A declining ticket trend
Or an explanation of why it is not declining, which is the more useful conversation.
What we ask for in return
Operating software well needs authority to change it. A support arrangement where the vendor can restart a service but cannot fix the bug causing the restarts produces exactly the treadmill both sides complain about.
So we ask for the ability to raise and ship fixes, and a budgeted share of capacity spent on reducing future work rather than servicing today's. Without that second thing, an operations engagement only ever absorbs load.
- Agreed severity levels and response targets, in writing
- Written incident reviews, shared, focused on cause
- A standing share of capacity for prevention, not just response
- Access to fix root causes, not only to restart things
- Runbooks kept current in your repository, so you can leave
When not to hire us
We do not price support by ticket volume or by headcount. Both quietly pay us for your problems to persist, and we would rather not have that incentive in the room.
If what you want is a rota of hands to restart things and close tickets without touching root causes, another provider will do it cheaper. We are only useful where we are allowed to fix what keeps breaking.
Common questions
Yes, and it is a large part of this work. It starts with a discovery period to establish how the system behaves, what its failure modes are, and what is undocumented — before we accept an availability target. Committing to numbers for a system we have not read would be guessing.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.