A service level agreement is a promise in numbers. It tells users what to expect and tells the IT team what to prioritise. The best ones are short, specific and reviewed regularly. The worst ones are copied from a template, never measured, and quietly ignored.
Start with priorities, not response times
Define three or four priority levels based on impact (how many people or how much revenue) and urgency (how quickly it gets worse). A payroll system down on pay day is critical. One person's second monitor flickering is low. Everything else fits in between.
Attach two numbers to each priority
- Response time: how quickly a human acknowledges and starts work.
- Resolution target: how quickly service is restored or a workaround is in place.
A typical set for a small business: critical responded to in 15 minutes and resolved in 4 hours; high in 1 hour and 1 business day; medium in 4 hours and 3 business days; low in 1 business day and 5 business days.
Be honest about hours and scope
State the hours the targets apply to, what happens outside them, and which systems are covered. If your team goes home at 6pm, a 24/7 target is a promise you will break every night.
Define how you measure
Say where the clock starts (ticket logged), where it stops (user confirms or 3 days of silence), and what pauses it (waiting on the user or a vendor). Without this, every missed target becomes an argument.
Add the boring but essential sections
- Service request turnaround times, which are separate from incidents.
- Planned maintenance windows and how much notice you give.
- Escalation path with names or roles.
- Review cadence: monthly reporting, quarterly SLA review.
Then measure and talk about it
An SLA you report on monthly becomes a shared language between IT and the business. An SLA that sits in a drawer changes nothing. Our managed IT plans come with written response targets and a monthly report against them.