Every service desk reports SLA attainment. Few can say, at nine in the morning, which open tickets will breach by the afternoon. The data to do so is not exotic: it is the ticket's age, its priority, how recently anyone commented, how loaded the assigned team is, and how similar tickets behaved before.
Six questions, six models
On a real ITSM estate — the IT function of a Gulf real-estate group — we built an intelligence layer around six models, each answering a question the desk already asks by hand.
Six models and the question each answers
From our GCC & IT services case study
| Model | The question it answers |
|---|---|
| Anomaly detection (isolation forest) | Which tickets look unlike the rest? |
| Incident forecasting | How many incidents should we staff for next month? |
| Resolution-time prediction | How long will this ticket really take? |
| SLA-breach risk scoring | Which open tickets will breach? |
| Recurring-issue detection | Which problems keep coming back? |
| Team bottleneck analysis | Where is work piling up? |
From dashboard to conversation
Models are only useful if someone acts on them. A copilot over the same data lets a service-delivery manager ask 'why are we breaching SLAs?' or 'what should we fix first?' and get an answer with the tickets, the trend and a recommended action — which a person then decides to take.
Making it stick
- Start with breach-risk scoring on one queue and measure attainment before and after
- Turn recurring clusters into problem records with owners and dates
- Feed runbooks and knowledge-base articles from resolved tickets
- Review the models' misses every month with the desk