Somebody wrote "one hour first response" into a service catalogue, and the queue is worked by two people who also have other jobs. The number was not chosen from data. It was chosen because it sounded professional, and because the tool suggested it. Six months later the breach rate is 30 per cent, the dashboard is ignored, and the one genuinely urgent request of the month still waited four hours because it looked like everything else.
A helpdesk SLA is not a quality initiative. It is an arithmetic statement about coverage, volume and staffing, published as a promise. Get the arithmetic wrong and the promise makes things worse than having none, because a target that is missed routinely teaches everybody that targets can be missed.
The number is a staffing decision
Before any tool is configured, three quantities decide what is honest to promise.
Coverage is the first. How many hours a day, and which days, is somebody actually watching the queue? Not on call. Watching. A team covering 09:00 to 17:30 on weekdays has 42.5 hours of cover in a 168-hour week, which is a quarter of the calendar.
Volume and its shape is the second. The daily average matters less than the peak. If Monday morning brings four times the Wednesday load, the target has to survive Monday morning, or the Monday breaches will make up most of the breach total on their own.
Absence is the third and most often forgotten. A promise that requires both members of a two-person team to be present is not a promise, because holiday and illness are certainties. A target is only real if it survives one person being away.
Run those three together and the honest first response target usually falls out. A single person covering weekday office hours with a queue of thirty items a day can reliably promise a first reply within one working day. Promising one hour means promising to drop whatever else that person does, every time, and that is a different job description.
What each clock actually measures
Help desks offer several different timers, and the choice between them changes behaviour more than the number attached to them. The list below uses Zendesk's names because they are documented in detail, and the concepts carry across tools.
| Metric | What it measures | When it pauses or resets |
|---|---|---|
| First reply time | Time from ticket creation to the first public agent comment | Does not pause |
| Next reply time | Starts at the oldest unanswered customer comment, stops at a public agent comment | Resets with each exchange |
| Periodic update | Time since the last public agent comment | Resets after every public agent comment |
| Requester wait time | Time the ticket spends in New, Open and On-hold | Pauses on pending |
| Agent work time | Time the agent holds the work | Pauses on pending and on-hold |
| Pausable update | An update clock that respects waiting | Pauses on pending, restarts when the status returns to open or on-hold with a comment or note |
Two consequences follow from that table.
First reply time is the only clock fully inside the team's control, which is why it is the right first commitment. It also cannot be paused, so it has to be paired with a coverage window or it will run all night.
Resolution time, by contrast, is mostly outside the team's control, because the majority of slow tickets are slow while waiting for the requester or a third party. Promising a resolution time without a pausing metric is promising something the customer partly determines. Periodic update or pausable update is the better promise for long-running work: not "this will be fixed in three days" but "somebody will tell you where this stands every two working days until it is done".
Business hours or calendar hours decides everything
This single setting causes more disputes than the targets themselves.
A four-hour first response target measured in calendar hours, worked by a team present from 09:00 to 17:30, breaches every time a request arrives after 14:30 on a Friday. Measured in business hours, the same request is answered at 09:30 on Monday and the target is met. The work was identical. Only the accounting changed.
Three details are worth checking in the tool before the policy is signed off. Whether the choice between business and calendar hours can be made per priority, which in Zendesk is an Enterprise-plan setting. Whether the schedule includes public holidays, since a target that ignores them will generate a burst of breaches twice a year. And how the tool applies a schedule when one changes, because status-based metrics capture the schedule at the time of each status change while single-event metrics such as first reply time apply one schedule for the whole ticket. That is the usual explanation when two reports disagree by exactly one working day, and switching a report to calendar hours is the fastest way to confirm it.
There is also a prerequisite that catches new configurations. In Zendesk, a policy applies only to tickets with a priority set in the system priority field, so a queue where nobody sets priority silently has no policy at all. The stock account includes a trigger that sets unprioritised tickets to normal, and if it is switched off the coverage disappears with it.
The shipped defaults are more aggressive than they look
Adopting a default is a decision, not a neutral act, and the defaults in this category are set for well-staffed support teams.
Zendesk provides a standard policy named Set first reply time, available for most accounts created on or after 3 March 2025. Its target is one hour at normal priority. Accepting it without changing anything commits a two-person team to an hour, all day, on every ticket that lands at normal priority.
Freshdesk allows multiple policies from the Pro plan upward, listed at $55 per agent per month billed annually, with Growth at $19 and Enterprise at $89 on the same basis. That matters for the policy design as much as the budget, because a single policy cannot express different promises for different customer groups or different priorities.
Two more behaviours are worth knowing before the first review meeting. Marking a ticket solved immediately fulfils every active target on it, which is exactly why "solve it now and reopen if they complain" becomes a habit on teams under pressure. And policies do not back-date: applying or changing a target that is already breached records the breach at the moment of the change, so tightening a target does not retroactively rewrite last month's report.
Setting a target from the queue rather than from a template
The method is short.
Export ninety days of the queue with the creation time and the time of the first outbound reply. Calculate the median and the ninetieth percentile, in business hours, for the hours the team actually covers.
Set the published target near the current ninetieth percentile, not the median. A target set at the median is missed half the time by definition. A target near the ninetieth percentile is met almost always, which makes the number credible, and it can be tightened later once the habit exists.
Then define priority with at most three levels, and define them by impact rather than by how the requester feels. Something is high priority when it stops work for many people or has a deadline outside the organisation's control. Everything else is normal. A fourth level is almost always used to mean "this one matters to me".
| Priority | What qualifies | First reply | Update cadence |
|---|---|---|---|
| High | Work is stopped, or an external deadline is at risk | Within 2 business hours | Daily until resolved |
| Normal | Work continues with difficulty | Within 1 business day | Every 2 business days |
| Low | A request, a question, a change for later | Within 3 business days | On change of state |
Those figures are an example of the shape, not a benchmark to copy. The point is the relationship between the levels and the fact that every level carries an update cadence, which is the part customers notice.
Three numbers worth reviewing each month
Breach rate is the number everybody reports and the least useful of the three, because it averages away the case that does damage.
The age of the oldest item with no reply is the first number to read. It is a single figure, it cannot be gamed by volume, and it points at one specific request that somebody has to deal with today. A team with a 96 per cent achievement rate and a fourteen-day-old unanswered request has a problem that the percentage is hiding.
The share of open items where the team owes the next move is the second. This separates a backlog that is genuinely waiting on customers from one that is waiting on the team, and those two situations call for opposite responses. A queue that is 80 per cent waiting on customers needs better chasing, not more staff.
The reopen rate is the third, and it is the check on the other two. Fast first replies and quick resolutions can both be produced by closing things prematurely, and the reopen rate is what exposes that. If first response improves while reopens climb, the target is being met by cutting the work short.
When the promise cannot be met, change the promise
There is an order of operations here, and hiring is last.
Narrow the window and publish it. A stated promise of "answered within one working day, Monday to Friday, 09:00 to 17:30" is worth more than an unstated aspiration of one hour.
Make the automatic acknowledgement tell the truth. An auto-reply that says a response will arrive within one working day sets an expectation that will be met. One that promises a call within the hour manufactures a complaint.
Reduce to one metric. A single first-response promise that is always kept beats four metrics that are all approximately kept.
Add an internal target between teams before adding one for customers. Where a request has to pass through a second team, the handover is usually where the time goes, and an ownership target for the receiving group is what makes it visible. In Zendesk these group policies are an Enterprise feature, which is worth knowing before the design depends on them.
Where the tool has no breach timer at all, the working substitute is an aged list: every open item sorted oldest first, with an owner's name against each, read by one person on a named day. That list catches the thing a percentage never shows, which is the single request that has been waiting eleven days. A queue built on stages and owners will produce it, and it answers the question a breach rate cannot.
What to change first
Measure the ninetieth percentile of the current first reply time in business hours, publish that number as the promise with the coverage window stated next to it, and delete every other target for one quarter. If nothing today can produce the aged list that makes this checkable, the gap is the queue rather than the policy, and a Halict board with an owner and a stage on each item is the shortest way to get one.
Q1. What is a reasonable first response target for a small helpdesk?
Whatever the ninetieth percentile of the current performance is, measured in the hours the team covers. For one or two people handling a queue alongside other duties, one business day is usually honest and a few hours is usually not. The credibility of the number matters more than its size.
Q2. Should SLA targets use business hours or calendar hours?
Business hours, unless the team genuinely covers the clock or a regulator has specified calendar days. Calendar hours against an office-hours team manufactures breaches every evening and weekend, which trains everybody to ignore the report. Publish the coverage window alongside the target so the promise is unambiguous.
Q3. Why does a resolution time target usually fail?
Because most of the elapsed time on slow tickets is spent waiting for the requester or a third party, which the team does not control. A pausing metric, or a periodic update promise, measures what the team can actually deliver: regular, honest progress reports until the work is finished.
Q4. What is the difference between an SLA and an OLA?
An SLA is the promise to the customer. An OLA, sometimes implemented as a group or internal policy, is the promise between teams inside the organisation, such as how long a second-line group may hold a request before acting. Customer-facing targets are rarely achievable without the internal ones, because handovers are where the time disappears.
Q5. Does a small team need SLA software at all?
Not necessarily. Breach timers are useful above a certain volume, but the same job can be done with a queue that shows every open item with an owner and an age, reviewed on a fixed day each week. Buy the timers when the list is too long to read, not before.