SLAs That Mean Something: First Response, Resolution & a Clock You Can Pause
An SLA you cannot measure is a hope you have shared with a customer. What first-response and resolution targets actually require, why the pause is the feature that makes them fair, and how to set targets you will not quietly abandon.
Most Kenyan service agreements contain a response-time promise that nobody has ever measured. It was written to win the contract, it sounds reasonable, and if a client ever produced evidence of a breach the honest internal response would be that nobody actually knows whether it was breached or not.
That is a commercial exposure and, more immediately, a management one — because a target you cannot measure cannot be improved, staffed for, or defended. This guide covers what it takes to make an SLA real, and how to set one you will still be honouring in six months.
Two clocks, not one
The most common SLA mistake in Kenya is promising a single resolution time. It sounds simple and it is the wrong shape, because it conflates two entirely different customer experiences.
First response
- Time until a human acknowledges the issue and says who owns it
- Should be short — hours, not days
- Almost entirely within your control
- This is what customers actually judge you on
- Silence, not slowness, is what generates complaints
Resolution
- Time until the issue is actually fixed
- Varies enormously by the kind of issue and by cause
- Often depends on the customer, a supplier, or a third party
- Customers tolerate a long fix they are informed about
- This is the clock that needs a pause to be fair
Splitting them lets you make a promise you can keep on the part you control, while being honest about the part you do not. A four-hour first response with a resolution target that reflects the kind of issue is both more achievable and more reassuring than a blanket "resolved within 24 hours" that everybody knows is aspirational.
Customers rarely complain about how long a fix took. They complain about the period when nobody told them anything. Buy back that period first — it is the cheapest reputation you will ever purchase.
The pause is what makes the clock fair
This is the feature that separates a real SLA engine from a timestamp subtraction, and it is worth understanding before you set any target.
A large share of resolution time is spent waiting on the requester — for a screenshot, an approval, access to a site, a decision, or simply a reply. If the clock runs through that period, your SLA report measures your customers' responsiveness rather than your performance, and your team quickly learns that the metric is unfair and stops respecting it. Once a metric is considered unfair it stops changing behaviour, which is the only reason to have it.
So the resolution clock must be pausable when a ticket is genuinely awaiting the requester, and resume when they reply. In AWRA this is tied to the ticket's status rather than left to an agent's judgement afterwards: moving a ticket to "waiting on requester" stamps the pause, and moving it out pushes the resolution due date forward by exactly the elapsed paused span. The pause is on the record, so a customer disputing a breach can be shown precisely which days the ball was in their court.
Why tying the pause to a status matters
A pause an agent can apply as a private accounting choice becomes a way to make the numbers look good, and then your SLA report is fiction in the other direction. Because the pause here is a consequence of a visible status change — the requester can see the ticket is waiting on them — pausing costs something socially, which is what keeps it honest.
Setting targets you will not abandon
The failure mode is setting ambitious targets, missing them constantly, and within two months treating the breach report as noise. A target that is routinely missed is worse than no target, because it trains everyone to ignore the one signal that was supposed to matter.
-
Measure for a month before promising anything
Run the helpdesk with no targets and find out what you actually do today. Almost every organization is surprised, usually in both directions.
-
Set the first target at roughly your current 80th percentile
Achievable today for most tickets, with a visible tail to work on. Setting it at your best-ever performance guarantees constant breach.
-
Attach the target to the category, not the mood of the day
In AWRA the SLA policy lives on the ticket category — each category carries its own first-response and resolution minutes, alongside a default department and assignee. "Password reset" and "system down" are different categories and deserve genuinely different clocks.
-
Keep priorities few and define them in writing
Priority orders the queue; category sets the clock. Three priority levels is usually right, and each needs a written definition — otherwise everything is urgent, particularly whatever the loudest requester just sent.
-
Review breaches weekly, tighten quarterly
Weekly to catch the cause while it is live; quarterly to move the target once the tail has genuinely shortened.
Category sets the clock; priority orders the queue
This division matters and is worth being deliberate about. The SLA target belongs on the category, because category is an objective property of the issue — a request to reset a password and a report that a depot cannot dispatch are different kinds of work and should carry different promises. Category also drives default routing, so the right department and assignee are set at intake.
Priority then decides what an agent picks up first among tickets that are all within their targets. Left undefined, priority tracks the requester's persistence rather than the business consequence — so the branch manager who calls twice gets a critical ticket while a quietly broken process affecting a whole depot sits at normal.
| Priority | Definition that works | What it should NOT mean |
|---|---|---|
| Critical | Revenue or operations stopped, or a statutory deadline at risk | Somebody senior is annoyed |
| High | A team or site significantly impaired, with no workaround | It arrived by phone rather than email |
| Normal | A real problem with a workaround, or affecting one person | The default nobody thought about |
Write those three sentences down and put them where tickets are raised. It is one of the highest-return fifteen minutes available, because it moves the priority decision from social pressure to a stated rule anybody can point at.
What we do and do not do
What AWRA OpsHub does today
- Separate first-response and resolution targets, set per ticket category in minutes.
- Default routing from the category — department and assignee applied at intake unless the ticket already sets its own.
- A genuinely pausable resolution clock — moving a ticket to "waiting on requester" stops it, and leaving that state pushes the due date forward by exactly the paused span.
- Due timestamps stored on the ticket, so the target is visible while the work is live rather than computed in a report afterwards.
- Breach notification, which re-arms if the target changes.
- Reporting on response and resolution times by category.
What it does not do
- The clock is elapsed wall-clock time from ticket creation. There is no business-hours, weekend or public-holiday calendar — a ticket raised at 6pm Friday keeps counting through the weekend.
- Targets are not set per priority. Priority orders the queue; the category carries the SLA policy. If you need per-priority targets, model them as categories.
- We do not compute contractual penalties or produce SLA certificates for clients.
- No automatic escalation up a management chain on breach beyond notification.
- No customer-facing SLA dashboard for clients to self-serve their own performance data.
That first point is the one to take seriously. If you have promised an hours-based SLA in a contract with financial consequences, the elapsed-time clock will not match "8 working hours" wording — decide deliberately how you handle nights, weekends and holidays before relying on the figures.
Read breaches as a staffing signal
When breaches cluster, the instinct is to ask the team to work faster. Usually the breach report is telling you something more useful and more structural.
- Breaches concentrated on one agent — a workload distribution problem, not a performance one.
- Breaches concentrated in one category — a knowledge or a root-cause problem; fix the cause and the tickets stop arriving.
- Breaches clustered on particular days — a capacity pattern you can staff for, often Mondays or month-end.
- First response fine, resolution poor — you are acknowledging well and getting stuck. Usually a dependency on somebody outside the team.
- Everything breaching — the target was set wrong. Fix the target, not the people.
That last one deserves saying plainly, because organizations are reluctant to revise a target downward. A target set from optimism rather than measurement is a management error, and correcting it restores the value of the metric. The wider practice is in helpdesk software in Kenya.
Our take
Promise a short first response and a priority-dependent resolution, measure for a month before committing to either, and make sure the resolution clock pauses when you are waiting on the customer. If you have a contractual SLA with penalties attached, verify the exact clock behaviour against the contract wording rather than assuming — that is the one place where being approximately right is expensive.
See an SLA clock you can defend
First-response and resolution targets per category, a clock that genuinely pauses while you wait on the requester, breach notification, and reporting on what you actually deliver.
Explore the SLA engineFrequently asked questions
Why separate first response from resolution?
Because they measure different things and only one is fully within your control. First response is acknowledgement — short, achievable and what customers actually judge you on, since most dissatisfaction is caused by silence rather than by slowness. Resolution varies enormously by the kind of issue and often depends on the customer or a third party. A single blended promise is either unachievable or so loose it means nothing.
Does the SLA clock pause while we wait for the customer?
Yes — the resolution clock can be paused while a ticket awaits the requester and resumes when they reply, and the pause is recorded on the ticket. This matters for fairness as much as for accuracy: if the clock runs through periods when you are waiting on a screenshot or an approval, your report measures your customers' responsiveness rather than your performance, and your team will correctly conclude the metric is unfair and stop respecting it.
How should we set our first targets?
Measure for a month with no targets at all, then set the first target around your current 80th percentile — achievable today for most tickets, with a visible tail to improve. Setting targets from ambition rather than measurement produces constant breach, and a target that is routinely missed trains everybody to ignore the breach report, which destroys the only reason to have one.
Does the clock respect business hours and public holidays?
No — it is elapsed wall-clock time from when the ticket was created, so a ticket raised at 6pm on Friday keeps counting through the weekend. There is no working-hours or holiday calendar. If your contract promises something like "8 working hours", the figures will not match that wording, so decide deliberately how you reconcile the two before relying on the report. This is the one place in this guide where being approximately right is genuinely expensive.
What if everything is breaching?
Then the target is wrong, and the correct response is to fix the target rather than to push the team. A target set from optimism rather than measurement is a management error, and organizations are often reluctant to revise one downward because it feels like lowering standards. It is the opposite: an achievable target that people respect changes behaviour, while an unachievable one becomes noise within two months.
