The benefits of a high quality, continuously updated technical knowledge base are numerous and proven; information enablement, reduced troubleshooting time, errors fixed on the first visit and instant transfer of skills to new generations of field service engineers, to name a few.
However, there is one question in particular that always comes up quickly in any knowledge base software project.
I’ve been working with Dezide for 20 years now, and over the course of that time span, there is one question in particular that keeps coming up when I speak with prospecting customers. I always get the question around the effort involved in building the knowledge base, and it usually goes something like this:
“The general consensus is that there’s a concern around the amount of time it would take to either build a new knowledge base or convert all of our existing KB articles into dynamic step by step guides and whether we have the resource to do this – thoughts, please?”
I understand your concern, and building a knowledge base should, by all means, not be underestimated. It is no small effort, but in our experience, it is worth the investment.
Conversely, not investing in your technical knowledge base can result in deterioration of the quality of the content over time, the knowledge base becomes stale, and the staler it gets, the fewer people tend to use it.
Let me break down the benefits and opportunities gained from investing in and building a high-quality knowledge base.
It all revolves around your strategy and goals for your service efforts, because regardless of the strategy you chose to employ, be it short term gains or long terms plans, it all comes down to your technical knowledge base and software platform. It’s an important decision to either keep using those familiar service manuals, try to take a short-cut with machine learning, or make a service leap by investing in upgrading the knowledge base with expert troubleshooting knowledge from the minds of the best.
Consider your strategy
First of all, you need to consider the expected outcome of your knowledge base project and whether you are looking to optimize your service efforts in a short or long term perspective to determine the type of software solution that matches your needs. Are you really just migrating from an old software system to a new and is all you really want to achieve a one-to-one transfer of the existing articles and their content to a new system that looks a little better and perhaps offers a bit better search engine (or something along those lines)? If that’s the case, then opting for an advanced guided troubleshooting solution is probably not the best choice.
Likewise, if you are looking for quick wins and a silver bullet solution that can automatically extrapolate solutions to common problems using NLP and neural network technologies to generate a knowledge base, it’s probably not an advanced troubleshooting solution that you are looking for either.
There is plenty of those type of systems out there now that computer power has reached a point where AI technologies, such as NLP and deep learning, makes sense on larger amounts of data. These systems are more content-aggregators than actual troubleshooting solutions. They can analyze and present data and information from many systems based on e. g. serial number or customer number – like customer relationship platforms, enterprise resource planning software, spare parts catalogs, scheduling, and historical case data from customer cases and technician work reports. These solutions become very efficient in the initial customer service triage experience and can potentially help find solutions to simple customer problems in call centers and self-service scenarios. However, they are not the best choice for capturing tacit expert troubleshooting knowledge from the minds of the field service gurus and make it available for the entire workforce.
But, triage might be just what you are looking for, if you are optimizing the service center part of your service value chain, or if the nature of your service issues are simple and your products aren’t too technically advanced.
If instead, the ambition is to upgrade to a more sophisticated system that can help you realize your long term strategic support vision by handling both easy and complex issues, utilize IoT data for automation, enable multi-channel distribution to varying skill levels, integrate with service management systems and many other advanced features, then looking into upgrading your existing knowledge base or building a new one from scratch, is definitely worth considering.
How do I get started – we already have a lot of existing documentation?
Every time we start a new project with a customer (regardless of industry), we start digging into the existing documentation used by the technical service workforce already. And, quite often, there is a significant amount of existing documentation that is used to some degree by the workforce. Existing documentation in the form of static pdf documents living in traditional document management systems. The workforce either looks up the documents in online searches or carries an offline dump with them on their devices to be able to work in disconnected environments without network connectivity. The biggest challenge with the traditional documentation approach is that, in our experience, technicians can spend as much as up to 30% of the total troubleshooting time looking for the right documentation, even before unpacking his tools. However, there is still value in the documentation, and what we find is that the existing documentation serves as an excellent starting point. But, it also reveals a hidden message. It reveals why you most likely are reading this article – that your existing documentation and knowledge base has only been able to take you and your service team thus far. It reveals that the state of it, its depth and quality has served you well up until now, but to take a leap forward, relying entirely on the existing documentation (and sometimes lack of documentation) will yield little to no results.
The thing is, traditional static documents tend to be, well, static. As much as everyone believes that the service manuals are the go-to resource for technicians and that they are kept updated on a regular basis – the reality is that they are very hard to update, and the turnaround time for updates is often very long. But, of course, it’s a good place to start and why not use what we already have?
Well, when we sit down four guys in a room – four guys that are some of the most senior expert technicians in the workforce, and they start building new troubleshooting guides in our framework using causes, probabilities, and cost, they quickly realize that the existing docs are often lacking in terms of being current and relevant. They don’t cover all causes, they do not share a common style or flow, and in general, they could need an overhaul. When we ask those same four guys (the type of technicians that other technicians call for help), to break down the root causes and their probabilities for any given problem or fault code on the whiteboard, we always end up with four guys that have four different opinions about what the causes are, how often they occur, how to fix them and how much time it actually takes … and this is not because they don’t know what they are doing, remember that these guys are the best in their field, but everyone has their way of working and their line of thoughts around troubleshooting complex problems.
Add to that the concept of workforce troubleshooting best practice “myths” that always exists in the field. These are common misconceptions that certain errors need to be fixed in a certain way.
Let me give you an example:
One of our customers was seeing a large volume of a particular sensor being replaced on certain products. When an issue occurred, the technician would know that the problem was caused by the sensor because “it’s always the sensor, just replace it.” However, they analyzed 100 cases of sensor replacements, and zero out of the 100 were faulty!
So if the best of the best with 20+ years of experience don’t agree on the best way to troubleshoot your products, how can you expect the rest of the workforce to provide the best possible service experience to the customers?
In these sessions, everyone becomes aware of the need for a troubleshooting solution that ensures uniformity and efficiency in the way that both remote agents and field service technicians operate. The only way to do this is to make sure that the knowledge base provided to them is as good as it can be, but also that it becomes increasingly better over time through feedback and optimizations.
It is also right there that everyone realizes just how much work would be involved in not only transferring knowledge to a new system but also in upgrading the content and enriching it with new knowledge from the field. The realization that the end goal of a solid knowledge base that covers all troubleshooting cases and all products is a massive undertaking. Of course, we encourage all of our customers to focus on a vertical and release the knowledge base in phases, as the knowledge base build-up progresses, but that’s a topic for another post.
Given the outlook of a significant initial resource drag on essential expert technicians, it can seem tempting to have an AI identify patterns and interpret existing service case texts and notes. Still, if you train your AI on old data that needs updating as described above, I’m not sure that you will be satisfied with the result.
I have even had a customer in the medical equipment industry calling their existing document-based knowledge base “dirty data” – I think that says a lot as to what to expect from an automated system.
But why would you start with “dirty data”?
Why not start with structured, validated expert knowledge?
It all comes down to strategy and your vision for your service business…
Consider the business case
The ability to support customers, agents, and field service technicians when troubleshooting the most complex issues in advanced products is in itself very often enough to justify the investment. I have written a bit about how to handle troubleshooting of complex problems in this blog post, and I recommend you give it a quick read if your products are advanced and the problem resolution path is complicated.
Now, I am sure that you can quickly achieve a 5% reduction in ticket creation through a modern search engine driven bot-interface for self-service, that doesn’t require a whole lot of work upfront – but is that good enough? A 5% increase in surveillance center efficiency is most likely also easily achievable – but is that good enough?
Does it support your long term after-sales strategy?
What strategic opportunities are closed, if you go with the simple solution now?
From the end-customer to the man in the van, the goal should be to make sure that each user gets the complete end-to-end digital support experience that they need with relevant pieces of content served at just the right time in an interactive guided step by step flow. Likewise, should the user need to escalate and create a ticket, we need to make sure that all the data used in the troubleshooting process is captured and sent along to the ticket system, enabling better informed agents that can continue troubleshooting from where the previous users ended.
Consider other service initiatives
Your long term strategy should also include considerations around other long term service initiatives and opportunities, but also operational factors such as knowledge base maintenance, distribution, and productization.
Here are some of the most important factors that we see our customers highlight at the moment.
Automation using IoT data
We have a long history of using external data to aid the user in the troubleshooting process. Every time there is a question in Dezide, there is an opportunity for automation as the system can answer the question automatically using data. We have seen some fantastic results in, e.g., the telecom business, where our customers have achieved outstanding results by automating remote diagnostics and the evaluation of complex data. This ensures that all users troubleshoot in the same way and that all data is interpreted in the same way every time – there is no manual evaluation of complex data.
The largest telecom operator in Denmark, TDC, is using guides in the call center where more than 25 questions are answered automatically by the system before the first solution is displayed to the agent. This has reduced average handling time and increased customer satisfaction scores. You can read about their case here.
As the industrial internet of things continues to generate massive amounts of data points, the opportunity for utilizing that data increases. From a service perspective, the potential for increasing troubleshooting efficiency using IIoT data is enormous.
Combining real-time machine state data with machine-specific error codes and historical data can result in a troubleshooting experience designed and optimized for each individual machine, every single time.
But, to increase service efficiency using data, your knowledge base needs to be updated, operational, and flexible.
Transfer of skills
Capturing expert troubleshooting knowledge in dynamic guides and adding the benefits of automation not only results in reductions in troubleshooting time, spare parts, and much more, but it also means a significant reduction in training time. Some of our customers have called it “instant transfer of skills” when hiring new generations of field service engineers.
For example, we worked with Atlas Copco Compressor Technique. They invested in building an entirely new knowledge base and quickly experienced a faster transfer of information and skills. Training of new personnel became much easier as knowledge is now available in an easily accessible digital form. This means that training time has been reduced significantly. Ultimately customers experienced a quicker resolution of the problems and increased machine uptime.
The actual conversion of existing content goes back to my first point around a one-to-one migration versus an upgrade of the content. We often see, that when our new customers start building troubleshooting guides from existing content, they quickly realize that there is room for improvement and quite often end up writing new content or improving upon the existing as converting old articles to step by step content provides an opportunity to increase the quality of said content.
In terms of time, our experience is that at least 90% of the time involved in building a high-quality troubleshooting guide is spent on the actual content, and only 10% is spent on the guide logic (causes, actions, questions, probabilities, etc.). That is why we highly recommend including technical writers on the team to assist the subject matter experts when building the guides. This is to ensure a high degree of consistency in writing throughout the entire knowledge base.
Should you be fortunate enough to be already using a CMS system for your content and articles, images, videos, etc. then we recommend an integration between Dezide and the CMS system. HP Inc. uses SDL as a CMS system that we integrate with. The result is that HP only builds and maintains the Dezide Guide logic (causes, actions, questions, probabilities) inside the Dezide Administration Tool and everything else lives in the CMS system. This makes it possible to separate concerns and let the technical guys capture the actual troubleshooting expertise in the guides and have the content organization handle the process of writing good content using consistent language and terminology.
This is an important operational aspect because if you do not make sure that your organization is in place for long term knowledge management, you might as well continue with the document management process. If you make the investment in upgrading your content and migrating to a guided solution but don’t secure the long term resources for keeping it updated, your project will not become the success you are looking for.
Localization and Internationalization
A knowledge base should support many languages. Dezide supports all the languages of the world, including Arabic, Hebrew, and Chinese. One of our biggest customers, HP Inc., supports 32 languages across the globe using Dezide and the system itself is fully localized too.
You might only have a single language service organization now, but what happens when new product sales start expanding to other markets? What happens when you can no longer get local technicians to your workforce?
Handling languages might sound like a small item, but in our experience, it can be a challenge.
White labeling & productization
We see an increasing interest in turning the combination of our software platform and the expert troubleshooting knowledge base into a product that our customers can sell to their customers to make a profit. This implies that the knowledge base platform has to support this kind of productization and white labeling. It is the process of going from challenges around downtime, tickets, and dispatches to a modern, efficient service organization that fixes problems on the first visit, in less time, and eventually turning an otherwise costly business unit into a revenue stream.
If the commercialization of your service offerings is on your roadmap, you definitely need to consider the ROI in not only converting or migrating your knowledge base but indeed also make the investment in upgrading.
So yes, it does take time to move to a new system, and the decision is influenced by many factors (more than I have covered here), but the benefits are many – we haven’t even talked about customer satisfaction and retention yet.
Going back to the original question:
“… there’s a concern around the amount of time it would take … , and whether we have the resource to do this – thoughts, please?”
The question around how much time it takes to migrate is difficult, but your goals for your knowledge base (and your support organization in general) will impact whether the work involved is justified. A quick win in the short term may set you up for failure (or a lot of re-work) later on. But again, depending on your case, you need to consider your strategy.
Case: upgrading a highly technical KB for very advanced products
We did some calculations for a big company in the semiconductor industry last year. They had around 1500 very complex decision trees in an old format that they wanted to upgrade and continue using in a new system, but the task seemed massive. We sat down and timed how long it took to build a few of their very complex flows and then extrapolated that to estimate how much effort would be required to migrate the whole thing by hand.
For them, the effort amounted to approximately 3,5 months for five full-time employees. That might sound like a lot of time, but in the big picture, and given the numerous advantages of a high-quality KB as described above, it’s really not that much in the long run. Most of our customers stay with us for 10+ years, so the initial investment in time is insignificant compared to the long term business impact.
So my point really is that while it does look like a daunting task to convert and upgrade an existing technical troubleshooting solution knowledge base, the opportunities that lie on the other side of a conversion far outweigh that initial investment.
The impact of launching an interactive step by step guided troubleshooting solution for 100’s or 1000’s of service engineers vs. an initial investment in time required by a handful of your best experts should be a no-brainer, especially if your goal is to transform your service department from a reality of unstructured and scattered information to a streamlined organized service experience through digitalization.