Most support teams have an SLA and stop there. They promise a first response in an hour, they measure whether they hit it, and at the end of the month they either celebrate or wince. What they're missing is the layer in between — the internal target they actually manage to day-to-day, and the small allowance for misses that turns a static promise into a tool for deciding what to do next. Borrowed from the way reliability engineering manages uptime, this layer is the difference between a number you report on and a number you run the team with.
Three words that get used as one
The terms get blurred together, so it's worth separating them cleanly, because each does a different job.
- SLA — the promise. The commitment you make to the customer, often with consequences attached: "first response within one business hour." It is external-facing, sometimes contractual, and you do not want to breach it. How to write good ones is its own discipline — see designing SLA policies.
- SLO — the objective. The internal target you actually manage to, set tighter than the SLA so you have headroom. If you promise customers an hour, you might run the team to a 40-minute objective. The gap is your safety margin.
- Error budget — the allowance. One hundred percent compliance is the wrong target; chasing it costs far more than it returns and burns people out. So you set the SLO at, say, 98%, which means 2% of tickets are allowed to miss. That 2% is your error budget — a quantity you get to spend, not a failure to feel guilty about.
The SLA is what you owe. The SLO is what you aim for. The error budget is what you're allowed to miss while still keeping the promise.
Why the budget is the useful part
The error budget reframes a miss from a moral failing into a resource. A team operating well under budget — barely any misses — is a team with room to spend: room to take on a hard migration, run training that pulls agents off the queue, or absorb a launch spike without panicking. A team that has blown through its budget is a team that should stop adding load and fix something structural before promising anyone anything new.
This is the whole point: the budget converts your SLA compliance data into a decision. Instead of "are we good or bad this month," the question becomes "how much budget is left, and what should we spend it on?" When the budget is healthy, you can say yes to risk. When it's gone, the data gives you the standing to say no — to a new channel, a new tier, a feature launch you can't yet support.
How to set the objective honestly
An SLO pulled from thin air is worse than none, because the team learns to ignore it. Set it from reality.
- Start from your current performance. Pull the last quarter of SLA compliance. If you're hitting first response inside target 96% of the time today, a 99% SLO is a fantasy that will just generate guilt. Set the objective slightly above where you are, so it pulls without snapping.
- Tighten the objective inside the promise. The SLO should be measured against a target stricter than the SLA. Manage to 40 minutes so the occasional bad day still lands inside the one-hour promise. The margin between SLO and SLA is what absorbs variance.
- Set different objectives for different work. A VIP tier and a free-trial user do not deserve the same objective, and a priority-one incident is not a billing question. Tie your objectives to your prioritization matrix so the budget is spent where it matters least and protected where it matters most.
- Measure the clock the customer actually feels. Business-hours-aware SLAs with stop-the-clock on customer wait are the only honest basis for an objective — penalizing the team for the hours your office is closed or for time spent waiting on the customer just teaches everyone to game the metric.
Spending the budget on purpose
A budget you never spend is a target set too loose. If you end every month with the budget almost untouched, you are either over-staffed for the promise or the promise is far weaker than what you actually deliver — in which case you could tighten the SLA and turn that slack into a competitive edge. The goal is not zero misses; it is to spend the allowed misses deliberately. Spend it on the backlog drain that needs people off the live queue for a day. Spend it absorbing a product launch spike. Spend it on the training that makes next quarter's compliance effortless. What you should never do is blow the budget by accident and discover it only in the month-end report.
Report it as a budget, not a grade
When you take SLAs to leadership, the budget framing lands harder than a raw percentage. "We were at 97.2%" invites a shrug or a nitpick. "We've used 80% of this quarter's error budget with three weeks left, driven mostly by the billing-integration incidents" is a sentence that gets a staffing or engineering decision made. Fold the budget into how you report to leadership: it shows you are managing a resource, not just surviving a metric, and it makes the case for help before the budget is gone rather than after.
The honest test
You're running SLOs and error budgets well when a missed SLA no longer triggers a witch hunt — it triggers a glance at the budget. A single miss inside a healthy budget is a non-event; a string of misses that drains the budget is an early-warning signal that gets acted on while there's still time. If instead every breach is treated as an individual catastrophe and your team has no idea how much room they have left before the promise to customers is actually at risk, you have an SLA but no way to manage it. The objective tells you where to aim; the budget tells you when to stop and fix something. Together they turn a number you report into a number you run the team with — every plan includes business-hours SLA management and the compliance reporting the budget depends on.