The SLA breached while the ticket sat in a queue
Nobody was watching the clock until it had already run out, and the first person to notice the breach was the customer who was owed the credit.
What actually happens
Service level reporting tells you what you owe. It is not a control, and treating it as one is why the credits keep appearing.
A ticket is raised and enters a queue with a response and resolution commitment attached. The clock starts.
It sits. Not because anyone is negligent, but because it is one of many, the queue is prioritised by severity rather than by remaining time, and a medium-severity ticket with two hours of budget left ranks below a high-severity ticket with two days.
That prioritisation is defensible right up until the medium-severity ticket breaches, at which point it becomes obviously wrong in hindsight and will be repeated next week because the underlying ordering has not changed.
The breach surfaces in the monthly service review. By then the credit is owed, the customer has already experienced the delay, and the conversation is about compensation rather than about service.
The reporting is accurate and completely useless as a control, because it operates a month after the only moment when anything could have been done.
Prioritising by severity is prioritising by how bad it is, not by how close it is. Those are different questions and only one of them has a deadline attached.
The same commitment, two ways
The comparison is between a queue ordered by severity and a queue that also knows how much time each ticket has left.
Illustrative, not measured. The times below model a scenario built from the patterns we see in production estates. They are not timings recorded at a named customer. The point is the shape of the clock, not the totals: check it against your own last ten incidents.
Today, ordered by severity
- T+0Ticket raised. Resolution commitment attached. Enters the queue at medium severity.
- T+0 ↓ T+70%WaitingHigher severity tickets take priority. Ticket ages quietly. No signal is generated by ageing alone.
- T+95%WaitingStill queued. Nothing distinguishes it from any other medium-severity ticket.
- T+100%Commitment breached. Ticket still open.
- T+2 daysResolved. Breach recorded.
- Month endWaitingBreach appears in the service review. Credit owed. Customer already knows.
Breach found in reporting · a month after it could have been prevented
With trajectory watched, not just severity
- T+0Ticket raised. Sentinel tracks remaining commitment alongside severity from the moment it enters the queue.
- T+55%Trajectory projected from current queue position, comparable ticket handling times and available capacity.
- T+55%Projection indicates breach is likely. Ticket surfaced while there is still budget to act.
- T+57%Options presented: reprioritise, reassign to available capacity, or accept with the customer informed in advance.
- T+60%Service manager reprioritises. Ticket moves up the queue with the reason recorded.
- T+80%Resolved inside commitment. No credit owed and no surprise at month end.
Surfaced with budget remaining · while a decision was still possible
The number here is simple and your service management team already has it: credits paid per period. Every one of those is a ticket that was visible in a queue while there was still time.
The reason severity-ordered queues breach is arithmetic rather than cultural. Severity is a property of the ticket and remaining time is a property of the clock, and ordering by only one of them guarantees that the other is occasionally ignored until it is too late.
The mechanism is projecting trajectory rather than reporting elapsed time. A ticket at fifty-five percent of its budget is not interesting on its own; a ticket at fifty-five percent whose queue position and comparable handling times imply a breach is a decision that needs making now.
Presenting the option to inform the customer in advance matters as much as the reprioritisation. A commitment that is going to be missed is much cheaper as a proactive conversation than as a line in a monthly report.
Why the number is what it is
The number here is simple and your service management team already has it: credits paid per period. Every one of those is a ticket that was visible in a queue while there was still time.
The reason severity-ordered queues breach is arithmetic rather than cultural. Severity is a property of the ticket and remaining time is a property of the clock, and ordering by only one of them guarantees that the other is occasionally ignored until it is too late.
The mechanism is projecting trajectory rather than reporting elapsed time. A ticket at fifty-five percent of its budget is not interesting on its own; a ticket at fifty-five percent whose queue position and comparable handling times imply a breach is a decision that needs making now.
Presenting the option to inform the customer in advance matters as much as the reprioritisation. A commitment that is going to be missed is much cheaper as a proactive conversation than as a line in a monthly report.
The mechanism is projecting trajectory rather than reporting elapsed time.
Who decides to press go
Reprioritising a queue changes which customer waits, so it is a service management decision rather than an automated one.
Trajectory projection, breach prediction, capacity analysis and option generation all run under policy. None of them reorder anything.
The options are presented to the service manager with the projected outcome for each, including which other commitments are affected. The reprioritisation and its reason are recorded with the decision.
Recording the reason matters more than it sounds. A queue reordered without a recorded rationale is indistinguishable from a queue reordered by whoever escalated loudest.
Tickets ageing toward their commitments in a queue ordered by severity. Ageing alone generates no signal.
Trajectory projected per ticket from queue position, comparable handling times and available capacity. Likely breaches identified while budget remains.
Options presented to the service manager: reprioritise, reassign, or inform the customer in advance. Decision and reason recorded.
Handling time model updated from actual outcomes. Recurring breach patterns by ticket type surfaced for capacity planning rather than handled ticket by ticket.
This is a platform capability, not a published customer deployment for this exact scenario. The mechanism, which is cross-system correlation followed by governed MOP execution with pre-check, post-check, rollback and approval gating, is running in production today across managed estates; see governed day-2 operations across 2,000+ nodes and closed-loop network automation. The timings shown are modelled, not measured at a named customer.
If the action carries no service impact
Trajectory projection, breach prediction, capacity analysis and option generation all run under policy. None of them reorder anything.
If it reprioritises or reassigns work
The options are presented to the service manager with the projected outcome for each, including which other commitments are affected. The reprioritisation and its reason are recorded with the decision.
What Sentinel did, step by step
- ObserveTickets ageing toward their commitments in a queue ordered by severity. Ageing alone generates no signal.
- InvestigateTrajectory projected per ticket from queue position, comparable handling times and available capacity. Likely breaches identified while budget remains.
- ActOptions presented to the service manager: reprioritise, reassign, or inform the customer in advance. Decision and reason recorded.
- OptimizeHandling time model updated from actual outcomes. Recurring breach patterns by ticket type surfaced for capacity planning rather than handled ticket by ticket.
Bring us last quarter of service credits
We will show how long each ticket was visible before it breached.