Managed service agreements are usually judged on price and response times, and those are the two clauses least likely to cause problems. The disputes that damage relationships come from things left undefined: whose fault an outage was, who owns a change nobody asked for, and what happens to the documentation when the contract ends. This article covers what to define, and how.
Define priorities before response times
A response time means nothing without a priority scheme that both sides apply the same way. Define three or four priority levels in terms of business impact, with examples from your own operation:
- Priority 1. A system that the business depends on is unavailable or unusable for most users, with no workaround. Example: order processing is down.
- Priority 2. A major function is degraded or a significant group of users is affected, with a workaround that is costly to sustain. Example: invoices can be produced but not sent automatically.
- Priority 3. A fault affects a small group or a non-critical function, with an acceptable workaround.
- Priority 4. Requests for information, minor changes and cosmetic issues.
Agree who sets the priority when a ticket is raised, and how it can be challenged. Most disputes about response times are really disputes about priority.
Response, update and resolution are different measures
Response time is how quickly a qualified person acknowledges the incident and begins work. Update frequency is how often you hear about progress. Resolution target is when the service is expected to be restored, which may involve a workaround with the underlying fix scheduled later.
Providers can commit firmly to response and update times because they control them. Resolution depends on the nature of the fault and on third parties, so it is usually a target rather than a guarantee. An agreement that promises guaranteed resolution times for every incident is either priced for the worst case or not going to be honoured; both are worth avoiding.
Coverage hours and escalation
State the hours during which each response time applies, and what happens outside them. Business-hours coverage with an on-call route for priority 1 incidents is the most common arrangement for medium-sized businesses and is much less expensive than full 24/7 operation. Whatever is agreed, the escalation path should name roles on both sides, with the contact details kept current as part of the monthly review.
A responsibility matrix, not a paragraph
The most valuable page in a managed service agreement is a table listing every recurring activity and who is responsible for it. Typical rows:
- Monitoring and alert handling
- Patching of operating systems, platforms and application dependencies
- Backup, restore testing and retention
- User account administration and access reviews
- Change requests and small enhancements
- Third-party supplier management for licences and infrastructure
- Security incident response and notification
- Documentation and runbook maintenance
- Reporting and service reviews
For each row, record who performs it, who approves it and who is informed. Where responsibility sits with your own team or with another supplier, say so explicitly; the gaps between suppliers are where incidents fall.
Changes and the improvement backlog
Distinguish between support, which restores the agreed service, and change, which alters it. Small changes can be covered by an allowance of hours per month; larger ones need a short estimate and approval. Keep a single improvement backlog, reviewed monthly, that turns incident trends and user feedback into prioritised changes. Without it, the service stays static while the business moves.
Reporting that supports decisions
A monthly report should be short enough to read and specific enough to act on: incidents by priority with response and resolution performance, changes completed, risks identified, upcoming renewals or end-of-support dates, and the state of the backlog. Review it in a meeting with the people who can make decisions, not just those who raise tickets.
Security obligations
State how security incidents are classified, how quickly you will be notified, and what the provider will do in the first hours. Specify access controls for provider staff, how credentials are stored and rotated, and how access is removed when people leave the engagement. If your organisation is within scope of regulations such as NIS2 or sector-specific rules, the agreement should give you the documentation and notification support you need to meet your own obligations.
Exit terms: the clause everyone skips
Every managed service ends eventually, through insourcing, a change of supplier or a change of system. Agreements that do not plan for this end badly. Define before signing:
- Ownership. Source code, infrastructure definitions, documentation, runbooks and configuration are yours, held in repositories you control, from day one.
- Credentials. Administrative access is issued from your identity provider or your cloud accounts, so it can be revoked without the provider's cooperation.
- Handover. A defined transition period, typically one to three months, during which the provider documents anything missing, shadows the incoming team and answers questions, at agreed rates.
- Data. How operational data such as ticket history and monitoring configuration is exported, and in what format.
A provider that agrees readily to these terms is confident in the quality of its work. Hesitation is informative.
Keep it proportionate
None of this requires a long contract. A schedule of a few pages covering priorities, response and update times, coverage hours, the responsibility matrix, the change process, reporting, security obligations and exit terms will prevent most of the disagreements that damage managed service relationships. The time to write it is before the first incident.