An IT support proposal says “one-hour response for critical incidents.” That sounds reassuring, until the office internet goes down at 4:45 pm and you discover the provider’s support clock stops at five.
Service-level agreements (SLAs) are useful, but only when the terms match how your business actually operates.
Response, workaround and resolution are different promises
A response target usually measures how quickly the support team acknowledges or begins working on a request. A workaround gets people moving again, perhaps by switching to a backup connection. Resolution means the underlying issue has been fixed.
These milestones should not be used interchangeably. A provider can meet a 30-minute response target and still need a day or longer to resolve a hardware failure, particularly where a replacement part must be ordered.
Check how priorities are decided
A sensible priority system considers both impact and urgency. One person’s browser problem is different from an outage affecting the whole company. But a problem affecting one person may still be urgent when that person is processing payroll or preparing a time-sensitive submission.
Ask for examples of each priority level, then compare them with your actual working day. If you run an online shop, an unavailable checkout deserves a different escalation path from an internal printer issue.
The fine print that changes the experience
Before agreeing to an SLA, clarify:
- Support hours: Are targets measured in business hours or around the clock?
- Clock start: Does timing begin when an email arrives, when a ticket is logged or when a technician accepts it?
- Third parties: Who contacts the internet provider, software vendor or hosting company?
- Escalation: What happens when the first responder cannot fix the issue?
- Updates: How often will somebody explain what is happening during a prolonged outage?
- Exclusions: Are site visits, out-of-hours work and major changes charged separately?
An SLA that is technically precise but operationally vague is not particularly helpful.
Make the reporting useful
Monthly ticket counts alone tell you little. Look at repeat incidents, ageing unresolved tickets and issues that disrupted important work. If eight people separately report unreliable Wi-Fi, a better outcome is a network fix, not eight closed tickets.
It is also worth agreeing how staff should flag business impact. “Email not working” is useful. “Customer service cannot send quotes to clients” gives the support team a better basis for prioritisation.
One test worth running
Describe your most disruptive plausible incident and ask the provider to walk through the first two hours. Who answers? Who investigates? Who speaks to management? Who approves a workaround? The conversation reveals more about service quality than a list of impressive-looking SLA numbers.
The best agreement is the one your staff can understand before they need it.
