Knowledge management in service: How mechanical engineers structure diagnostic knowledge and make it usable

When an experienced service technician retires, years of diagnostic knowledge often leave the company. At the same time, service employees spend a considerable amount of their working time searching for information that is documented somewhere – on SharePoint, in PDFs, in old service logs. The problem is rarely a lack of knowledge, but rather the lack of structure in which it is available.

Structured knowledge management in service is the answer: diagnostic knowledge is created directly in the work process, is linked to the specific machine and is available at the touch of a button the next time service is required – regardless of which technician takes over the job.

• Problem: Knowledge is scattered in heads, PDFs and isolated solutions. Diagnosis takes longer than necessary, initial solution rates suffer, new employees need months to become productive and independent.
• Solution: A machine-context-related knowledge base that is visible in the service console and grows with every use.
• Result: Faster diagnosis, higher first-time fix rate, documented domain knowledge that remains in-house during the generation change.

logicline has co-developed the Salesforce integration of Empolis Service Express – diagnostic knowledge appears contextually related to the specific machine directly in the Service Cloud, not as a separate research tool.

Why knowledge management in service is becoming a strategic issue

Three factors make the issue particularly urgent for the mechanical and plant engineering sector.

Generational change. Over the next few years, service organizations will lose experienced technicians who have accompanied machines for decades. What they know – typical error patterns after 10,000 operating hours, unusual combinations of sensor values, undocumented configuration changes – is rarely written down. When these employees leave, a considerable amount of service expertise goes with them. Structured documentation is the only sustainable answer.

Complexity of the installed base. A machine manufacturer with several thousand systems worldwide has machines of different generations, customer-specific configurations and different maintenance histories. Diagnostic knowledge that is suitable for machine generation A may be incorrect for generation B. Without a structured link between knowledge and machine file, the probability of errors multiplies.

Pressure on first-time fix rate. Today’s customers expect a service visit to solve the problem. Every second visit costs money, ties up technician capacity and damages the customer relationship. If you want to noticeably increase the FTF rate, you need technicians who can access the knowledge of all previous assignments on site – not just their own.

What Knowledge-Centered Service (KCS) means in mechanical engineering

Knowledge-Centered Service is an established methodological framework that originally comes from IT support and can be easily transferred to mechanical engineering service. Unlike traditional approaches, in which a small number of experts maintain centralized documentation, KCS is based on a simple principle: Every technician contributes knowledge while solving problems. Knowledge is created where it is needed – in the service case itself.

Four principles underpin the approach:

• Abundance: Knowledge grows by sharing, not by hoarding. Those who document help others and themselves in the next similar case.
• Added value: Knowledge is created as a by-product of problem solving, not in separate documentation sprints.
• Demand orientation: Knowledge is validated through use. What is frequently found is relevant. What is not accessed can be discarded.
• Trust: Technicians are allowed to create and improve knowledge articles themselves – not just a small group of editors.

These principles are less a technology decision than a cultural one. The tools follow.

How the double loop works

KCS works with two toothed loops:

Solve Loop – embedded in every service case:

1. Technician searches the knowledge pool for articles matching the reported symptom
2. If he finds one – he applies it and improves it if necessary
3. If he does not find one, he immediately documents the solution he has found in a form that can be read by others
4. The knowledge article is linked to the specific machine, the error code and the solution

Evolve Loop – continuous structural work:

1. Frequently used articles are maintained, supplemented and synchronized with current machine generations
2. Rarely used articles are checked – are they outdated or do they describe a marginal problem?
3. Patterns across many articles are identified – where do complaints accumulate, where do knowledge gaps arise?

In service organizations that consistently implement KCS, the first-contact resolution typically increases noticeably and the training time for new technicians is reduced by weeks to months. The exact figures vary according to machine complexity and starting level – the decisive factor is not the individual percentage, but the direction: less knowledge in heads, more in the structured basis.

Connecting knowledge and digital machine files – the decisive step

Knowledge management rarely fails due to a lack of knowledge articles. It fails because knowledge is separated from context. A technician standing in front of a malfunctioning system does not want to search a general knowledge pool for “vibration bearing damage” – he wants to see what has already been documented about this machine generation, with this configuration, in comparable applications.

This is exactly what the link to the digital machine file solves. The digital machine file on Salesforce manages machines, components, configurations and service history in a structured manner. When knowledge articles are linked to these objects, access changes fundamentally:

• When a service ticket is opened, knowledge articles matching the machine type and the reported error code appear automatically
• Service history and knowledge articles are displayed in the same view – the technician can see whether the problem has already occurred on this system and how it was solved
• Interactive decision trees guide you through the diagnosis, based on the service status of the specific machine
• QR codes on the system directly open the machine-specific view with knowledge, service history and open notes

The effect: switching between several systems is no longer necessary. Knowledge is no longer “stored somewhere”, but part of the service reality.

Empolis Service Express in the Service Cloud

For the knowledge base itself, we rely on Empolis Service Express – a specialized platform for structured service knowledge with guided troubleshooting and decision trees. logicline co-developed the Salesforce integration of Empolis Service Express, so that the Empolis knowledge base does not run as a separate product on the side, but appears directly in the Service Cloud – context-related to the specific machine, with the same authentication, in the same workflow.

In practical terms, this means that when the technician opens a service case, they not only see the Empolis articles on the error message, but also the 3D models of the affected component, the associated diagnostic steps and similar cases from the service history – all in one view. If necessary, they can escalate from the same console to a remote specialist with a single click, the integration of which logicline also helped to develop (see IoT data during service calls).

