Avoiding Hotline Hell
With much fanfare, a manufacturer launches a newly designed piece of equipment – car, plane, train, medical analysis device. Along with the equipment comes the usual library of technical support publications for maintaining and repairing the equipment, with names like Maintenance Manual, Parts Catalog, and Troubleshooting Guide. At the outset, all of these manuals are quite effective but, over the life of the equipment, the Troubleshooting Guide (TSG) presents unique challenges.
There are important differences between service manuals. The TSG helps technicians figure out “what” needs to be fixed, whereas the other manuals focus on “how” to perform those fixes. Helping technicians diagnose the root cause of equipment problems is critically important, and it’s the only way to ensure they make accurate repairs (following the maintenance manuals and parts catalog). However, product support suffers when the manuals get out of date.
Technical manuals are typically created during the product design and manufacturing process. Maintenance manuals and parts catalogs tend to reflect equipment assembly processes and, as a result, the content remains relatively stable over the life of the product. (Service procedures and part numbers only change when the product design is revised, or when install/replace procedures are improved.) However, the TSG is another matter.
Troubleshooting processes start to change as soon as the equipment begins operating in the field, and the number of changes to the TSG increases with the number of machines in operation. The reason is that each equipment owner has different workloads, performance criteria, and environmental conditions, making it inevitable that equipment performance will degrade, or even fail, in new and unexpected ways. These new “failure modes” must be captured and shared to ensure proper troubleshooting and customer support.
The need for frequent TSG updates is a challenge because troubleshooting processes use a step-by-step format (measure, inspect, test, etc.) to isolate specific problems. If the TSG is not up-to-date (i.e., it doesn’t include steps for new failure modes) then technicians won’t be able to accurately identify certain equipment problems, which increases the time and cost of repairs. Unfortunately, updating the TSG is more complicated than simply adding a new step-by-step process because other, similar processes must also be modified (and reviewed/ approved) to ensure accurate identification of each failure mode. In other words, with each new failure mode the TSG becomes more complex and unwieldy. On the other hand, failing to add new problems to the TSG makes it less valuable to technicians.
The challenge of keeping TSGs up-to-date is too much for most companies, they simply don’t have the resources to make all the changes. As a result, many companies leave the original TSG intact (no changes except for minor tweaks) and instead ask customer support and field technicians to add new troubleshooting processes as service reports, service bulletins, best-practices, tips-and-tricks, etc. These documents are then dumped into various product support silos (repositories), which could be SharePoint directories (or other CMS), web portals (knowledgebases), private YouTube channels, and/or technical forums. Unfortunately, the result of this approach is that troubleshooting processes get spread across multiple locations, as different formats, using various terms/jargon, and each silo is (by definition) an incomplete representation of what the company really knows about troubleshooting. (Even when all the information is in a single repository the challenge of maintaining consistent data formats, descriptions, keywords, tags, and jargon can be overwhelming.)
This marks the beginning of a company’s decline into customer support anarchy, where technicians do whatever they can to avoid searching each of those silos (because even a highly-tuned search engine delivers too many “hits” to be efficient). Most technicians simply call the hotline, hoping for a fast answer from a person with limited visibility (and perhaps less expertise) into the technician’s specific problem. Companies that choose to pursue a searchable database find that too is doomed over time because as the amount of information in the database grows, the search results get longer and the technician is required to read, understand, and evaluate multiple documents to solve their problem. (This approach may seem cost-effective in the beginning but is typically ineffective in the long run.)
To avoid hotline hell and searchable databases, some companies take their most effective technicians—subject matter experts (SMEs)—and make them work on the hotline to try and spread their wisdom one call at a time. They may also ask SMEs to document everything they’ve learned (over the past 20-years) as videos and best practices, using a very structured format, but that simply increases the size and complexity of the silos (as well as enforcing the guidelines).
A better approach to troubleshooting replaces the TSG (and its add-on silos of information) with a diagnostic database (DDB). A DDB can capture all the problems, symptoms, causes and solutions associated with each type of equipment. A DDB is flexible and easy to update, can provide links to maintenance manuals and parts catalogs, and incorporates a diagnostic reasoning engine that can be tuned to each company’s needs. More details about the DDB approach will be shared in subsequent blog posts but the result is a troubleshooting solution that is portable, easy to use, and up-to-date (and integrates seamlessly with Internet of Things (IOT) environments). A few of the benefits to a diagnostic database solution include:
- All troubleshooting knowledge is managed and protected in one place
- Technicians are quickly guided to validated solutions for equipment problems
- Support personnel (and SMEs) are freed up to resolve new customer problems