What to Do When You Miss an SLA: A Response Framework

The single worst version of an SLA breach is one the client notices before you do. Set monitoring thresholds that flag a breach, or an approaching one, automatically, rather than relying on someone manually checking metrics against the contract terms on a schedule that's slower than the SLA itself. Being the one to surface the problem first changes the entire tone of the conversation that follows, from a client catching you out to a vendor being proactively transparent about a real issue.

The urge when something breaks is to fix it quietly and fast, then decide whether it's worth telling the client at all. Resist that instinct for anything that crosses a documented SLA threshold. Notify the client that a breach occurred, or is in progress, even while the internal fix is still underway, with a clear statement of what's happening and when they'll hear a fuller update, rather than waiting until everything is fully resolved before saying anything.

Decide the credit or remedy structure in the contract before any breach happens, and apply it the same way every time rather than negotiating a one-off response under pressure after the fact. Inconsistent application, generous with one client and stingy with another for the same type of breach, erodes trust further once clients eventually compare notes, which happens more often than most vendors expect.

A credit issued without a clear explanation of why the breach happened reads as a company buying its way out of a problem rather than actually understanding it. Include a specific, honest root cause in the client communication, along with what's changing to prevent a repeat. Vague language like 'we've identified the issue and are working to prevent recurrence' without any specifics reads as a template response, and clients notice the difference between that and a genuine explanation.

Route every breach through the same documented workflow: detection, internal fix, client notification, root cause documentation, and credit application, tracked in a tool like Process Street so no step gets skipped under the pressure of an active incident. A project tool like Wrike can hold the remediation work itself if the root cause requires a longer-term fix that spans more than the immediate incident response.

Run each breach through these steps in order:

1. Detect the breach, or an approaching one, through automated monitoring thresholds instead of a manual check against the contract.
2. Notify the client that a breach occurred or is in progress, with what is happening and when they will get a fuller update.
3. Fix the underlying issue internally and track the remediation work, including any longer-term fix.
4. Document a specific, honest root cause and what is changing to prevent a repeat, then share it with the client.
5. Apply the credit or remedy the contract defines, the same way you would for any other client.
6. Hold a short internal debrief on detection speed, notification timing, and how accurate the root cause turned out to be.

Once the client-facing part of the response is done, run a short internal review before moving on: was the breach detected as fast as it should have been, did the notification go out on time, was the root cause explanation actually accurate once the dust settled. This debrief is where the response workflow itself improves, and skipping it because the immediate fire is out means the same gaps in detection or notification timing show up again on the next breach, unexamined and unfixed.

A single breach is an incident. The same client hitting SLA issues repeatedly, even if each one is individually minor and handled well, is a signal the underlying service isn't meeting what was promised, not just an unlucky string of one-off problems. Track breach frequency per client alongside the individual incident responses, and treat a repeating pattern as its own escalation, worth a proactive conversation about the root systemic cause rather than another round of credits applied to the symptom.