Internal Service SLA Template
Three documents and three sheets that set a response target for every request type from what your team has actually delivered, not a guess.
Free download · No account needed
SLA Target by Request Type
Bramwell Foods, Data & Reporting team, 175 requests this quarter
| Old target | One flat 16-hour promise for every request type |
| Old breach rate | 37.1% overall — 0% to 100% depending on type |
| New target | Each type's own 80th percentile response time |
Same quarter, five targets instead of one
| Request type | Old flat target, 16h | New target | New breach rate |
|---|---|---|---|
| New report build | 100.0% breached | 85.8h | 21.1% |
| Dashboard change | 63.4% breached | 38.7h | 19.5% |
| Bug fix | 41.7% breached | 20.6h | 20.8% |
| Ad hoc data pull | 17.2% breached | 15.7h | 19.0% |
| Access request | 0.0% breached | 7.4h | 21.2% |
Access requests never once breached the old target and get a tighter one. New report builds always breached it and get a longer one. Same 16 hours, opposite problem, for five request types nobody had actually separated.
Search this and every result assumes a support desk: priority tiers named Critical, High, Medium, Low, each with a response time chosen because it sounded proportionate for a customer-facing ticket. Internal SLAs use the exact same mechanics as customer-facing ones, carried over wholesale. That fits an IT helpdesk triaging incidents by urgency. It fits nothing about a data or reporting team fielding five completely different kinds of work, where a twenty-minute access grant and a four-day report build were never the same promise wearing a different label.
The best advice on page one gets halfway there: use your own current average response time as the baseline, then set the initial target slightly tighter than that. An average still blends every request type into one figure, and a right-skewed distribution's average sits well above where most requests actually finish, so the resulting target's real breach rate stays undisclosed. The same reasoning engineers use for latency targets applies here: a percentile shows the shape of a distribution; a single average obscures the tail entirely.
Bramwell Foods' three-person Data & Reporting team tested this on 175 real requests logged in one quarter. One flat 16-hour target for everything breached 37.1% overall, and that average hid the real story: 0.0% for access requests, 100.0% for new report builds. Five targets, each a type's own 80th percentile, produced a designed, disclosed 20.0% breach rate on every type at once, the same discipline a process map applies to queue time and the decision rights pack applies to an escalation.
What's in the pack
SLA Target by Request Type
Every request type's real P50, P80 and P95 response time from your own history, the old target's actual breach rate against the same data, and the new target's breach rate by construction. The comparison is computed, not estimated.
Why the 80th percentile, not the average
An average gets pulled around by the slowest outlier in the sample and blends request types that are not the same work. The 80th percentile of one type's own history is both achievable, since four in five past instances already cleared it, and honest about the fifth.
Volume Trend
Monthly request volume by type, so a rising queue shows up as a number before it shows up as a missed quarter. The same sheet says which request type is driving the growth, which is usually not the type anyone assumed.
Breach Log
One row per miss against the new targets, with a one-line reason and no individual review for a single occurrence. A reason code appearing three or more times in a rolling quarter is the one that gets pulled out and fixed.
Service Catalog
The request types defined precisely enough that classification doesn't drift between whoever is logging them, with what to include in a request so the clock starts on complete information instead of a follow-up question. A structured intake form is what actually gets that information captured on the way in.
SLA Definitions
The policy document stating each target, its derivation, and its expected breach rate in plain language, so the team publishing it and the department reading it agree on what the number actually promises.
Breach Procedure
What happens on a single miss (the requester gets a status update, the reason gets logged, nothing else) versus a repeated reason (a real review, routed to whichever side of the handoff the reason actually sits on).
How to use it
- 1
Open in River, or download it
Install the pack and hand River your request history, or download all three documents and three sheets blank and run the percentile calculation yourself.
- 2
Send the request history
A shared inbox, a Slack channel export, a spreadsheet log, or a ticketing tool export, with an open and close time on every request.
- 3
Let the percentile set the target
Every request type gets classified and its own P50, P80 and P95 computed. The 80th percentile becomes the published target for that type.
- 4
Publish the definitions, log what's next
The targets become the SLA Definitions, and every future request gets logged so next quarter's recomputation runs on real, growing history.
Frequently asked questions
Is this free, and what do I get?
Free, no signup needed for the download: three documents and three spreadsheets. The AI half is optional. Send River your request history and it computes the per-type percentiles and drafts the definitions for you. More in the template library.
Why not just set one target for everything, like two business days?
Because request types are not interchangeable units of work. In the worked example, one flat target breached 0% of the time for access requests and 100% of the time for new report builds. A number that is always right for one type and always wrong for another was never a real target.
Isn't a 20% breach rate too high for an SLA?
It depends entirely on where the target came from. Against an aspirational number, any breach looks like a failure. Against a chosen 80th-percentile target, a 20% breach rate is the design, stated up front, not a number to be embarrassed about or to quietly stop measuring.
What if a request type doesn't have enough history yet?
Under roughly fifteen closed requests, the percentile is too thin to trust. That type inherits the closest comparable type's target as a stated placeholder until it accumulates enough volume, rather than getting a number invented to fill the row.
How is this different from a customer support SLA?
Support SLAs segment by urgency tier, Critical through Low, because the underlying work is genuinely similar and only the stakes differ. Internal requests segment by type instead, because a bug fix and a new report build are different work regardless of how urgent either feels.
What does Edit with AI actually do?
Creates a free account, installs this exact pack as a private space, and primes the agent to read whatever request history you send. Nothing gets computed until you send something, and the blank pack is always there to download instead.
Set targets your team can actually hold
Take the documents and sheets blank, or install this pack in River and send it a quarter of your own request history.
Edit with AI