When an SLA is breached, five steps should be followed: alert the team and appoint an owner, analyze the cause, inform the customer, restore the service and communicate the resolution. But the most effective approach is to prevent the breach in the first place, with alerts before the deadline, automatic escalations and defined owners for each stage. Those owners include the internal teams and suppliers involved, through OLAs and UCs. The sections below explain each step, with examples of alerts and escalations.
- What does it mean when an SLA is breached?
- How can an SLA breach be prevented?
- Who is responsible at each stage?
- What is the relationship between SLAs, OLAs and UCs?
- What should be done if an SLA is breached?
- What should be reviewed after a breach?
- What sets ServiceTonic apart in SLA management?
- Frequently asked questions
- Conclusion
What does it mean when an SLA is breached?
An SLA (service level agreement) sets the maximum time allowed to respond to a request and to resolve it, depending on its priority or the type of service. It is breached when one of those deadlines is exceeded. This can happen with the first response deadline, the resolution deadline or both. SLAs can be based on the type of service, the customer or the type of contact. What is an SLA explains them in more detail.
A one-off breach is not necessarily serious, but not knowing why it happened or who should have prevented it is.
How can an SLA breach be prevented?
The most effective way is to define a sequence of alerts and escalations that is triggered before the deadline, not after it. This is an example for a resolution SLA, which each organization can adjust:
| Point | Alert | Recipient | Expected action |
|---|---|---|---|
| 50% of the deadline used | Visual alert on the ticket | Assigned technician | Review the status and estimate wether it will bo on time |
| 75% of the deadline | Email alert | Technician and group coordinator | Reassign or ask for help if the ticket is blocked |
| 90% of the deadline | Escalation | Supervisor or second level | Take control of the case and prioritize it |
| Deadline reached | Breach notification | Service manager | Start the restoration steps and inform the costumer |
It is also important to configure SLAs so they measure what really depends on the team. For example, pausing the timer while the ticket is waiting for the customer to respond, and applying the support hours that correspond to each service.
Who is responsible at each stage?
| Owner | Responsibility |
|---|---|
| Assigned technician | Resolve the ticket within the deadline and warn if that will not be possible |
| Group coordinator | Distribute the workload and reassign tickets that are at risk |
| Supervisor or second level | Take on escalated cases and unblock them |
| Service manager | Manage the breach, inform the customer and review the causes |
| Internal teams (OLA) | Meet the deadlines agreed with the service desk, for example Systems or Development |
| External suppliers (UC) | Meet the deadlines in their underpinning contract |
What matters is that each alert has a recipient who is able to act. An alert sent to the whole team at once usually ends up with no owner.
What is the relationship between SLAs, OLAs and UCs?
- SLA: the agreement between the service provider and the customer or user.
- OLA (operational level agreement): the agreement between the service desk and another team within the same organization that is involved in resolution.
- UC (underpinning contract): the contract with an external supplier that provides part of the service.
OLA and UC deadlines must make it possible to meet the SLA. For example, if the SLA with the customer sets 8 hours to resolve a hardware fault, but the supplier has 24 hours to send the part, that SLA will be breached every time the part is needed. Operational Level Agreement OLA/UC explains both agreements.
What should be done if an SLA is breached?
- Alert the team and appoint an owner. As soon as the breach notification arrives, identify who is responsible for restoring the service. For example, if a repair is not ready because the team is overloaded, find someone who can handle it urgently.
- Analyze the cause before acting. Are resources lacking? Does the workload need to be redistributed? Does it depend on an internal team or a supplier? Acting without knowing the cause often leads to rushed solutions.
- Inform the customer. Transparently and with a solution underway: what has happened, what is being done and when it will be resolved.
- Restore the service. With the necessary resources and top priority.
- Communicate the resolution. Confirm that the service is working, thank the customer for their understanding and, if appropriate, offer compensation.
Example: an SLA about to be breached
A high-priority ticket arrives at 9:00 a.m.: a customer’s billing system is not generating invoices. Its resolution SLA is 4 hours.
| Time | What happens |
|---|---|
| 9:00 | The ticket is logged and assigned to the Applications group. The SLA timer starts. |
| 11:00 | 50% of the deadline has been used and an alert appears on the ticket. The technician finds that the fault is in the database. |
| 12:00 | With 75% used, the coordinator receives an alert and escalates the case to the Systems team, which has a 1-hour OLA for this type of incident. |
| 12:30 | With 90% used, the supervisor takes control of the case. Systems confirms that the database supplier is needed. |
| 13:00 | The SLA expires. The service manager informs the customer of the cause and the expected resolution time. |
| 13:45 | The supplier applies the fix, the service is restored and the resolution is communicated to the customer. |
What should be reviewed after a breach?
- Was the SLA realistic? If it is breached often, the deadline may not match the resources available.
- Did the alerts and escalations work? Did they arrive on time and reach the right person?
- Could the cause happen again? If so, it should be treated as a problem, not just an incident.
- Are the OLAs and UCs aligned with the SLA?
- How did the customer experience it? A survey after resolution helps find out.
- What needs to change? Deadlines, alerts, resources or agreements with third parties.
What sets ServiceTonic apart in SLA management?
ServiceTonic includes service level management (SLA) that automatically assigns the right SLA to each ticket and sends visual alerts and emails before each deadline expires. SLAs are configured without programming: by service, customer, contact type or priority, with their own support hours and with pauses while the ticket is waiting for a response. OLAs and UCs are linked to each SLA and tracked separately, and dashboards show compliance in real time. All of this is integrated into the help desk software and incident management.
Frequently asked questions
What happens if an SLA is breached?
It depends on what the agreement states. It may have no contractual consequences or it may involve penalties, such as discounts or compensation for the customer. In any case, the service should be restored as soon as possible, the customer should be informed and the cause should be analyzed so it does not happen again.
What is the difference between an SLA, an OLA and a UC?
The SLA is the agreement with the customer or user. The OLA is the agreement with another team within the same organization that is involved in the service. The UC is the contract with an external supplier. OLA and UC deadlines must make it possible to meet the SLA.
When should alerts be sent before an SLA expires?
At several points, for example at 50%, 75% and 90% of the deadline, with different recipients for each alert. This leaves time to reassign or escalate the ticket before the deadline.
Does the SLA stop while the ticket is waiting for the customer to respond?
It can be configured that way. In ServiceTonic, the SLA timer can be paused while the ticket is waiting for the customer to respond, so the metric only measures the time that depends on the support team.
Who is responsible for a breached SLA?
The service manager is accountable to the customer, but the cause may lie at any point in the chain: the assigned technician, an internal team with its OLA or a supplier with its UC. That is why each alert and escalation should have a defined owner.
Conclusion
An SLA is not breached at the moment it expires, but much earlier: when a ticket is left without an owner, when an alert reaches someone who cannot act or when a supplier has a longer deadline than the SLA itself. That is why the best way to reduce breaches is not to react better when the deadline hits, but to review the whole chain of deadlines and owners before it is needed.
Would you like to see how SLA alerts and escalations work in ServiceTonic? Request a demo and see how to configure your SLAs, OLAs and UCs without programming.