This is the difference between a knowledge tool that exists parallel to the actual work process and an integrated knowledge layer that is part of the daily work.

SDI as the intelligence layer behind the knowledge base

A structured knowledge base is the foundation. But the real leverage lies in the fact that AI agents and office staff can access this basis without relying on the statistical probability of a generic large language model.

This is where Service Decision Intelligence (SDI) comes into play. SDI is the intelligence layer between data sources – knowledge articles, IoT telemetry, service history, ERP data – and the AI front end such as Agentforce, Claude or Copilot. It ensures that the AI does not hallucinate, but accesses a citable knowledge base with proof of source and confidence score.

In concrete terms, this means knowledge management:

• AI agents can retrieve diagnostic knowledge from Empolis and combine it with the specific service history
• Every recommendation comes with a source reference – technicians and service management know where the answer comes from
• SDI runs on the machine builder’s infrastructure (Azure or AWS, EU region) – the service knowledge remains under the company’s control, does not flow into external training models and is AI Act-compliant from the outset

This means that the knowledge base is not only documented, but can also be used to make decisions. It becomes the foundation on which the next stage of service digitalization is built: AI-supported decision intelligence.

In the 4-step model: Where knowledge management takes effect

Knowledge management belongs to the Networking level of the logicline level model:

Anyone who does not yet have a structured machine file in level 1 should start there. Knowledge management without a machine file anchor remains a generic pool of knowledge – valuable, but not half as effective as context-related knowledge.

Four steps to introduction in service

1. embed knowledge capture in the ticket system

The documentation must be created where the problem is solved – not in a separate documentation sprint later on. Structured templates for typical case types are stored in the Salesforce ticket system: Tool settings, material deviations, calibration steps. The technician documents as he solves.

A mobile service app with offline mode ensures that deployments are also recorded without a network connection. As soon as a connection is re-established, the solution synchronizes with the central knowledge base.

2. structure knowledge in the machine context

Knowledge articles are not stored in a flat list of topics, but are linked to machines, components and error codes. Standardized templates create consistency and enable automatic categorization. QR codes on the machine modules immediately provide the machine-specific view when scanned: error history, checklists, relevant knowledge articles.

An intelligent search that forgives synonyms and typing errors ensures that technicians find the right answer even under time pressure. With Empolis Service Express, this search is already part of the platform – it can be used via the co-developed Salesforce integration in the service console.

3. establish peer review as a routine

Quality assurance must be easy, otherwise it won’t happen. Clear approval workflows directly in the system: a knowledge article is created, a second technician checks it for the next similar case and improvements flow back. For complex cases, technicians can start problem-related chats in the ticket system and then transfer the solution to a permanent knowledge article.

Important: Knowledge coordinators (often experienced service employees with a reduced field service workload) check and publish instead of writing all the articles themselves. This ensures that the knowledge base remains a joint effort and not a bottleneck.

4. guided diagnosis with decision trees

In addition to the knowledge articles, guided diagnostic flows in Empolis Service Express provide step-by-step instructions for complex problems – from camera calibration to material adjustments and safety checks. These diagnostic flows are embedded in the service console and linked to the specific machine.

Even less experienced technicians can handle challenging service cases without blocking the internal hotline or having to call the manufacturer back. This reduces the escalation load for senior technicians and makes the service scalable.

How to measure the effect

Key figures that count

If you introduce knowledge management without measuring the initial state, you will not be able to prove any effect later on. These values should be recorded before the start:

• Mean Time to Resolution (MTTR): Average resolution time per service ticket
• First-time fix rate (FTFR): Proportion of cases that are solved on the first assignment
• Time-to-productivity: How long does it take a new technician to reach the target values independently?
• Ticket deflection rate: How many customer queries are resolved directly via knowledge articles in self-service without a ticket being created?
• Contribution rate: How many knowledge articles are created or improved by technicians per month?
• Update rate: How many articles are checked each quarter? A sensible target is a fifth to a quarter of the inventory – otherwise the content will expire.

Outdated knowledge articles are more dangerous than missing ones. Once you have followed a wrong recommendation, you no longer trust the knowledge base and return to calling an experienced colleague.

Start with a pilot in 8-12 weeks

A pilot project in a clearly defined service area or machine type is the pragmatic way to get started. Three phases:

1. Blueprint (2-3 weeks): Inventory of existing knowledge sources, target definition, tool selection, definition of the pilot scope
2. Preparation (2-3 weeks): Create knowledge map, develop templates, configure Salesforce + Empolis integration, train pilot team
3. Pilot (4-6 weeks): Real service cases, continuous improvement, weekly reviews with the pilot team

After the pilot, the system is evaluated, lessons learned are documented and the roll-out to other service areas is planned. Innovation labs – small teams that test the system with real service cases before it is rolled out widely – have proven to be more effective than big-bang rollouts.

Next step

Knowledge management in service is not a tool problem, but a structural problem. The tools (Empolis Service Express, Salesforce Service Cloud, Knowledge Management) are mature. What makes the difference is the integration into the daily work routine and the link to the specific machine.

The first step is therefore not the next software selection, but an honest inventory: Where is the service knowledge today? Which machines are in the field without a documented diagnostic history? Which technicians have critical domain knowledge that is not written down?

Two pragmatic approaches:

• Installed Base Assessment – when the machine data is scattered today and the structured basis is missing before knowledge management. 4-6 weeks, clearly defined, with a concrete leverage report at the end.
• Initial consultation – when the database is ready and you want to evaluate how Empolis Service Express will work productively in your Salesforce environment and which pilot service areas are best suited.