A 10-year AI Journey in Revolutionizing a Service Department – Part One, The Past

This is the first post in a three-part series of blog posts that tells the story of how one of Dezide’s biggest customers took a journey from unstructured content, hidden knowledge, and traditional documentation to a modern, streamlined service organization.

This customer works in the field of Industrial Engineering manufacturing machines that are distributed worldwide.

This blog will be followed by a webinar in May 2021, where another Dezide customer, Atlas Copco, will participate in the discussions and share insights into how they have taken the same journey as outlined in this post. We will also publish a research report with insights from the field, where we will get unprecedented insights into the experience of the field service engineers working with AI-powered intelligent knowledge management.

The webinar will be beneficial for organizations that have not yet started the investigation or implementation of AI-powered knowledge base solutions, organizations that have started the implementation of a knowledge base but have met obstacles, and for organizations that have come a long way with implementing knowledge base solutions but who are looking for inspiration on how to take it to the next level.

Above all, this is a story of digital transformation and modernizing a traditional service department by enabling field service technicians to access the right knowledge at the right time. It’s a story about quitting an old service strategy and embracing digitalization from all levels of the service organization, from top management to the technician in the van.

The story begins ten years ago, a few years before the first troubleshooting instruction was created in Dezide, and before Dezide was even chosen as a software solution vendor.

Low first-time fix rates

The service division had supported a wide range of machinery and models over a long period of time. This made it difficult and challenging to have sufficient knowledge about all possible equipment, technologies, and configurations for every single field service technician. Moreover, the company had expanded across the globe and grown considerably through both organic growth and acquisitions, and the combination of a big complex range of products and impressive growth made training and knowledge management very challenging.

It was difficult and time-consuming for on-site technicians to find documentation that could help them. When they found a document, it was often a very long PDF file with potentially hundreds of pages, which meant it took a lot of time to browse for the exact piece of content that could help out in the given situation.

This was (and still is) not unique to this customer. We continuously see field service personnel in even very large service organizations that spend as much as 30% of their time just locating the right piece of information before they can start unpacking their tools and actually fix the problem. When the problem is not fixed properly on the first visit, the technicians spend an inordinate amount of time on every single visit just looking for the right information to help them out in the situation at hand.

The documentation available to the service technicians consisted of traditional engineering documentation in the form of service manuals, electric diagrams, and the like. Common for these types of documentation is the very long turnaround time for updates (if any). Nobody wants to give feedback on documents that are never updated or seldomly used.

A few initiatives for gathering troubleshooting knowledge had been tried out over the years, with many of them being driven by individuals trying to build a set of articles in Lotus Notes and later converted to an MS Access database. That article collection had grown to several hundred articles, but most were outdated and had never been updated.

Typically, it doesn’t end well for projects driven by individuals without organizational support trying to tackle a big area such as knowledge management, but with the lack of other alternatives, the old article collection was the only option at the time.


The management had the ambition to reach new levels of high-quality service and undergo a transformation in service and support. It was a transformation to be driven by digitalization and how knowledge should be managed in the organization.

It took courage to make the decision to leave old ways behind and start focusing on a new approach to service. Ten years ago, most service organizations tried to tackle the distribution of troubleshooting and service knowledge using static documents, articles, manuals, and other kinds of media that were hard to update and where the turnaround time from user feedback to actual content update was extremely high. The only way to improve service KPIs was to hire more technicians and make an effort to get the best people in the field – and they were always in high demand. In addition, the level of training time for new employees was high, given the complexity of the products.

So for the management in the service department to start considering a service-oriented architecture enabling proactive, human-centered, and data-driven offerings delivered as a truly seamless omnichannel user experience providing dynamic and real-time paths required support from many levels of the organization and a lot of elbow grease.

Nonetheless, the ambition was to support the transformation from “old school” knowledge management to a modern dynamic approach enabling them to give stellar service and ultimately increase customer satisfaction.

A testament to the fact that it required courage was that troubleshooting software really wasn’t a thing at that time. Everyone knew that the organization needed an ERP system, a CRM system, a work order management system, and so on, but investing in an IT system for formalizing something as intangible as tacit knowledge and know-how wasn’t really on the table. Still, the management could see the enormous benefit in the ability to retain knowledge in the organization when people left and the vast potential in being able to fix problems on the first visit – even for less-skilled employees.

The dialog with Dezide started in 2011, and through several meetings and ultimately a pilot project, top management became convinced that this was the right thing to do. They were convinced that not only would a technical knowledge management system help them share knowledge rapidly throughout the organization, but in the long run, the knowledge base would become a commercial and competitive advantage.

Choosing the right knowledge management system

The service division explored different solutions within the troubleshooting space. They required a system that would grow with the business while being easy-to-use as the main users of the tool are service technicians working at customer sites. This requirement eliminated many vendors as they were looking for a solution that could solve their challenges related to easy access to relevant information on the spot and increased knowledge sharing.

