SLA template for a small team: response targets by request type, who owns a miss, and a Slack alert before the clock runs out

Someone asks "what is your SLA?" and you realise nobody on the team has written down how fast a request gets a first reply, who holds the clock, or who is told when it is about to run out. Most of what you find when you search for an SLA template is a contract skeleton with invented numbers, remedies and signature lines. This guide gives you a one-page internal SLA you can copy, a four-week rule for setting every target from your own data, clock rules, an owner for every miss, and the Slack alert thresholds that tell you before the client does.

The short version

The page in five points:

1. Write a first-reply target and a resolution target per request type, not one for the whole team.
2. Measure for four weeks with no promise attached, then set each target at the 80th to 90th percentile of what the team did.
3. Write the clock rules: it starts on arrival, stops on the first human reply, and pauses only while you wait on the requester.
4. Name one owner per request, a backup per owner, and who is told at 75 percent of the window and at 100 percent.
5. Keep it internal until you have hit it for a full quarter. A client contract with credits needs a lawyer.

Why most SLA templates do not fit a small team

Google's SRE book separates the pieces: an indicator is a measured quantity, an objective is the target for it, and an agreement adds explicit consequences if the target is missed. Inside a firm of 5 to 100 people you rarely have consequences beyond embarrassment, so what you need is an objective with an owner. The contract machinery is dead weight.

The template pages that rank for the phrase mostly come from help desk vendors, and they are honest about it. One of them lists eight elements of a support SLA, from parties and scope to remedies, termination and signatures, then adds that an internal SLA usually drops the remedies and signatures. The tier tables in these pages are explicitly illustrative. They tell you what other teams chose, not what yours can hit.

A copied template fails first because its numbers are guesses, and second because its clock rules are missing or buried. Most SLAs fail on the clock rules, not the targets: whether an automatic acknowledgement counts as a reply, whether the clock runs through the night, whether it stops when a colleague is waiting on a third colleague. A practitioner thread on the Atlassian forum shows the cost. A Jira Service Management user with a 48 hour SLA asked why the timer behaved differently when a ticket moved between statuses, and the reply was that the pause conditions decide when the SLA pauses and restarts. That is one user's report about one tool. If you do not write the pause rule, the tool or the loudest person writes it for you.

The third reason is that a miss has no owner. A target missed every day teaches the team to ignore it.

The one-page internal SLA template

This is the page to copy. Fill the brackets, delete what you do not need, and keep it to one screen. The numbers in it are placeholders for step 2, not recommendations.

INTERNAL SLA: [team or channel name]
Effective [date]. Owner of this page: [name]. Reviewed every quarter.

HOURS
Business hours: [days and hours], [time zone]. Holidays: [where listed].
Out-of-hours requests start the clock at the next opening.

REQUEST TYPES AND TARGETS (business hours)
Type First reply Resolution
Blocked, cannot work [time] [time]
Access or account change [time] [time]
Standard question or task [time] [time]
Idea or low priority [time] none

CLOCK RULES
Starts: when the request is created, not when someone opens it.
First reply stops on the first reply from a person on the team.
An automatic acknowledgement does not count.
Resolution pauses only while we wait on the requester's answer.
We never pause for an internal wait.

OWNERSHIP
Every request has one named owner within [time].
At 75 percent of the first-reply window with no owner: [lead] is told.
At 100 percent: [manager or founder] is told and replies or reassigns.
Backup for each owner: [name].

REPORT
Weekly: share of targets met per request type. Goal: about 90 percent.
Nothing client-visible, no credit or remedy, without [owner] and a lawyer.

How to set a target you can hit

Start with request types, not with teams. A password reset and a new-laptop order from the same IT team have very different natural durations, so targets are set per request type. Three or four types are enough. A request that stops someone working gets a shorter clock than a nice-to-have.

