Never sign a customer SLA until every team that has to deliver it has agreed, in writing, to a faster internal one. That’s the rule. The reason it keeps getting broken has very little to do with support and a lot to do with how the promise gets made: Sales negotiates it, the customer’s procurement team pushes it tighter, somebody signs it, and support finds out what was promised when the first breach lands. I’ve seen a 4-hour, 24/7 customer SLA go out the door with engineers behind it who were only available the next business day. I’ve written about why every internal SLA in the chain has to be faster than the external one, and that’s the mechanics. This post is about the conversation that has to happen before the contract goes out, and who needs to be in the room for it.
The good news is that the conversation isn’t complicated. The bad news is that it’s usually uncomfortable, because it means telling a salesperson with a deal on the table that the promise they want to make can’t be kept yet. Have it anyway. That conversation is uncomfortable. It’s a lot less uncomfortable than explaining the service credits to your CFO a quarter later, and far less uncomfortable than explaining to a customer why the SLA they bought turned out to be fiction.
Where does a customer SLA go wrong?
It goes wrong at the point of sale, not at the point of delivery. The people making the promise are rarely the people keeping it, and nothing in most sales processes forces the two groups to compare notes. A buyer asks for 4-hour resolution around the clock. It sounds reasonable, the competitor says they offer it, and nobody at the table asks who picks up a Priority 1 at 3am on a Sunday. The contract doesn’t care that your development team works office hours. The customer’s clock starts when they log the ticket. It doesn’t pause for a weekend, a holiday or an escalation queue nobody is watching. So by the time support realizes nobody on the development side is covered overnight, the promise has already been sold at a price that assumed they were.
Then the bill arrives. SLAs usually carry service credits, and in outsourcing contracts the money for them typically comes from a slice of the monthly fee put at risk, often sized to roughly the provider’s profit margin. Read that again. A customer SLA you can’t meet can quietly erase the margin on the very account it helped you win. That’s the “you will lose money” half of the problem. The “you will lose customers” half follows close behind, because a customer who’s been credited three months running isn’t thinking about the credit at renewal time. They’re thinking about the outages.
Inside the building, it looks like a support team permanently firefighting escalations it had no say in. Engineers get dragged off planned work to chase a clock they never agreed to, and everyone ends up resenting the SLA instead of the sale that created it. The fix is simple enough to say: give customers one SLA and peg your internal SLA to a higher standard. Everyone agrees with that in principle. The whole trick is getting it agreed before the signature, not after.
How do you run the gap analysis before you sign?
Start with the proposed customer SLA and go through it line by line. For each commitment, name the team that actually delivers it, write down that team’s current internal SLA, and write down the hours it covers. An internal SLA is simply an agreement between departments inside the business, and if one doesn’t exist for a line, that’s your first finding. Then compare. Anywhere the internal target is slower than the customer promise, or the covered hours are fewer than the hours you’re selling, you’ve found a gap. If you already run a tiered SLA matrix, do this for every cell your new customer will sit in, not just the headline one.
Get the right people around that table: Sales, support, engineering, and development if code changes are ever part of a fix. Each team sets its own internal target with the customer number in front of it, because a target handed down from above is a target nobody owns. Make those targets realistic but aggressive. If the customer SLA promises 4-hour resolution, engineering should be aiming for 2 to 3 hours, not 4, because the ticket also has to travel through triage and possibly development before it’s fixed. Then measure against it every month and adjust. A target set once and never looked at again is just a number in a contract. Volumes change, products change and teams get reorganized, and every one of those can quietly open a gap that wasn’t there when the SLA was signed.
Write the result up in one page before anything goes out to the customer. This is your ammunition for the conversation with Sales and senior management. It shows, in their language, which lines of the SLA are backed, which aren’t, and what it would cost to back them. Keep it to one page, because nobody in a deal review reads page two.
What can you do when the gap won’t close?
You’ve got two levers, and you should pull at least one of them before the contract goes out. The first is investment. How much are you and your company willing to invest in protecting yourself from the 20% of problems your frontline and Tier 2 teams can’t solve alone? That can mean a rotating on-call schedule for engineering and development, extra staff for nights and weekends, automated monitoring that detects and escalates faster than a person can, and cross-training your Tier 1 team so fewer tickets need engineering at all. Every one of those has a price. Like everything else, there are things you can do and things you can’t, so decide which one gives you the best bang for your buck.
The second lever is the promise itself. If the business won’t fund 24/7 development cover, then 24/7 resolution isn’t something you can sell. Maybe it’s 24/7 response with business-hours resolution, or round-the-clock cover only for Priority 1 incidents. Sales needs to hear that from you before the customer hears it from a breach report. It helps to have a real disaster recovery plan behind the biggest promises too, because a 4-hour SLA means nothing on the day the whole platform is down. Your customer SLA is a promise made on behalf of people who weren’t in the sales meeting. Make sure they’d have signed it too.
Frequently Asked Questions
What is a customer SLA?
A customer SLA is the service level agreement you sign with a customer, setting targets such as response time, resolution time and hours of coverage. It’s usually backed by service credits or penalties if you miss it. It’s only achievable if the internal teams behind it have agreed to faster targets of their own.
Who should approve a customer SLA before it’s signed?
Sales, support and every team that delivers part of the service, which usually means engineering and often development. Senior management needs to sign off on any gap between what’s being sold and what’s currently backed, because closing it costs money.
What happens if you breach a customer SLA?
Most contracts pay out service credits, often drawn from a portion of the monthly fee that’s been put at risk. Repeated breaches also damage the relationship, and customers who’ve been credited month after month are far more likely to leave at renewal.
Should an internal SLA be stricter than the customer SLA?
Yes, always. The internal target has to leave room for triage, handoffs and time spent waiting between teams. Against a 4-hour customer resolution, a 2 to 3 hour engineering target is a sensible starting point.
Hutch Morzaria is a CX and Support Leadership professional with 19 years of experience building and leading support organizations across SaaS, Fintech, and enterprise technology. He has held Director-level roles at Q4 Inc, AudienceView, Johnson Controls, and others, and holds ITIL Expert certification across V3 and V4.