In those days, ten years ago, smartphones were still very new, let alone tablets. Field service technicians were equipped with laptops and internet connections were not a given, especially for service technicians in a global company servicing advanced products in environments that can sometimes be difficult to reach. A key feature turned out to be very important – the ability to use the system in offline environments with no internet connection. It was a huge benefit if all technicians would be able to use the system while working in remote areas.

Vendor selection

As growth capabilities and user-friendliness were the main requirements when deciding on the most suitable knowledge management software, some of the most important features of the system were:

Responsiveness and scalability

Having a scalable and responsive tool is essential when handling knowledge about a wide range of products. Responsiveness goes without saying – nobody wants to use a slow system. Scalability is another important area when you start working with a knowledge base system because the decision to start building and maintaining a knowledge base is, by all means, a long-term strategic decision, so it’s important that the system can grow as you do.

Easily manageable from a content maintenance perspective

Continuous innovation and machine improvement created the need to update and manage content in an easy way. It had to be as easy as possible to capture and structure knowledge. This should be the core of the solution, where it was essential that the solution would use a good model for capturing and organizing knowledge. If knowledge cannot be easily stored, updated, and optimized, then the rest of the items in this list would be moot points.


The best way to grow and improve a technical knowledge base is by activating the field’s expert community. Making a contribution to the knowledge base has to be easy and quick to ensure that vital tribal knowledge is captured when the tech is ready to make a contribution.

Strong language support

Worldwide service support results in the need to manage content in many different languages. Language support is not a given, even in modern software systems, so they would have to select software that supported the workflow around translations and internationalization. Many field service technicians are native people, and while technically proficient, they are not expected to be good at English; hence, localized content was a must.

“We have looked at other suppliers of similar software but chose Dezide because of the simplicity of the tool combined with sufficient functionalities like data collection & Bayesian statistics.”

The strong company growth had created a great challenge in keeping their knowledge organized and managed systematically. When the opportunity came to evaluate different software options for organized knowledge, they took it and soon chose Dezide as Dezide fulfilled all the requirements put forward for an intelligent solution that would help them reduce troubleshooting time, fix problems on the first visit, retain knowledge and reduce the training time of new employees.

When the decision was made to go ahead with Dezide, the next step was to start building the initial knowledge base that would be launched to the workforce.

Building and launching the first knowledge base

Getting ready to launch a knowledge base solution to a wider audience is no easy task. An important decision to make is where to start and this needs to be considered carefully.

Based on our experience, it is compelling to go for one of the most popular products and the issues that you are seeing the most in the field for this product, as this is where the guides would be used the most times. Likewise, it is enticing to select a brand new product, as it would be good from a marketing perspective to have a brand new modern guided step-by-step troubleshooting solution in place for this new product when it arrives in the market. Another compelling approach is to build a list of the 50 most occurring issues across the entire product fleet as we definitely would like to reduce the number of these and the time we spend fixing them.

However, in our experience, these might not be the best approaches.

The most popular product might not be the product that sees the highest volume of issues or the most complex issues. A brand new product doesn’t have any good troubleshooting information because the documentation for new products often comes from the engineering department and could be based on previous generations of the product. Finally, the list of the most occurring faults might not be the best choice either, as that list might not tell us if the issues are 5-minute fixes or long-running, complex tasks.

Generally, we recommend that you select products that see common issues that are not easily resolvable. Issues that require a lot of calls to HQ/gurus will ensure that the field service technicians get a good experience from the first uses of the new tool. Considerations like these help narrow down the potential products or product lines that are a good fit for the initial knowledge base.

The customer took this very approach and selected a product with wide distribution and decided to build troubleshooting guides for all the issues that are most difficult to solve and the ones that generate the most re-visits for that product. The knowledge base was launched, and soon, feedback started trickling in along with requests for other troubleshooting guides for that product, so the knowledge base started to expand organically from that point.

The strategy was to implement it as quickly as possible, to get the benefits as quickly as possible for the highest priority items, and then grow it after that initial phase, which worked out very well.

Given the strategy to implement quickly and realize benefits, it was decided that integrations to other existing infrastructure and systems would wait for later phases in favor of getting the knowledge base out there in the hands of the field service technicians.

The result of the first phase was to launch Dezide with custom branding for system familiarity containing the initial knowledge base for one product and with no complicated integrations – all in a few months.

In the next post, we will look at how they are doing today and how they are using Dezide now.

Stay tuned!

Lars Hammer

Co-founder and Chief Executive Officer of Dezide

Lars has 20 Years of Experience with building and implementing AI-powered troubleshooting and knowledge management software in enterprises all over the world.

Service Leaders Move to “Technician Agnostic Service Infrastructure”
Mental Health & Wellness: Creating a Culture of (Technician) Care
Similar Posts