Most SLAs are written to win a deal. They’re the number that looks good in a proposal, that the sales team can point to, that gives the customer the confidence to sign. And then the support team inherits them.
I’ve spent nearly two decades leading support organisations across SaaS and fintech. In that time I’ve seen SLAs designed by product teams who didn’t consult operations, by sales leaders who wanted a competitive edge, and by finance teams optimising for contract terms. I have almost never seen an SLA designed by the people responsible for hitting it — at least not at the outset.
The consequence is predictable: a team that is structurally set up to miss its targets, managing the gap between what was promised and what’s operationally possible, and using creative reporting to make the numbers look better than they are. Everybody knows the SLA isn’t real. Nobody says so. And the customer, eventually, figures it out.
Here’s how to do it properly.
Start with what your customers actually experience, not what your contracts say.
The first question in any SLA design process should not be “what did we promise?” It should be “what does a good customer experience actually look like in terms of time?”
This sounds simple. It’s harder than it sounds, because the answer varies dramatically by customer type, issue type, and channel. A billing error for an enterprise customer in the middle of a month-end close needs to be resolved in hours, not days — regardless of what the contract says about standard response times. A feature request from a trial user can wait. A security issue for any customer cannot.
The work here is segmentation. Before you write a single target, map your issue types against their actual urgency and impact. Not the urgency the customer claims — the actual urgency in terms of business impact to them. An outage affecting production is different from an outage affecting a test environment. A billing discrepancy is different from a billing question. A data loss concern is different from a display formatting bug.
Once you’ve mapped the issue types, you can start to build the tiered structure that the SLAs will sit within. Tiered SLA frameworks allow you to set differentiated response and resolution targets based on issue severity, customer tier, or both — which means you stop averaging together things that should never have been averaged.
The case for tiering by both severity and customer.
Most operations tier by one dimension — either issue severity (P1/P2/P3) or customer tier (Enterprise/Growth/Starter). The better-designed operations tier by both, because severity and customer tier are independent variables that combine to produce the real priority.
A P2 issue for an enterprise customer on a premium support contract is not the same as a P2 issue for a trial user. Treating them identically in your SLA framework means you’re either over-serving the trial user or under-serving the enterprise customer — and in practice it usually means both, because the team will triage based on relationship rather than documented policy, and the documented policy will stop being useful as a management tool.
The matrix approach — severity on one axis, customer tier on the other, with defined response and resolution targets in each cell — gives you a framework that is both defensible to customers and actionable for your team. It’s more complex to build and communicate than a single-tier SLA. It’s also more honest about the reality of how your operation works and needs to work.
A note on resolution targets specifically: resolution is much harder to target than response, because resolution time is often driven by factors outside the support team’s control. Engineering queues. Third-party dependencies. Customer cooperation. Build your resolution SLAs with those dependencies documented, and distinguish clearly between time-to-resolution (which you own entirely) and time-to-closure (which you don’t).
Design for your team’s operational reality.
Here’s the test I apply to any SLA before we commit to it: can my team hit this target on a bad day?
Not on the best day. Not when the queue is light and all hands are on deck. On a bad day — when two people are out, when there’s an incident running, when the volume is higher than forecast. If the answer is no, the SLA isn’t a target — it’s a ceiling you’ll spend your energy explaining why you missed.
This is where staffing and SLA design need to be done together, not sequentially. First contact resolution targets, response time commitments, and coverage hours all have direct staffing implications. An SLA that requires a two-hour response window during business hours implies a minimum staffing level to maintain that window consistently. If the staffing budget doesn’t support that level, the SLA needs to change — not the team.
I’ve sat in enough QBRs where an ops leader apologises for SLA misses that were structurally predetermined to know that this is a common and avoidable problem. The miss wasn’t a performance failure. It was a design failure — an SLA built without the staffing model that would have been required to hit it. The fix is not to work harder. The fix is to redesign the SLA, or fund the staffing, or both. The budget conversation is uncomfortable. It’s less uncomfortable than consistently missing your targets.
Make SLAs visible and tie them to behaviour.
An SLA that lives only in a contract and a monthly report is not a management tool. It’s a document. For an SLA to drive behaviour, your team needs to see it — in their queue, in their tooling, in their daily work — and they need to understand why it matters.
Practically, this means SLA breach alerting built into your ticketing system. It means dashboards that are visible to agents, not just managers. It means a shared understanding of the priority matrix — which issues need to be jumped on, which ones can wait, and what happens if the queue is backing up at the P1 level.
It also means calibration. On a regular cadence — monthly at minimum — review a sample of tickets against your SLA framework. Are things being prioritised correctly? Are escalations happening at the right thresholds? Are there issue types that are consistently misclassified? The taxonomy you designed on paper will drift in practice. The calibration sessions are how you catch it early.
And review the SLAs themselves annually. Your customer base changes. Your product complexity changes. Your team’s capability changes. An SLA designed for your operation two years ago may be meaningfully wrong for your operation today — either too conservative to be differentiating, or too aggressive to be achievable. The discipline of annual review prevents the slow calcification of targets that no longer reflect how the business works.
Good SLA design is, at its core, an exercise in honest alignment. It’s the process of agreeing — internally between operations, finance, and commercial, and externally with customers — on what service levels are actually achievable, actually valuable, and actually meaningful as a measure of quality.
When that alignment exists, SLAs do what they’re supposed to do: they set clear expectations, drive the right team behaviours, and give customers a reliable signal of what they can count on. When it doesn’t exist, they become a bureaucratic exercise in explaining misses that were predictable from the moment the targets were set.
Do the hard work up front. The calibration, the segmentation, the staffing modelling, the internal negotiation. It takes longer than copying a competitor’s SLA and calling it done. But it produces something you can actually operate against — which is the whole point.
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.