In the first blog installment of this series, we discussed industry verticals and product profiles that are great candidates for the application of Artificial Intelligence. We also looked at some cost contributors that spur the decision to dive into AI. It is very important to understand the current state in order to envision where improvements can be made, and we began that exercise by reviewing the typical process of a product manufacturing organization. Let’s continue with the next process: support desks!
Support Desks
Also referred to as Agent Triage, support desk contact is often the first step for the average consumer and is usually triggered through a phone call or email when they have an issue with their product. For the manufacturer, this contact is often the first with the customer, who may or may not be known based on whether the customer registered their product and associated warranty.
After identifying the customer and determining if the product is in or out of the warranty period, the agent’s responsibility to the customer is to strive for a Single Contact Resolution, which is a driving metric in the industry. Current statistics indicate that this is achieved only about 20% of the time, which means that 80% of incidents will eventually result in a scheduled field service call to diagnose the problem or an unnecessary RMA (Return Merchandise Authorization, or an order to receive a refund, repair, or replacement), both of which increase the cost center footprint.
Service within the manufacturing vertical is not immune to common issues that plague other industry service desks. This includes turnover, which continues to stratify service agents into experience levels that prevents any given agent from working any incident. This is historically accounted for by moving the customer through multiple skill levels of agents until the issue can be solved (or not), which extends the customer interaction time, and as a result, the frustration level of the customer.
Resources
Past incident data – This is usually provided by either a ticketing system and/or a CRM system and contains incident details reported by the customer in question, or by other customers that reported similar incidents with the same products. This data is often the most referred to but can be incomplete because the source of record is only updated by other service agents and typically not with a matching resolution from a field service claim report or other resolution source. This means that only single contact resolutions are in the system for reference, which (as mentioned above) is only achieved 20% of the time. This becomes a systemic and cyclic problem that keeps that metric artificially low.
Product documentation – There are often two types of product documentation: one that is customer facing and provided with the product or online, and one that is internally facing that would document known issues, recalls, and part deficiencies. Both are excellent resources for agents; however, they are largely incomplete and not always fully indexed and therefore not searchable. Using these documents for answers often takes a significant amount of time, and if the issue is found, yields an accurate solution. However, if the issue is not found it results in a monumental waste of time. Even though the downside is significant, these documents will almost always be referenced if the past incident data does not provide a clear resolution. This process can drive a significant update process in the case where the documentation does not have the resolution and the resolution is discovered later. Sadly, most major document revisions are conducted when a new product version is released.
Warranty Claims and RMA reports – This is often the most accurate data available, because it contains the “fix” as it was applied to the product by a field service agent, or in the case of an RMA, how the product was repaired or refurbished to be in working order. This information is not without its own challenges. Most manufacturers have not fully indexed this data and “linked” it back with the problem as it was reported by the customer, which limits the agent from “connecting the dots” from incident to resolution. In many organizations, this data is also directly connected to its associated financials, and as such agents do not even have access to it.
Knowledge Silos
As agents work incidents from day to day, much of the repeatable information is memorized. This is especially true of the manufacturer’s most popular products. This creates significant knowledge silos in agents that can be specific to certain SKUs, sub-systems, or geographic dispersion, and presents both a problem and an opportunity.
The problem is that if a very knowledgeable agent that has specialized in a particular product leaves the organization, a gap is created. Many manufactures have tried to combat this issue with training regiments or documentation policies against the past incident data mentioned above, but both approaches are time consuming and contribute to increasing the loaded cost per incident metric.
An opportunity lies in connecting the customers with specialized incidents to those agents with that specialization quickly and efficiently to increase the chances of a timely single contact resolution. In smaller organizations, this is typically achieved through educating the first level agents on whom they should route tickets to when the incident is obviously one that can benefit from a specific agent. If the nature of the incident is not obvious however, that procedure breaks down. In larger organizations the only real option is automation, which requires the accurate “tagging” of the incident AND the agent with standardized metadata to make a match and then to route the incident accordingly. As a manual process, this often takes longer and diminishes any benefit that would otherwise be gained.
In our next installment, we will take a deep dive into the Field Service Component, which is where much of the value of an AI-infused platform comes to root (and where much of the existing cost leaks out and drives up per incident cost). Until next time!
