SLA breach prediction

A breach prediction is a list of tickets that will miss their target unless something changes. The only useful question about that list is what the something is. If the answer is that a manager will look at it when they have time, the model has produced anxiety and nothing else.

Name the interventions before building anything. Reassign to someone free. Pull a subject expert in for ten minutes. Send an honest holding update. Downgrade a target that was never realistic. Ask the customer for the missing detail that has stalled the ticket. Each one costs somebody's time, and the sum of those costs is the real capacity of this system.

This is expensive to build and modest in value, which is an honest description rather than a criticism. Most of the cost is in getting clean clock data and in wiring an intervention path that a shift lead will actually use. The model itself is the easy part.

A warning also does not reorder the queue by itself. It creates a worklist for one person. Anything that silently promotes predicted breaches will starve the tickets whose clocks look comfortable, and those tickets belong to customers too.

Most support tools already track first response and resolution targets, and most of those clocks are messier than anyone admits. Pauses, business hours, holiday calendars, and pending-customer states all stop and start the timer. A model trained on raw elapsed time will learn the wrong thing about every paused ticket.

Reconstruct the timeline the way the SLA policy defines it, not the way the database stores it. Every state change, with a timestamp and the reason. If the tool cannot export the pause history, the prediction cannot be trusted, and the honest move is to fix the clock before training anything.

Features worth having are unglamorous. Time already consumed against the target. Number of reassignments so far. Whether the ticket is waiting on the customer or on the team. Queue depth in the assigned group. Shift coverage over the remaining window. Whether the ticket belongs to a known incident.

The ticket's category matters, because different work has different natural durations, and it should come from the same field the routing uses. Take it from the classifier that assigns categories for downstream routing rather than deriving a second label here.

If the SLA policy itself is undefined for a queue, do not predict. A target nobody agreed on cannot be breached, and a forecast against an imaginary deadline will still generate warnings that people act on.

A warning that arrives an hour before the deadline is a notification, not a forecast. The value sits in the window where something can still be done, which for most queues means at least a quarter of the target remaining. Set the lead time first and design backward from it.

Re-run the prediction whenever the ticket changes state. A reassignment, a customer reply, a pause, or a new incident link all change the picture. Tickets should be able to leave the warning list as well as join it, and a list that only grows during a shift will be abandoned by lunchtime.

Display the hours remaining beside the risk value, and the top contributing factor beside both. Nine hours left, waiting on the team, third reassignment. A shift lead can triage that line in seconds. A percentage on its own tells them nothing they can act on.

Sort the warning list by hours remaining, not by risk value. The tickets with the least time left are the ones where an intervention is still possible and nearly out of runway. A list sorted by confidence puts hopeless cases at the top.

Cap the list length. A shift lead can work a handful of tickets per hour on top of their other duties. Show that many, and let the rest sit unshown rather than presenting a page nobody will finish.

The situation below is fictional. A university IT helpdesk supports students and staff, with a four-hour first-response target during term and a two-day resolution target for account issues. The first fortnight of autumn term is the busiest stretch of the year.

On the Monday of week one the model flags forty-three tickets as likely to miss the resolution target. The shift lead has capacity for roughly a dozen interventions across the day. Forty-three warnings against twelve slots is not a model problem. It is a staffing fact the forecast has made visible.

Sorted by hours remaining, the top of the list is dominated by one pattern: new-student account activations stuck waiting on an identity check that only two staff members can perform. Nineteen of the forty-three share that factor. That is one intervention, not nineteen.

The lead puts a third person on identity checks for the afternoon and sends a single honest update to all nineteen. Eleven of the remaining twenty-four are password and access issues that a first-line agent can close in minutes once someone points at them. The rest are genuinely long, and the lead extends the target on four of them with a note explaining why.

Nothing on the list moved position automatically. The warning produced a decision by a named person on a named shift, and the identity-check bottleneck went into the following week's capacity plan. The clustering that made the pattern visible is the same idea used by grouping tickets that share an underlying cause.

The failure modes here are less about accuracy and more about what people do with the output.

Warnings become the queue. When agents work the flagged list first, tickets that were comfortably on track start slipping, get flagged, and join the list. The system then predicts breaches it helped create. Keep the flagged list as a separate view worked by one person, not as the ordering everyone follows. The same caution applies to any score that reorders a shared queue.

Clock gaming replaces resolution. Once a warning is visible, the cheapest way to clear it is to set the ticket to pending-customer and stop the timer. Watch the rate of pause transitions on flagged tickets. A rise there is the clearest sign the metric has replaced the work.

Individual accountability creeps in. A breach forecast attached to an agent's name turns a capacity signal into a performance review, and agents respond by avoiding hard tickets. Report the list by queue and by cause. Whether an individual is struggling is a coaching conversation with different evidence.

Seasonal patterns break the model. A helpdesk trained on quiet months will underestimate everything during a peak, exactly when the forecast would be most useful. Retrain on data that includes the peaks, and expect the first peak after launch to be the least reliable.

One named person per shift owns the flagged list, and their decisions are the output of this system. They choose which tickets get an intervention, which get a holding update, and which are accepted as late. That last option must exist, because a queue with more risk than capacity has to lose something on purpose.

Changing an SLA target is not a shift-level decision. Extending a deadline, pausing a clock, or moving a ticket to a different policy needs the support manager who owns that policy, and it gets a written reason. Otherwise the easiest way to hit a target is to move it.

Reassignment triggered by a warning still goes through the normal path. A predicted breach is a reason to look for a better owner, and the choice of owner belongs to the routing that weighs queue depth and shift coverage. Bypassing that to hand the ticket to whoever is idle moves the problem rather than solving it.

Review the misses monthly with the leads who worked the list. Two questions matter: which warnings arrived too late to act on, and which breaches were never flagged. The second group is where the real learning sits, and it is usually made of tickets that looked ordinary until a dependency failed.