SLAs, priorities and response times in support

“We reply within four hours” is cheap to write and expensive to keep. A declared time does not make a team faster: it makes the speed it already has measurable, and it makes every miss visible. That is a very good thing, as long as you know that is what it is.

This guide is about declaring times that hold: priorities first, hours second, and the distinction most vendors leave blurred — between software that warns and a promise made to a customer.

What a service level target actually is

In everyday use, “SLA” covers two different things that are worth keeping apart, because their consequences are opposite.

• The contractual commitment. It lives in the contract, applies towards the customer and usually carries consequences when missed. It is a commercial and legal decision, not a setting.
• The time configured in the software. It is an internal reminder: it tells the team that a request is approaching the threshold you gave yourselves. It is not visible to the customer and produces no consequences by itself.

The second exists to help you keep the first, and confusing them is the expensive mistake: software that flags a breach has promised nothing to anyone, and a signed contract does not become true because somebody configured a number.

Priorities come before times

A single time for every request is always wrong: either it is so loose that it means nothing for serious cases, or so tight that it is impossible for trivial ones. Priorities exist for that, and they should be defined by effect on the customer — not by how annoying the request feels to you.

• High: the customer cannot work and there is no way around it.
• Medium: they can work, but slowly, manually or badly.
• Low: it needs fixing, but not today.

Three levels hold in most small companies; five produce more debate and the same decisions. And your team assigns the priority by reading the request. If the customer picks it from a menu, everything is urgent within six months and the times stop meaning anything again.

What is measured, and from when

There are only two measurements worth declaring, and they are different in kind:

• First reply. From the moment the request arrives to the moment a person writes to the customer. It is what the customer experiences, and what trust is built on.
• Time in progress. How long a request may stay open before it is worth looking at again. It catches the requests that breach nothing and age anyway.

The detail that separates a fair target from an unfair one is waiting on the customer. When you have replied and are waiting for information from them, that wait is not your delay and must not consume your clock. Without that distinction the team learns to close requests quickly to avoid a breach, which is precisely the behaviour you were trying to prevent.

And hours must be declared for what they are. If the count runs continuously, twelve hours opened on a Friday evening expire on Saturday morning: a reader who sees “four hours” naturally thinks of office hours, so say out loud that they are not.

The software warns, it does not act

Here is the promise most product pages let you assume without ever writing it down. A ticketing system that handles times sends a warning — before the threshold, after it, or both. It does not close requests, reassign them to somebody else, raise their priority or phone anyone on your behalf.

So a configured time produces a result only if somebody receives the warning and has the authority to act on it. A warning landing in a mailbox nobody reads is not a control: it is noise, and within three weeks it gets filtered. Decide, together with the time, who gets warned — the person who owns the request, and who is told when nobody has picked it up yet.

The other question to put to a supplier, and one that rarely has a written answer: does the customer see that a threshold was missed? In most cases they should not. A customer receiving a delay notice before you have seen it yourself is an extra problem, not a sign of transparency.

When declared times are not useful

If you receive few requests and see all of them within the day, a configured time adds nothing: you already know where they are. If there are two of you, the reminder is you.

They are no help either when the delay comes from available time rather than visibility. If requests stay open because the people answering are doing something else, a threshold turns a staffing problem into a list of missed thresholds. Useful information for deciding on a hire — but nothing has been solved.

And avoid them entirely until priorities are agreed: different times applied to priorities everyone assigns their own way measure the judgement of whoever opened the request, not the service.

How response times work in OglutTicket

Times are switched on per project, one at a time: where you do not need them there are none, and no project starts with times to meet. For each status you say how long is too long, with different values per priority, so an urgent request does not wait like a normal one.

Warnings arrive before the deadline and not only after it, in the notification bell and by email, to the person holding the request — or to the administrators if nobody has taken it yet. Waiting on a customer reply has its own separate clock, which you normally do not configure. The customer never sees that a time was exceeded.

Two stated limits, because this is the part worth knowing beforehand: hours are continuous rather than office hours, and warnings stay warnings — the software does not close, reassign or change priority for you.

The response-time section inside the full path of a request is on how it works. If priorities are still to be agreed, start from organising customer support in a small business; for the underlying definition there is what a ticketing system is.