Traditional customer support escalation processes focus on mitigating vs. avoiding user dissatisfaction. This often adds to the customer’s already-present frustration; lowers service satisfaction ratings; and increases support costs by requiring intervention from senior staff and management. We believe that Machine Learning (ML) can help support organizations shift the paradigm from reactive to proactive by systematically predicting escalation triggers and driving interventions before customers get frustrated — improving the service experience, lowering costs, and increasing staff efficiency along the way. This article examines the author’s experience in building an ML tool to predict service escalations and describes key takeaways from his journey.
By Sameer Patkar, VP – Oracle Support Services
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.
This article is an excerpt from a longer article Sameer wrote for the ASP. To read the rest of this article you must be logged as an ASP Member.
Not an ASP Member? Learn about the benefits of joining the Association of Support Professionals
Learn More about the ASP