Day-to-day operation of the enterprise systems you depend on, including ones we did not build: maintenance, incidents, monitoring and steady improvement, under service levels agreed in contract.
The system runs payroll, or orders, or the nightly reconciliation, and it has outlived the team that built it. Three people share the on-call schedule, and one of them is on vacation. Alerts go to a channel everyone has muted, and the only person who knows why the overnight job fails wrote it years ago. Nobody planned this. Keeping a system like that healthy is a real job, and it needs people for whom it is the job.
They are listed separately because agreements name them separately. In practice they feed each other: the incident that keeps returning is a problem, and fixing the problem is usually an enhancement.
Bug fixes, patches, dependency and runtime upgrades, certificate renewals, and the user questions that turn out to be defects. Tested and released through your pipeline, in your accounts, within the windows you allow.
Service is restored first and explained second, with a timeline and, where one can be found, a root cause. Recurring incidents become problems with an owner. AI helps sift old tickets for a shared cause; an engineer confirms it.
Hours of cover, response and resolution targets, and escalation paths are written into the contract, system by system, along with how and how often performance against them is reported, misses included.
The agreement covers change as well as upkeep: the report finance keeps asking for, the slow screen, the manual step behind a recurring ticket. You set the order, and we keep the list moving.
Alerts tuned to what matters to the business, dashboards someone actually reads, and the routine work around them: batch jobs checked, backups restored on test, capacity and cost reported. Most bad nights start as a signal somebody scrolled past.
Who built the system matters less than what is known about it. Before we take one over, four things have to be written down: what the system does, what an ordinary day looks like, what has failed before and how it was fixed, and who can approve a change at 3 a.m. Usually at least two of them are missing, and finding them is the first part of the work.
That transition is real work, planned and scoped as part of the engagement rather than treated as a formality before the real contract begins. We sit with the people who take the calls today, read past alerts and outages, and write down the failure patterns they know from experience. Taking over an undocumented system is how a support contract turns into an argument about whose fault an outage was.
Responsibility moves in stages, and at each stage both sides can see who holds it. Nothing is assumed: when service levels take effect is agreed in the contract, and the runbooks they rely on are written first.
We read the code, the configuration, the tickets and the outage history, and interview the people who keep the system alive today. You receive a written picture of the system, its known failure patterns, and the gaps nobody could fill.
Our engineers watch your team handle real incidents and releases before touching anything themselves. Every undocumented step they see becomes a runbook entry. You review the runbooks and the alert list before anything changes hands.
Responsibility moves system by system, with an overlap agreed with your team. Service levels apply from the point the contract sets, against the runbooks just written. Every incident and change is visible in your own ticketing system.
The work settles into a regular rhythm agreed with you: incidents reviewed, problems scheduled for repair, enhancements prioritized together. Reports cover what failed, what changed, what it cost, and which trends point to the next problem.
| Scope | What we do | Your decision |
|---|---|---|
| Service levels | Meet agreed cover, response and resolution targets | Which systems justify after-hours cover |
| Monitoring and alerting | Tune alerts, watch dashboards, check batch jobs | What counts as business-critical |
| Incidents and problems | Restore, escalate, find and fix root causes | Approval of customer communication |
| Maintenance and patching | Test and apply updates in your accounts | The windows we may use |
| Backup and recovery | Run restore tests and prove they work | How much data loss is acceptable |
| Enhancement requests | Estimate, build and release through your pipeline | Priorities and the release calendar |
Yes. That is what this service is designed for. The condition is the transition: we document the system before we take responsibility for it, and the contract sets when service levels begin. If it turns out the system needs modernizing rather than maintaining, we will say so, but that becomes a separate decision, not something quietly absorbed into the support budget.
Describe the problem in a paragraph and we will tell you which service applies.
