An SLA is a promise about time, and time is the part of a help desk most likely to be implemented carelessly. Two systems can both claim a four-hour first-response SLA and disagree by two and a half days on whether a specific ticket breached. Neither is lying; they run different computations, and almost nobody checks which one they bought. This article is about the computation: what a deadline actually is, how it is derived, and where the derivation goes wrong.
The two computations produce different deadlines
A wall-clock SLA adds elapsed minutes to the creation time. A business-minute SLA steps forward through your calendar and counts only the minutes that fall inside a working day, inside working hours, and not on a holiday. The difference is not a rounding detail. Here is the same four-hour target, on a Monday-to-Friday 09:00-17:00 calendar.
| Ticket arrives | Wall-clock deadline | Business-minute deadline | Gap |
|---|---|---|---|
| Tuesday 10:00 | Tuesday 14:00 | Tuesday 14:00 | None |
| Tuesday 16:00 | Tuesday 20:00 | Wednesday 12:00 | 16 hours |
| Friday 18:00 | Friday 22:00 | Monday 13:00 | 63 hours |
| Saturday 11:00 | Saturday 15:00 | Monday 13:00 | 46 hours |
| Thursday 16:30, Friday a holiday | Thursday 20:30 | Monday 12:30 | 88 hours |
Row three is why this matters operationally. Under wall-clock arithmetic that ticket breaches at 22:00 on Friday, and Monday morning shows a breach for a ticket nobody could have answered without an on-call rota you never agreed to staff. Breach counts that include time you never promised to be working are noise, and a team that learns to ignore its breach dashboard has lost the mechanism that made the promise real.
The same logic applies in reverse. If you run 24/7, wall-clock is the correct computation and a business-hours clock would quietly forgive genuine misses. Business minutes are not always right; the computation must match the commitment, and you should be able to say which one your system performs.
Whose calendar, and whose timezone
The calendar belongs to the team that must act. A deadline exists to tell an agent when to do something, so it has to be expressed in a clock that agent is awake for.
This becomes concrete the moment a team is distributed. A team split between Dubai and Toronto sharing one queue needs every deadline evaluated against a single declared workspace timezone, not the server’s and not whichever agent opens the ticket. A server running in UTC that computes “09:00 to 17:00” without converting produces a working day starting at 13:00 for the Dubai half and ending before the Toronto half arrives.
The customer’s timezone governs what you publish, not what you compute. “We reply within one business day” is checkable by a customer anywhere. “We reply within four hours” means five different things depending on when they send it.
First-response and resolution are two commitments
A first-response clock measures the gap between the ticket arriving and a human saying something public. A resolution clock measures the gap between arrival and the problem being closed. They answer different questions and should not share a number.
| First-response clock | Resolution clock | |
|---|---|---|
| Measures | Time until the customer hears from a person | Time until the issue is actually finished |
| Stops on | The first public reply | The ticket reaching a resolved state |
| Should pause for the customer | No; nothing is owed by the customer yet | Arguably yes; a ticket blocked on their answer is not your failure |
| Gamed by | Sending an empty acknowledgement | Closing tickets early and letting them reopen |
| Good default | Tight, and the same for most priorities | Loose, and genuinely differentiated by priority |
Both are gameable, in opposite directions. A team measured only on first response sends acknowledgements. A team measured only on resolution leaves the customer silent for two days and then fixes it properly. Publish both, and read them beside customer satisfaction results rather than instead of them.
The pause problem is an architecture problem
Pausing an SLA clock while you wait for the customer sounds like a configuration option. It is a data-model decision, worth understanding before you promise it to anyone.
There are two ways to store a deadline. Stamp it: compute an absolute timestamp at creation and store it, so a breach check is one cheap comparison and every report agrees with every other report. Accumulate it: store the business minutes consumed so far, advance them while the ticket sits in an active state, and derive the deadline on read. Only the second design can pause, because pausing means not advancing an accumulator and there is nothing to not-advance in a fixed timestamp.
Stamping buys determinism and gives up pausing. Accumulating buys pausing and gives up the guarantee that yesterday’s deadline is today’s. Neither is wrong, but a vendor offering stamped deadlines and a pause feature is doing something you should ask about.
What breaks at holidays and on empty calendars
Two failure modes live in the calendar itself.
The first is the holiday nobody entered. A business-minute walk that does not know about a public holiday counts it as a full working day, and every deadline computed that week is a day early. That is a data problem, not a software problem, and the highest-return thing to check each January.
The second is the calendar with no working minutes at all. If a configuration error marks every day non-working, or working hours are saved with the start after the end, a minute-by-minute walk has no terminating condition: it steps forward forever looking for a working minute that does not exist. Any correct implementation needs a guard. In Oneop the walk carries a 366-day limit and falls back to elapsed time rather than looping. That is the right defensive choice and also a signal to watch for, since a deadline that suddenly looks like plain wall-clock arithmetic usually means a calendar that has stopped containing working minutes.
The failure case: the priority you raised after the clock was set
Here is the one that catches real teams, and it is invisible until someone audits a breach report.
A support lead sets two rules: medium priority gets a four-hour response target, urgent gets one hour. Triage policy is that everything arrives as medium and is raised by whoever picks it up. A payment outage arrives Tuesday at 11:00 as medium and is raised to urgent at 11:06 by an agent who correctly recognises it.
The deadline on that ticket is 15:00, not 12:00. It was computed at creation from the rule that matched at creation, and raising the priority six minutes later did not recompute it. The team believes it operates a one-hour urgent SLA; the system is measuring a four-hour one. Nobody finds out until a customer asks why a severity-one incident took three hours, and the breach report sides with the system.
In Oneop this is explicit: the deadline is stamped once at creation and only ever fills a deadline that was empty, so it is idempotent and a later priority change does not restamp. Both fixes are procedural. Either triage to the correct priority at intake, with routing rules and form fields rather than human reclassification, or accept that the clock reflects intake priority and stop promising otherwise.
Two rule-matching behaviours belong in the same audit. A rule must be active, belong to your workspace, and match the priority exactly; where none matches, the ticket carries no deadline rather than an invented default, so it is absent from breach statistics rather than counted as compliant. Where two rules match, the most recently created wins, so duplicating a rule to “try something” silently changes every new ticket’s deadline.
How Oneop computes a deadline
The Oneop help desk walks the breach deadline forward one working minute at a time from the moment the ticket was created. Each step asks three questions before it counts: working day, working minute, and not on your holiday list. All three are evaluated against the workspace’s own timezone rather than the server’s. The default calendar is Monday to Friday, 09:00 to 17:00, and the days, hours, timezone and holidays are configurable per workspace. Counting raw elapsed time is also a setting, for teams whose commitment genuinely is wall-clock.
One breach timestamp is stored per ticket, derived from the rule’s resolution time if it has one, then its first-response time, then its escalation time. Escalation only ever raises: a sweep works out the level a ticket should be at, acts only if that is higher than the level recorded, hands the ticket to the deepest matched rule naming a person, and notifies both the previous assignee and the manager taking it on. A breach is a one-shot condition rather than a repeating event, since each breached ticket is claimed with a guarded write that only succeeds while nothing has claimed it, so the automation behind it fires exactly once. “Chase every hour until someone answers” is a delay step inside that automation, not the same trigger firing five times.
SLA rules and escalation are a Pro-plan capability; the ticket queue and shared inbox are on every plan. Before configuring anything, run the audit this article implies: take last month’s breaches, check which fall outside your working hours, and count how many tickets carry no deadline at all. The structure that queue sits in is covered in running support on two channels, and which commitments are worth automating enforcement for is in when not to automate.