Using Decision Trees in Support Centers
Decision Trees (DTs), like those that can be created in AnswerFlow/Process Wizard using Oracle Knowledge or Guided Assistance using Oracle Service Cloud are basically automated process flows that instruct users through a series of steps to resolve an issue or find information on a specific topic. With each step, a DT can gather user input to transition them to the next correct step, eventually leading them to the correct end step.
During the course of my career in Knowledge Management (KM), I’ve encountered a mix of Knowledge Management System (KMS) clients, ranging from those with little to no knowledge of their KMS DT feature to some who have implemented hundreds, or even a thousand of them. Most clients have used or continue to use just a handful of them, but have either not found a good reason to implement more, or have had difficulty in understanding how much their DT implementation can be expanded.
But in my experience, it’s usually the lack of knowledge about the useful ways that DTs can be implemented to provide value that holds organizations back from creating more of these nifty guides. The following list contains some of the most useful contexts where DTs can provide value to a business.
- Procedural Support Knowledge
- Support Responses to Customers
- Call Scripts
- Employee Training
- Search Disambiguation
The trouble with this traditional method of writing an article or document to describe procedural information is that depending on the issue or topic, the information can get quite complex, and contain many branches of information that the user must follow to get to the correct solution. It can contain lots of sections that look something like: If X then Y, but if A then B. For more information on Y, look at article XYZ, or for more information on B, click this link, etc. The user can quickly get lost in a mire of process layers, resulting in not getting to the end step on the first try, or reaching an incorrect one.
DT features provide an interactive way to step the user through a procedure, without having to keep track of all of those layers. It’s no wonder that some companies have caught onto the value of these features to replace many of the procedural documents that used to exist in their KMS, which have largely been archived in favor of DTs.
We live in an omni-channel world, and the most successful B to C companies have updated their systems and processes to satisfy the consumer appetite for omni-channel support experiences. Responses to customer queries are no longer limited to phone conversations, but can be delivered via e-mail and message posts that contain specific information or steps on how to resolve the issue reported by the customer.
But manually writing a new response to every customer’s support case can be tedious, time-consuming, and prone to errors. Therefore, many support organizations are opting for KMS tools that allow them to attach or embed support information from their knowledge base directly into their responses to customers.
DTs can be a good option here since it can not only automate all of the decisions needed to transition correctly from step to step, but also keep the pieces of information they need to consume in smaller bits and pieces, reducing the chance of misreading or skipping over important information. Users are rarely motivated to read every word in a multi-page article, but when broken down to smaller increments, the user is more likely to go through each piece of information in sequence and will consume more of the written information. Best of all, DTs can be used without the support of a live agent.
DTs might be great for sending as an attachment or link in an email to a customer, but what about when a customer calls into a support center or starts a live chat to talk to a live agent? In this scenario, the agent must either step the user through a procedure, or follow the steps themselves to provide the correct answer to the customer. DTs allow businesses to streamline agents’ responses to customers, thereby controlling the quality of responses that are provided.
They also provide an easier way that agents can support themselves when supporting customers, as there is less of a need to create a verbal response in a conversation, and they are able to provide the correct information at each step in the process being followed.
Any organization will have its mix of veterans and newbies, but nowhere is the difference in output quality and productivity between these two groups more apparent than in a support environment. One of the biggest challenges when building a knowledge base for a support organization is figuring out how to best serve the needs of both groups. See the key differences in the table below.
DTs in this context are a great solution to dynamically customizing the knowledge base experience to different levels of knowledge, as well as making them more findable than ordinary articles. This is because DTs can have inherent logic built into them to transition users to the next logical step, taking the guesswork out of, “What else do I have to know or do now?” Oracle KM Process Wizards and Answer Flows can additionally be configured to appear in context with search patterns, making them contextually specific.
If you’ve ever spent time looking through a search log, it won’t be long before you scratch your head and say, “I have no idea what some of these users were looking for.” That’s because users tend to use less words and put them together less naturally than when talking to a live agent. This makes it difficult for search optimization engineers to tune the search engine to retrieve the correct results. To tune search, you must be able to evaluate the relevancy based on the results returned, but you can’t evaluate the relevancy of the answers if you don’t know what the question is actually asking.
Now, imagine that you’re a support agent and a caller asks you the same ambiguous question that you just saw in a search log. What would you do? You’d probably ask one or more questions to gather more input from the caller, hoping that it will clarify the question they asked. This is exactly what a DT in this context would do, except that instead of live agent, the user would be interacting with a “wizard” that will take them through some easy steps to not only clarify their question, but also lead them to the best answer.
. . .