In our first and second installments of this blog series, we look at manufacturing industry verticals that are great candidates for using Artificial Intelligence, their customer service practices, and the challenge of knowledge silos. The third blog takes a deep dive into the challenges of field service. Now that we’ve set the stage with the patterns and practices that manufactures typically employ, let’s examine how applying Artificial Intelligence (AI) can provide significant benefits.
Defining the Symptom/Solution Model
When applying AI or Machine Learning (ML) to a use case like product service, the core base of knowledge and its “schema” is referred to as the data model. This is often a compilation of historical data that can hide trends and patterns that are much more quickly and easily detected by a machine than by a human. Taking into account all of the opportunities for improvement in manufacturing service practices, one overarching fact emerges: The earlier in the process the root cause and resolution are identified, the cheaper and quicker the execution of that resolution will be. We will refer to troubleshooting augmented with AI and ML as “intelligent triage” as we go forward.
Identifying the Symptom
Let’s use a medical analogue to apply a familiar use case to intelligent triage. When someone visits the doctor and complains of a belly ache, they have given the doctor a symptom to start the diagnostic process. The doctor might then ask a series of questions to help narrow down what the root cause is in order to provide a resolution to the ailment. Where does the doctor draw those questions from?
Many-to-Many Relationships of Symptoms to Problems
The initial symptom has many potential root causes. For the sake of illustration, let’s say there are 10 possible root causes. If each of those root causes has five solid symptoms, then, accounting for overlap, there might be 25 or so unique symptoms. If those symptoms are turned into questions asked of the patient in a very specific and efficient order, the root cause could ideally be identified, or at least narrowed down with a high confidence level. This is the simplistic overview of how the ML predictive analytics model would assist in the triage process.
Root Cause-to-Solution Mapping (Resolution Coding)
Once the root cause has been narrowed down as far as possible, with associated confidence levels for different options, the solution to that root cause needs to be identified. The root cause in our medical analogue might be that the patient drank sour milk, and the resolution would be, don’t drink sour milk!
But what if the milk were fresh and the root cause was that the patient was lactose intolerant? There could be several resolutions to this. One might be to stop consuming dairy products, a solution easily implemented without further assistance from the doctor. Another resolution might be to take medication that would reduce or eliminate the condition. That would most likely require a prescription from the doctor.
The analogy here is that, with intelligent triage, perhaps a service agent could help a customer by resolving their issue right away over the phone. Or, perhaps it reveals that resolution requires a field service visit to make the repair. With intelligent triage, at least the resolution is known in both cases, so even if the field service agent has to visit the product location, the parts, tools, and time to fix are known quantities. That eliminates the “diagnostic truck roll,” saving money and limiting the customer’s frustration with down time and the inconvenience of multiple site visits.
Solutions with Parts
Solutions or resolutions that involve replacement parts are especially positively affected by intelligent triage that identifies required parts that can be ordered before the service call. In over half of the cases where an initial truck roll is ordered to diagnose an unknown problem, the parts for the repair are not on the truck, resulting in another truck roll. This is further exacerbated by sub-contractors not maintaining a stock of replacement parts, opting instead for the much cheaper just-in-time ordering process.
Coding for Root Cause
Many manufacturers code repairs with the root cause so at least they are collecting some data relating root cause to solutions. The easy way to do this with some level of automation is to look at the part that was used for the repair, such as coding “The icemaker was replaced” as “Bad icemaker.” This seems like a good solution until a warranty claim comes in that uses a myriad of parts for repair, once again introducing an unwieldy many-to-many relationship of data. To keep it simple, the most expensive part is often used to code the root cause, but this is often inaccurate and also opens up loopholes in the process, allowing parts to be “hidden” within a warranty claim.
Solutions Without Parts
Solutions without parts often lead to the most inaccurate documentation within the warranty claim process. However, they can be a significant source of triage data that can be leveraged by the ML model. Typically, solutions without parts are either not coded for root cause, or a human determines how to code every claim. This is a time-consuming process that can be greatly enhanced by AI/ML with Natural Language Processing (NLP). The claim can be analyzed and compared against hundreds or thousands of others to produce highly accurate predictive recommendations of root causes
Applying the Symptom/Solution Model for AI
So how do you apply AI to the symptom/solution model during an intelligent triage session? The main challenges are turning a database of well-known symptoms into questions and finding the most efficient order in which to ask those questions to narrow down possible root causes. In the absence of enough information to identify a root cause, the AI engine would also have to understand how to contribute qualifying data back into its own model.
Training the AI Model with Symptom/Solution Data
One of the most useful applications of AI is the ability to detect nuanced patterns and anomalies within large volumes of data that would otherwise be difficult or impossible for a human to uncover. That brings us to the first step in developing our intelligent triage model: loading the data and identifying the patterns that make sense. In the absence of other parameters, the logical choice for root cause is frequency. If the most common cause of a belly ache is eating bad food, then that fact – backed by empirical data – could be assumed to be the case until proven otherwise. In fact, that is why “What did you eat today?” is probably the first question a doctor would ask.
The doctor would most likely continue the line of questioning, trying to confirm that the issue is, in fact, the most common one – until an answer is given that invalidates it. In that case, the next most likely root cause (considering the answers to previous questions) would be identified, and the process would begin again until no more information would further identify potential root causes. This is the base process and ruleset by which our AI engine would use its symptom/solution model
Predictability Models
Consider the above intelligent triage process being executed many times with the same initial symptom. In addition to patterns that exist within the source model, new patterns will start to emerge within the intelligent triage process itself. Symptoms and their corresponding questions will start to hold weighted relevancy as to their ability to predict the root cause, and therefore would be asked first. Conditional combinations will also start to be identified, whereby certain questions answered in a certain way eliminate the need to ask one or many other questions to corroborate the result. This data is persisted into another associated model that drives predictability, accuracy, and most importantly, efficiency.
The AI User Interface for Triage
Everything that we have described so far lives in the “back end” of the AI-assisted application or platform. To be useful, it has to be manifested in a way that mirrors how work is performed in the troubleshooting environment of product service. What does that look like?
When dealing with large amounts of historical data, it helps to eliminate data not relevant to the issue. Let’s depart from our medical analogue and use a real product use case. A customer calls in about an issue with a refrigerator. The icemaker has not produced any ice for several days. The first thing we can do to assist the AI engine is to identify the model number of that refrigerator to eliminate data being retrieved for a clothes dryer or dishwasher. Limiting the intelligent triage process to only what is applicable is prudent and acts like a filter before the process begins. There are many other such filters that could be applied as well, such as how the product was being used, or the geographic location of the product (if that would affect the operation or performance of it). Any upfront “filtration” is a good thing.
Guided Questionnaire
The user interface, then, is a guided questionnaire, which is a machine generated progressive list of questions based on the questions that have been asked thus far, similar to what the doctor would do in our previous analogy. It is important to note that, if properly implemented, this questionnaire is not pre-scripted, because the permutations of symptoms and associated values would be incredibly vast (not to mention that it would not be “AI” at all).
The guided questionnaire should have, at minimum, the following features:
- A running list of questions that clearly shows the history and order of the questions asked, and the answer that was given
- A current running list of possible root causes with their associated confidence levels
- The ability for users to:
- Eliminate a question from the list if it is found to be inapplicable
- Restart from a given point in the history because the answer to a question was incorrect and needed to be changed
- Skip question if the answer is not known
- Enter their own question and answer
- “Upvote” or “downvote” a question based on the user’s consideration of how helpful or applicable a question was to the process
- Correct the language accuracy or punctuation of the question (they are machine generated from statements and can sometimes be inaccurate)
Contributing to Unresolved Symptom/Solution Chains
It is inevitable that in some cases there is simply not enough data to drive the intelligent triage process to the satisfactory conclusion of identifying a root cause and resolution. This can be especially prevalent when a new product is released that doesn’t have any historical service history to draw from. There are a couple of strategies that can be employed here:
Documentation Seeding
With any new product, there is always documentation provided to the user that typically would have some troubleshooting steps or processes in it. This can be loaded into the model to seed it with information to start building from.
Manual Creation
Any platform should provide the ability to manually enter symptom, root cause, and resolution data directly into it if the information is previously known. This can also provide a base of data that the AI engine can start associating and building relationships from.
Product Data and Previous Model References
Possibly the most effective way of dealing with a shortage of data is to integrate the product data management (PDM) system with the intelligent triage platform. This allows for the engine to take into consideration all of the service data that might have been recorded against a part or subsystem that has been reused in a model – for example, a new model refrigerator reusing last year’s model icemaker. That icemaker subassembly would most likely have service data associated with it that can be used, even if a filter were applied to include only the new model.
This can also be extended by attribution of parts and assemblies to allow for grouping types or categories of the same parts. It is highly likely that a particular family of parts might experience the same issues or failures, and that data could be applicable to the current product being triaged. Of course, in both of these cases, if the root cause and resolutions were identified, the data would also be stored against the current model in question for the next time. The bigger and more complete the data model, the better the chances of a definitive result.
Other AI/ML Opportunities For Manufacturers
There are other potentially impactful applications for AI in manufacturing service management. Some can be implemented as stand-alone solutions, and some are meant to go hand-in-hand with the intelligent triage process. Here are a few examples:
Customer-Facing Virtual Agent
Conversational AI virtual agents, or bots, are everywhere on the web, and this approach is being widely accepted across all customer-facing platforms as a first form of contact and resolution. The “classic” implementation is, however, problematic for manufacturers because of the nature of “intents,” which is the way a conversational AI bot recognizes what to do based on the input the user typed. If there is no match to the user’s issue, the bot has to do something else, which becomes a catch-all intent – like forwarding to a live service agent, for example. This implies that a successful bot would have to know all of the triage permutations ahead of time. There are one or two advanced technologies available, however, that can use an agent-facing triage engine for a customer-facing application.
Field Service Truck Stock
In the case of a truck roll to service non-mobile durable goods, a predictive model based on historical service data could proactively recommend parts to be included on the truck based on all service calls scheduled for that day. This can increase the number of successful completions in one call, eliminating the need for another truck roll. This concept can even be extended to building specific product “kits” that would be loaded on the truck for the associated products on that day’s service route.
Field Service Suggestive Maintenance
Similar to the truck stock example, a suggestive maintenance engine would recognize that a service visit is being made for a particular product of a specific age, with a specific service record. It would then suggest, or even directly append to the service order, other maintenance tasks such as wear part replacement or recall part servicing.
Automated Document Generation/Update
There is also a significant opportunity for allowing resolution data from the triage system to be automatically reincorporated back into user documentation. This can be accomplished with Robotic Process Automation (RPA), another AI-based technology that can integrate with the triage and knowledge base platforms.
B2B Solution Offerings
In today’s retail market, most manufacturers’ products are sold through resellers. Many big box stores are designing their own extended or augmented warranty offerings that are more robust than a manufacturer’s base warranty. However, the retailer will typically not be as experienced in servicing that product as the manufacturer. That’s because the retailer covers only a fraction of the total units in the field. In that case, monetizing the service data in the form of an intelligent triage product that can be licensed to a retailer could be a way of helping convert a cost center into a profit center for the manufacturer.
Conclusion
With modern AI seemingly everywhere in our lives, it’s only logical to apply it to troubleshooting product issues for manufacturers. We used the medical analogue as an example earlier, but in reality, AI platforms in the healthcare industry have existed for some time, giving diagnosis, treatment, and prescription recommendations to medical professionals. In this case, the data model is the knowledge base behind modern medicine. It is now time, and the technology is adequately mature, for manufacturers to adopt AI for improving their service processes. In today’s highly competitive economy and with resources stretched, any edge that contributes to a product’s profitability should be considered a staple strategy – particularly when it can help meet consumer expectations for a better experience when dealing with an issue.
