Support email SLAs, explained for UK teams.

A customer service SLA, or service level agreement, is a written commitment to answer and resolve support requests within set times. In email support it usually has two targets: a first-response time, how long until a customer gets a first human reply, and a resolution time, how long until the issue is fixed. Good SLAs are realistic, measured against the hours your team actually works, and reviewed when they are missed.

You do not need a legal contract to have an SLA. For a small UK team it is often just an internal standard: a short promise the team holds itself to, even if customers never see the exact numbers. Writing it down turns a vague hope of replying quickly into something you can measure, staff for and improve.

The rest of this guide builds that standard up in plain steps: the two clocks every SLA tracks, why UK business hours and bank holidays change the maths, how P1 to P4 priority works, a worked example you can adapt, and how Solves measures it all.

First-response time measures how long a customer waits for a first human reply after they write in. It is the acknowledgement that a real person now owns the ticket, and it is usually the number customers feel most. A reassuring reply within a few working hours buys a lot of patience, even when the full fix takes longer.

Resolution time measures how long until the request is actually done: the bug fixed, the refund issued, the question fully answered and the ticket closed. It is naturally more generous than first response, because real fixes take real work, and it varies far more by priority and complexity.

Measuring both keeps you honest. A team can look fast on first response while quietly leaving hard tickets open for weeks, or resolve everything but make customers wait a day for any acknowledgement. Tracking the two clocks separately, per priority, shows you which half of the promise is slipping.

Watching the Waiting pile

A long wait is often the customer, not your team. If you ask a question and they take three days to reply, that delay is outside your control, so factor it in when you read your numbers. Solves gives a ticket a Waiting for Customer state and a saved Waiting view, so you can separate time parked on the customer from time genuinely on your desk when you review how the team is doing.

If your team works UK business hours, your SLA should be measured in those hours, not in calendar time. A ticket that arrives at 5:30pm on a Friday should not silently breach a 4-hour target overnight while the office is empty. Counting only working hours keeps the target fair to the team and honest to the customer about when a reply is realistic.

Bank holidays make this sharper in the UK, where a long weekend can stretch a Friday-evening ticket across three non-working days. An SLA that ignores bank holidays will show a wall of false breaches every spring and late summer, and your team will quietly stop trusting the numbers.

When you set your Solves targets, choose minute values that reflect the cover you actually staff, so a generous out-of-hours window does not turn into a wall of false breaches. Solves has first-response and resolution SLA timers, with per-brand or organisation targets and a due date calculated from when the ticket arrives, and a breaching view that surfaces overdue tickets. That is the difference between an SLA report your team believes and one they learn to ignore.

Two timers	First response and resolution, each tracked separately against the target you set.
Targets in minutes	Per-brand or organisation targets, with a due date calculated from when the ticket arrives.
Breaching view	Overdue tickets surface in a saved view so the team can act on them.
Ageing visible	Older tickets surface so nothing rots quietly at the bottom of the queue.

P1 to P4 are a simple way to say how urgent a ticket is, so the same SLA does not treat a blocked customer and a minor query as equals. The exact wording varies between teams, but the shape is consistent: lower numbers are more urgent and carry tighter targets.

1. P1, critical: the customer is blocked or a service is down, with no workaround. Tightest first-response and resolution targets; often everyone drops what they are doing.
2. P2, high: a significant problem, but with a workaround or partial use. Quick response, resolution within a working day or so.
3. P3, normal: a standard request or question handled in routine business hours. The bulk of most queues.
4. P4, low: a minor query, cosmetic issue or feature wish. Acknowledged promptly, resolved when capacity allows.

Keeping it to four levels is deliberate. More tiers look thorough but slow triage, because every ticket needs a finer judgement call. For a small team, four clear levels with written targets are easier to apply consistently than ten, and consistency is what makes an SLA mean anything.

In Solves you set a priority on each ticket, filter and sort the queue by it, and watch a dedicated breaching view that surfaces tickets close to or past their target. Priority drives which work the team picks up next, while the timers keep the targets honest in the background.

A useful SLA fits on a single screen. Here is a sensible default for a small team working UK business hours, measured in working hours with bank holidays excluded. Adjust the figures to match the cover you can actually staff: a target you miss every week is worse than an honest, slightly looser one you hit.

P1, critical	First response within 1 working hour, resolution within 4 working hours.
P2, high	First response within 4 working hours, resolution within 1 working day.
P3, normal	First response within 8 working hours, resolution within 3 working days.
P4, low	First response within 1 working day, resolution when capacity allows.

How to set targets you can actually hit

Base the numbers on what your team can sustain on a normal week, not your best day. Look at how long replies really take now, set targets a little tighter to create useful pressure, and keep some headroom: aiming for around 95% compliance rather than a perfect 100% leaves room for the odd complex case without the whole SLA looking failed.

• Start from your current real response times, not a number that sounds impressive.
• Set a tight first-response target and a more generous resolution target per priority.
• Measure in working hours so the clock matches when people are at their desks.
• Review breaches monthly and adjust the targets or the staffing, not just the team.

An SLA is only as good as the reporting behind it. Solves reports cover first response, resolution, open backlog, ageing, the Waiting pile and created-versus-resolved over time, with brand filters, so you can see whether the promise is being kept and where it is slipping. The breaching view shows the live risk; the reports show the trend.

That is what lets a small team quote a response time it can stand behind. You set targets in minutes that suit the cover you staff, watch the breaching view for what is overdue, and review the misses so the next month is better. For the full detail, see the reporting and SLA timers pages linked below.