All institutions are drowning in a deluge of support cases. As the cloud scales, so do support requests. How can we keep support cost under control? Is there a way to automate a slice of these cases? Let us explore.
Problem
There's a slice of support requests where a support engineer looks at the complaint and the attributes of the impacted resource, uses her expertise to build a search query, searches for it, processes the web links, and produces a resolution. It seems the customer could take all these steps herself — except she lacks the knowledge the support engineer has accumulated. We'd benefit from a faster resolution if we had a model that translates the customer request directly into resolution steps.
Solution
We aim to build a model that reads the customer complaint and produces resolution steps. We can simplify the problem to learning a function that translates a customer complaint into a search query. How do we get such a mapping? Observability comes to the rescue. Support request logs map complaints to the web links that resolved them; search logs map search queries to web links. Using the web link as the pivot, we can generate training data mapping a complaint to a search query, then train a model that infers a resolution query for a new complaint.
Metrics
How effective is this approach? We can measure the number of cases resolved this way. For partial resolutions, we use a feedback loop to improve the system.