For a first guess, the published tables agree on shape even though they disagree on numbers. One support SLA template starts at one business hour for urgent first replies and one business day for normal ones. An IT helpdesk guide uses 30 minutes for critical requests and two hours for standard ones. A help desk guide says many internal desks land between one hour for blocking issues and one business day for routine ones. Treat these as the range you will land in, then replace them.

Measure for four weeks, then set the target at the slow end

Run the team for four weeks with the clock on and no promise made. The guides that cover this say to measure before you promise and to take the 80th to 90th percentile of actual durations per category rather than an average.

Set each reply target at the 80th to 90th percentile of your own first-reply times from four weeks of measurement, not at the median, because a target set at the median is missed by about half of all requests by design. That is my reasoning, not a quotation, but it follows from what a median is. The Google SRE chapter makes the matching point about averages: they hide a long tail.

A made-up example shows the arithmetic. An operations lead logs 20 standard requests over four weeks, with first replies from 0.2 to 7.5 business hours. The median is 1.2 hours. If she promised 1.2 hours, 10 of the 20 requests would have missed it. The 80th percentile is about 3 hours, which 16 of 20 met. The 90th percentile is about 4.3 hours, which 18 of 20 met. She picks 4 hours, and the team starts at roughly 90 percent attainment instead of 50.

You do not need a tool to do this. A spreadsheet with a created time, a first-reply time and a request type is enough, with a percentile formula and an attainment percentage on top.

Aim for about 90 percent, not 100, because 100 percent every week usually means the target is too loose.

Put a quarterly review in the template, since the IT helpdesk guide says to review at least quarterly. If a category never breaches, the target may be slack. If it breaches about a quarter of the time, the target is fiction or the team is understaffed.

The clock rules

Three events define everything: when the clock starts, what stops the first-reply clock, and what pauses the resolution clock.

Start. The clock starts when the request arrives, not when someone opens it or when it is assigned. Drag lists this as the first rule most SLAs get wrong.

Stop. First reply stops on the first reply from a person, and an automatic acknowledgement does not count. The template from Keeping and the Drag guide both say so: counting an auto-reply reports a speed nobody experiences. Private notes between teammates do not count either, and neither does the requester adding detail to their own request, as one help desk guide defines it.

Pause. Pause the resolution clock only while you wait on the requester. Drag adds the half that matters: never pause for internal waits, such as engineering, finance or a manager, because those are the delays an SLA exists to expose. The help desk guide adds two guards against abuse: record each pause as an interval, allow it only after the team asked a question, and auto-resume after a fixed number of days. A request parked in "waiting" forever never breaches, which is exactly why it needs a guard.

Decide before the first breach who owns a miss and what is allowed to pause the clock, because a clock that pauses on internal waiting hides the exact delays an SLA exists to expose. Write the pause rule while nothing is on fire, so a later breach is a data point instead of an argument.

Who owns a miss, and who is told when

The owner of a request replies. The owner of a miss is told when that has not happened, and decides what happens next. Write both names into the template, with a backup for each, because choosing a backup while a request is already stalling turns into a negotiation. The same logic is covered for approvals in the guide to approval requests with a silence clock.

The sources agree on two alert points. One help desk guide escalates at 75 percent of the clock when a request has no owner, to the team lead, and at 100 percent to their manager. The Drag template reminds the owner at 75 percent of the first-response window and notifies the lead at breach, and the IT helpdesk guide routes a missed target to the IT Support Manager for review.

Default table for a small firm:

Alert at 75 percent of the window when a request still has no owner, because an alert at 100 percent only reports a miss that has already happened. At 100 percent the requester is already waiting and your best outcome is an apology. At 75 percent you can still reply on time.

Keep the alerts few: one well-timed nudge beats five automatic ones that train people to ignore alerts, and escalation should go to a person, not a channel everyone has muted.

Run the clock in Slack

If requests already arrive as threads in a channel, you have the material and no clock. The table above can be run by hand with a spreadsheet, and for a team of five that is a fair start. The cost is that someone must remember to look, and that is the coordinator's job. The guide on client requests that disappear into Slack covers the capture side of this.

