Response times are the least important part. What matters is who sets priority, when the clock pauses, and what a resolution is defined as.
Service level agreements get negotiated on the response time, which is the number on the front page and the easiest thing to compare. It is also close to the least important term in the document.
A thirty-minute response commitment is worth very little if the provider decides what counts as a priority one, if the clock pauses whenever they ask you a question, and if "resolved" includes telling you to restart your computer. All three of those are standard in agreements that look fine.
The same clause, two ways
Going through those in order of how much they matter.
Who sets the priority
The single most important term. If the provider classifies incidents, then every commitment in the document is contingent on their judgement, and when the service desk is busy, judgement moves.
What to ask for instead: priority defined by business impact, in a table, agreed in advance. Something like:
Priority 1 is a complete outage of a service used by the whole business, or any issue stopping revenue. Named examples: email down, the line-of-business system unavailable, the office with no connectivity.
Priority 2 is a service degraded or a whole team unable to work.
Priority 3 is an individual unable to work.
Priority 4 is everything else, including requests.
Name your actual systems in the table. A generic definition will be interpreted; a table naming your ERP will not.
Add one line giving you the right to escalate a priority, with the provider able to query it afterwards rather than refuse it at the time. In an emergency the argument should happen later.
When the clock runs
Two sub-clauses, both routinely abused and neither contentious once raised.
Start. When the ticket is logged, not when it is triaged, assigned or read. Automated acknowledgement does not stop the response clock.
Pause. Most agreements pause the clock while awaiting customer information, which is reasonable in principle. It becomes unreasonable when any question pauses it, including questions the provider could answer themselves.
Reasonable wording: the clock pauses only when the provider has requested specific information without which work cannot continue, and resumes on receipt. Not "pending customer response".
What counts as resolved
If this is undefined, a ticket closed with a workaround counts as a resolution, and your resolution statistics will look excellent while the same issue recurs weekly.
Define two states. A workaround restores service with the underlying cause unaddressed; it stops the resolution clock and opens a problem record. A resolution means the cause has been addressed and the issue should not recur.
Then ask for repeat-ticket reporting, which is the number that reveals whether resolutions are real. We wrote about why in the metrics worth watching.
Definitions to nail down
Two in that list deserve a note.
Business hours. Specify them, specify the timezone, specify public holidays, and specify what out-of-hours support costs and how it is invoked. A nine-to-five contract is correct for many businesses. What is not correct is discovering the boundary at 5.45pm during an outage.
Availability measured excluding all planned work. A service with ninety-nine point nine percent availability excluding planned maintenance, where planned maintenance is whatever the provider schedules, is a service with no availability commitment. Scheduled work should mean work scheduled in windows agreed with you.
Remedies, which are mostly symbolic and still worth having
Service credits in IT agreements are typically small, often a percentage of one month's fee. They will not compensate you for a bad outage and they are not meant to.
Ask for them anyway, for two reasons. A credit makes the target real: a commitment with no consequence is an aspiration, and providers behave differently when a miss has a cost, however modest. And a pattern of credits is evidence if you ever need to argue for termination.
Pair the credit with a reporting obligation, which matters more: when a target is missed, the provider tells you, with an explanation, rather than you discovering it in a quarterly summary.
Reporting
Monthly, with the raw ticket data available on request. Three things on the report:
Volume and trend, tickets per user. Every missed target, with the reason. The top repeating issue and what is being done about it.
A report that is a page of green percentages is a report designed not to prompt questions.
What is reasonable to concede
Negotiating every clause to your advantage produces either a refusal or a price increase, so it helps to know what to let go.
Concede on the credit amount. It is symbolic; fight for its existence rather than its size. Concede on exclusions for genuine third-party outages, since the provider cannot fix Microsoft. Concede on reasonable force majeure.
Hold firm on who sets priority, when the clock pauses, the definition of resolution, and access to the underlying data. Those four determine whether the rest of the document means anything.
Finally, read the termination clause
It is not part of the SLA and it is the clause you will care about most if the relationship goes wrong. Notice period, what happens to your data, what transition assistance is provided and at what cost, and whether you have administrative access to your own systems throughout.
A provider who holds the only administrative credentials for your tenant has leverage that no service level commitment offsets.
