SLA management on business hours you can actually defend

Stillpoint tracks three targets per policy: first response, next response and resolution. Each target runs on either business hours or calendar hours, and which clock was used is stated on every number the system shows you — on the ticket, in the report, in the export. Half of all SLA arguments are really arguments about which clock somebody meant, and that is a labelling problem with a labelling fix.

First response has a precise definition: it counts only public agent replies. An internal note is not a response to the customer. Neither is an automated acknowledgement, and neither is an auto-reply. That is the same definition Zendesk and Freshdesk use, which matters because it means your first response time is comparable to the benchmarks people quote at you rather than a flattering local variant.

Next response applies to every subsequent customer message, which is where teams actually lose customers — the first reply is usually fast because it is easy, and the third reply is slow because it is hard. Resolution measures time to a resolved state on whichever clock the policy specifies.

A single "working hours" setting is not enough for any organisation with more than one team. Stillpoint supports as many schedules as you need, each with its own timezone and its own working windows per weekday — so a Cape Town team on 08:00–16:30 and a London team on 09:00–17:30 are two schedules, not a compromise, and a Saturday morning shift is just a window on Saturday.

Holiday calendars attach to a schedule, and support both fixed dates and dates that repeat every year. A holiday contributes zero working minutes; it does not shift the working window, it removes it.

One implementation detail worth stating because it is where most SLA engines quietly break: the arithmetic walks local calendar days and evaluates each day's windows in the schedule's own timezone, rather than adding fixed hour offsets to a timestamp. That is why a daylight-saving weekend does not silently move every open deadline by an hour, and why a deadline computed in March still explains correctly when you read it in November.

This single example is the whole feature. A four-hour first response target, on business hours of Monday to Friday 08:00–17:00, with a ticket arriving at 15:00 on Monday and a public holiday on Tuesday.

When a ticket is waiting on the customer — you have asked for an order number, a screenshot, a decision — the clock stops. That much every helpdesk claims. The interesting part is what happens when it starts again.

Stillpoint stores the clock minutes already consumed at the moment of the pause, and on resume recomputes the deadline as "now, plus the remaining target" on the correct clock. That sounds like a detail and it is the difference between a defensible number and a fictional one. The classic bug is to add the wall-clock pause duration onto a business-hours deadline: a ticket paused from Friday 16:00 to Monday 09:00 gains 65 wall-clock hours, of which the business clock would only ever have spent one. Adding the wall duration silently hands back time the clock never spent, and the resulting target is unmeetable in one direction or absurdly generous in the other.

Per policy you also choose whether waiting on a third party — a supplier, a courier, an upstream vendor — pauses the resolution clock. Some contracts allow that and some deliberately do not, so it is a setting rather than an assumption.

Every deadline in Stillpoint can be opened and explained. The explanation lists, in order: when the clock started and against which policy and schedule, each window that counted and how many minutes it contributed, each day that contributed nothing and why — closed, or a named holiday — every pause and resume with its reason, and how much clock time remains.

The important property is not the presentation, it is the plumbing: that screen calls the same arithmetic that set the deadline. It does not recompute an approximation for display. So the explanation can never disagree with the number, which is the failure mode that destroys confidence in an SLA report faster than a missed target ever does.

If a schedule or policy was changed after the clock started, the explanation says so rather than quietly showing figures derived from the new configuration. You get "this deadline was set under the previous schedule" instead of an unexplained mismatch with your own settings.

If a policy points at a schedule with no working hours defined, Stillpoint does not fall back to a 24/7 clock and produce a deadline anyway. It withholds the deadline and tells you the schedule needs working hours. The same applies if a policy references a schedule that has since been deleted.

The reasoning is worth stating plainly, because a missing value looks like a bug and a wrong value looks like a feature: a plausible-looking wrong deadline is far more damaging than a visibly absent one. The wrong one gets quoted in a contract review, printed in a board pack and used in somebody's performance appraisal. The absent one gets fixed in about ninety seconds.

Escalating at the breach is escalating too late. Stillpoint fires escalations at percentages of the target, each level with its own recipient and its own action — so a supervisor hears about a ticket while there is still time to do something about it.

A typical ladder: 70% nudges the assigned agent, 100% notifies the team lead, 120% notifies a manager and can automatically raise the ticket priority. Each level fires once, so a long-running ticket does not generate a notification every few minutes and train everyone to ignore them. Every escalation is written to the ticket timeline with its threshold and its reason, which means "nobody told me" is a checkable claim rather than an argument.

The SLA clock history is append-only. Every start, pause, resume, met, breach and escalation is recorded with its reason and timestamp, and nothing in that history is ever rewritten. Compliance is computed from those records, never from a ticket's current fields — which is why a ticket that spent three days paused reports the same way next quarter as it does today.

Two exclusions matter for honesty. Targets that are still running are excluded from compliance rather than counted as successes, because their outcome is not yet known; counting them as met is the most common way an SLA dashboard flatters itself. And tickets that existed before SLA history was recorded are excluded and labelled as such, rather than being assumed compliant.

There is also a deliberate gap, and it is better to name it than to approximate quietly: median and average response times are reported on the calendar clock, because business-hours arithmetic cannot be expressed in portable SQL across the databases Stillpoint supports. The SLA compliance figures — met, breached, at risk, by policy, by team, by agent — are computed on the correct clock and answer the contractual question. The distribution statistics are calendar-time, and every one of them says so.

An SLA promise that depends on somebody remembering it is not a promise. Policies are matched to tickets by an ordered rule set where the first match wins, and the rules can test the data the rest of the platform already holds: priority, customer lifetime spend, RFM segment, order value, company, mailbox or ticket category.

That commerce-aware matching is only possible because the store and the CRM are in the same database as the tickets. "Customers who have spent over $50,000 get a two-hour first response" becomes a rule the system applies to every ticket, including at 02:00 when the person who negotiated it is asleep. Routing rules can then send those tickets to the right team, and every routing and policy decision is written to the ticket timeline so an assignment is never mysterious.