A founder told me his company promised a two-hour first response. I asked how many tickets came in on a Sunday and how many people were working. The arithmetic did not survive the question.
The promise had been set by looking at a competitor's website. That is how most service levels get set, and it is why most of them are quietly broken.
Work it from capacity backwards
Start with the real numbers: how many requests arrive, in what pattern across the week, how long each type genuinely takes, and how many people are available — minus holidays, sickness and the person who is in a meeting.
Then set the promise with headroom for a bad week. Not an average week. The week when two people are away and a release goes wrong.
Different promises for different things
One blanket response time across every request type guarantees you will either over-serve the trivial or under-serve the urgent. Split them: a payment failure is not a feature question.
Three tiers is usually enough. Each gets its own first-response time and its own resolution target, and each one is set from how long that category actually takes.
Write the escalation path before you need it
The moment to decide who gets pulled in on a serious problem is not during the serious problem. Write it down: at what point does it leave the first responder, who is next, and after how long does it reach you.
Then tell the team that escalating early is correct behaviour, not failure. If escalation is treated as weakness, people sit on problems until they are expensive.
Templates are not impersonal
There is a fear that prepared replies make support feel robotic. In practice the opposite is true: a team improvising under pressure writes worse, colder messages than a team working from a good template they adapt.
Write the fifteen situations your team meets every week. Leave space in each for the specific detail. Quality stops depending on who happened to pick up the ticket.
Publish only what you will defend
Say less and hold to it. A company that promises next-business-day and always delivers is trusted more than one that promises two hours and manages it most of the time.
Set times you can actually hold
An SLA builder worked from real capacity, the escalation path behind it, and the replies your team sends.
See the bundle →In this article
Rather just ask?
Thirty free minutes on the problem itself, instead of another article about it.
Book a call →