Project Perspective & Learnings
Sameer Patkar, VP -Oracle Support Services
Traditional customer support escalation processes focus on mitigatingvs. avoidinguser 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 thatMachine Learning (ML) can help support organizations shift the paradigm from reactive to proactive by systematically predicting escalation triggers and driving interventions beforecustomers 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.
Escalations comprise only a small percentage of most support teams’ overall ticket volumes. While proportionally few, each escalated incident incurs a higher transactional cost to resolve by requiring additional time from managers and technical resources for monitoring, follow-up, and customer communication. Pre-empting 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.
Sameer is on ASP’s Member’s Advisory Board. This is an excerpt of a longer article he wrote for us. Login to see the rest of the article and click on Articles.