Here is what the Kipwise agent and its internal request desk do for the clock, and where they stop.

• A request is filed with your team and the requester keeps a card with its number and state. The desk has a triage channel, queues, SLAs, approvals and ratings.
• When a request is about to miss its deadline, misses it, is escalated, or nobody has picked it up for a while, the team sees one line in that request's thread in the triage channel, naming who asked and who holds it. If the channel cannot be used, the holder hears privately. A confidential request never appears in a channel; its alerts are private messages.
• Ask "how many requests this week, and how are we doing on deadlines?" and the agent sends you the numbers privately: requests opened and solved, how fast the team replied, deadlines met, ratings and how often AI answers helped.
• A weekly summary can run on a schedule, asked for in plain language. Creating the scheduled task needs your approval once.

What it does not do is write your SLA. The request types, queues and SLA policies on the desk are set up with Kipwise when you start, not created by the agent from a chat message. Do not expect to type your targets into Slack and have them enforced. Bring the page you built above to the setup, and it becomes a transcription job. Also ask what "about to miss" means in your setup rather than assuming it equals 75 percent, and keep the manual check from the table until you have seen the alert fire once.

What stays with a person: choosing the targets, deciding what pauses the clock, any client-visible promise, and any credit or remedy.

Every Agent install puts the team on the Premium plan, which includes the request desk. The Agent costs $10 per user per month, or $108 per user per year, with a minimum of 3 users, and it has a $2 trial for 7 days, or a $10 trial for 14 days if you save a card or are on a paid Slack plan. People who file requests need no seat; the people who work the desk are members of one user group. The pricing page has the current terms.

When the real ask is a client contract

The head phrase "sla template" also matches people who need a signed document with credits and termination. If a client wants a written SLA with service credits, remedies or a right to terminate on repeated misses, that is a legal contract. The template you copied from a vendor blog is a starting point at best, and the vendor's own copy tells you to have a lawyer review any remedies clause before you sign. This page does not replace that.

You can make the lawyer's job smaller. Run the internal SLA first, publish a customer-facing version only once you hit it reliably, and keep the public promise to your hours and the first-reply target. Your lawyer then gets measured numbers, not hopes. For the support-escalation side, see customer support automation in Slack with approval.

Handle failure and edge cases

Weekend and after-hours requests. A four hour target at 5 pm on Friday means Monday morning to a person and Friday evening to a naive timer. Pick one of two honest options: wall-clock targets with realistic numbers, or a business-hours calendar, and write the choice in the HOURS block.

The requester goes quiet. The pause is fair; an open-ended pause is not. Set a number of days after which the request resumes or closes.

Two owners, or none. If a request has two names it has none. The 75 percent alert exists for the case where it has nobody.

Confidential requests. Alert privately, to the owner and the lead only.

A target nobody can hit. Do not tighten the people. Look at where the misses cluster. In an illustrative rollout, Drag describes a four-person team whose misses came from nobody covering lunch and from Monday backlog, and the fix was staggering lunch and assigning the backlog at 9:00. That is the author's example, not a measured study, but it shows where to look first: coverage and ownership before effort.

Verify it works

Run a two-week pilot on one request channel before you roll the page out to everyone.

• Every request has an owner within the stated window.
• The first-reply clock stops only on a human reply. Check three requests by hand against the timestamps.
• Attainment per request type is near 90 percent. At 100, check that the clock is not stopping on automatic replies. Under 70, the target is fiction or the team is short.
• At least one 75 percent alert reached a named person, and that person acted on it.
• The weekly summary arrived and matches your own count.

At the end of the pilot, change one thing: a target, a window or an owner.

What to do next

Today, export four weeks of one request channel into a sheet with type, created time and first-reply time. Compute the 90th percentile for the busiest type and write it into the first row of the template. If your requests already live on a Kipwise request desk, ask the agent "how many requests this week, and how are we doing on deadlines?" in that channel and compare its answer with your sheet.