Escalations comprise only a small percentage of most support teams’ overall ticket volumes. While proportionally few, each escalated incident incurs a higher transnational cost to resolve by requiring additional time from managers and technical resources for monitoring, follow-up, and customer communication. Preempting escalations can therefore help support organizations produce better outcomes for their customers and themselves.
To that end, support teams have utilized various approaches in the past to try and identify tickets that might escalate; most have proven to be partial solutions that either did not scale or could not reliably predict triggers. For example, one effective way to avoid escalations that occur due to lack of timely response is for ticket owners to seek help from others if they are stuck on how to proceed with an incident. While some do, most support engineers prefer to resolve problems themselves rather than seek help. Consequently, organizations have enacted external review and monitoring processes wherein managers and/or peers review open within another team member’s queue. This approach is time-consuming and does not scale.
Another popular approach is to use rules-based reports that run on all open tickets in backlog and apply logic meant to identify markers of missed expectations. While more scalable than manual audits, rules-based reports tend to identify too many potential escalations to be used reliably; the volume of “false positives” they produce can quickly inundate support personnel with additional work that may or may not legitimately require investigation.
This occurs because rules have limitations: they must be written to know about ALL potential conditions that could lead to escalation and they must have data available on which to operate. Conversely, customer dissatisfiers are not always explicitly stated in ticket data, but must instead be derived forensically by examining each individual interaction from the inception of the ticket to identify missed expectations. The relationship between this derived data and the reasons why customers escalate can be complex and not reducible to simple rules. Furthermore, customers express dissatisfaction in text updates that also convey their sentiment. Rules-based approaches are not very effective at assessing text-based sentiment and then correlating that sentiment with derived data. Finally, relationships across data elements can change over time, which can require rule reprogramming.