When the Best Technician Retires: Preserving Service Knowledge Before It Leaves the Company

The best troubleshooter on the service team is rarely the colleague with the most entries in the system. It’s the one who already knows which assembly is being referred to when the call comes in, because he’s been working with that model series for twenty years. If this colleague retires, his knowledge will remain available only as long as the team remembers his personal phone number. Knowledge transfer in the service department is therefore decided by the data structure—and this happens long before the notice period begins. The bottom line for the head of service and executive management:

• The risk lies with just a few people. At mass-production manufacturers with a large installed base, diagnostic expertise is concentrated among a handful of senior technicians per machine generation.
• Recording the data is the easier part. Interviews, tandem assignments, and AI-powered note-taking help capture knowledge that’s stored in people’s minds.
• The benefit is realized only when the data is retrieved. A knowledge article is useful when it appears when you open a ticket for a specific machine, not when it’s just sitting in a wiki.
• A prerequisite is a complete machine file. Without reference to the model series, configuration, and serial number, verified knowledge remains a pool with no recipient.

What Goes with the Technician and What Stays Behind

What is usually documented is the target state: circuit diagrams, maintenance schedules, spare parts lists. What’s missing is the experience gained from instances of deviation. Which fault pattern in the 2011 model series indicates bearing play and which indicates a sensor failure. Which customer operates their system in three shifts and therefore exhibits different wear patterns. Which modification made six years ago was never properly documented. This knowledge is specific to each individual and can be identified by the following signs:

• When things escalate within the team, it’s always the same two or three people.
• The first-time resolution rate varies greatly among technicians, but not among machine types.
• A coworker’s vacation is causing some appointments with certain clients to be rescheduled.
• It takes new technicians months before they can take charge of a product line on their own.
• Repeat visits are becoming more common for older generations of machines.

Demographic pressures follow a different rhythm than the shortage of skilled workers caused by economic conditions. The cyclical shortage has recently eased: According to the ifo Business Climate Survey “Skilled Labor Shortage Is Declining” (February 2026), about 19 percent of companies in the machinery and equipment sector reported a shortage of skilled workers—significantly fewer than in previous years. This does not change the fact that service team members are retiring. These retirements are tied to birth cohorts rather than the order situation, and they can be planned years in advance. That’s the good news: you know when the time will come.

Why Wikis and Explanatory Videos Rarely Solve the Problem

The usual response before retirement is a knowledge capture initiative. The colleague is given four weeks to write down whatever comes to mind and shoot a few videos at the machine. The material ends up on the intranet. Two years later, no one looks for it there anymore. The problem is availability when service is needed, not data entry. Three reasons why inventory isn’t getting where it needs to be: No machine reference. The article is titled “Notes on the H Series” and is stored in a folder. However, his starting point in his daily work is the ticket with serial number 4711. There is no connection between the two, so he can only find the article if he knows it exists. No need for maintenance. If knowledge isn’t maintained as part of the work process, it becomes obsolete. After two software releases and a change in vendors, half of it is no longer accurate, and no one notices because no one looks into it. No format for diagnosis. Free-form text describes what the expert knows. It doesn’t guide anyone through a decision. Someone new to the field needs a clear sequence: symptom, diagnostic step, result, next step. We’ve described how knowledge can be meaningfully embedded in the process in a separate article on integrating knowledge management into service.

Three Ways to Put Your Knowledge into Practice

When it comes to data collection itself, three methods have proven effective in service organizations. They are not mutually exclusive; rather, they come into play at different stages.

Structured Expert Interviews

The format is a guided interview based on real-life cases. You’ll take twenty completed service calls from the past two years that the expert has resolved and work through each one individually: What was the symptom described in the call? What did you check first, and why? How did you recognize the incorrect assumption? The case serves as the anchor; otherwise, the expert will end up stating the obvious because their own knowledge seems self-evident to them. Two hours per session, a meeting minutes taker who comes from the service department and can ask follow-up questions. The result is error profiles with test logic, not just descriptions.

Tandem and Shadowing Assignments

The senior technician goes on a call with a younger colleague, following this sequence: first, the junior observes; then, he works under supervision; and finally, he takes over, with the senior technician available only by phone. This conveys exactly the aspects that no interview can capture: practical skills, prioritizing tasks under time pressure, and interacting with the customer on-site. The effort involved is real; a tandem requires a second technician for each assignment. Plan for this based on the product lines where the reduction takes effect first, not across the board.

AI-Powered Data Collection in the Workflow

For some time now, service reports, phone notes, and call logs have been automatedly analyzed and condensed into drafts for knowledge base articles. A voice-guided interview is also possible: After a call, the technician dictates what was unusual, and receives a structured draft in return, which they simply need to review and correct. The advantage lies in the threshold. Someone who stops writing articles after ten hours on the job might still speak for another three minutes. The final decision on technical accuracy remains with a human; otherwise, half-baked knowledge masquerading as authority finds its way into the system.

What to Include and What to Omit

The most common mistake in data collection projects is the desire for completeness. A technician with thirty years of experience can fill weeks of work without any of it translating into practical results in day-to-day operations. Instead, apply a filter before the first session begins. It is worth noting anything that meets three conditions: The issue occurs repeatedly, the solution cannot be derived from the existing documentation, and a mistake costs time or requires a second trip to the site. Anything already listed in the schematic, maintenance schedule, or spare parts catalog does not belong in an interview. Nor should anything that has happened only once in twelve years. In practice, this filter results in a manageable number of error patterns per product series, and these few account for the majority of escalations. The list serves as the work queue. It can be worked through in just a few sessions and supplemented later as operations continue.

Method	Suitable for	Effort	Limit
Structured Interviews	Fault Patterns and Test Logic by Product Series	2–3 days per expert, spread out	Records only what the expert remembers
Tandem/Shadowing Assignments	Procedures, Prioritization, Customer Interaction	Second technician per assignment	Not scalable; requires preparation before departure
AI-powered data collection	Continuous flow of knowledge from operations	Low per case; one-time setup	Requires subject matter expert approval and clean source data

Anchoring Knowledge in the Machine Context

This is where it is decided whether the data collection is worthwhile. A knowledge article must be linked to the specifics of the service case: the model series, the configuration, and the serial number. This linkage requires that the installed base be organized in a structured manner to begin with. This is exactly what the Digital Machine File (IOTAM) provides: one data record per machine, including its history, modifications, software versions, and service history. Once this structure is in place, knowledge can be linked to it. logicline helped develop the Salesforce integration for Empolis Service Express: Diagnosis knowledge that has been recorded appears in the service console in a context-specific manner for the specific machine while the employee is processing the case. The technician sees the relevant fault patterns for the system in front of them without having to search through an archive first. We’ve covered the methodological aspects of this—namely, structure, peer review, and KCS—in our overview article on knowledge management in service. A typical scenario in machinery and equipment: A senior technician is familiar with the characteristic failure pattern of an older generation of machines because he has seen it repeatedly over the years. None of this is documented. After he leaves the company, the number of escalations for that exact model series increases, and younger colleagues are sent out on follow-up calls more frequently. If these cases are reviewed in advance during interviews and linked to the model series as knowledge articles, the next technician will find the troubleshooting steps when opening the ticket, without even knowing they exist. This knowledge extends even further beyond the field service team. Through Service Decision Intelligence (SDI), the verified knowledge base—along with machine, order, and sensor data—is made available to the inside sales staff handling phone calls and to AI agents in Salesforce. The key here is source citation: Every recommendation shows which product and which data record it is based on, and SDI runs within the customer’s infrastructure, ensuring that the company’s expert knowledge stays within the company. That is the difference between being documented and being actionable.

Classification: Knowledge retention belongs in the “Connect” stage

In the ” Digitize → Connect → Decide → Automate ” model, knowledge transfer occurs at stage two. Stage one provides the prerequisite: the structured machine file. Without it, the documented knowledge has nowhere to be anchored. If you reverse the order and record data first, you’ll end up with material that will have to be painstakingly reorganized later. Those who consider the integration process at the same time lay the groundwork for step three: As soon as knowledge is linked to the asset and combined with service history and operational data, decisions regarding service can be supported in a traceable manner rather than merely described.

Next step

The loss of expert knowledge is a planning problem with a known timeline. The key factor is whether the recorded information can be retrieved when service is needed, and that depends on the database. Two pragmatic approaches:

• Installed Base Assessment – if your installed base is currently scattered across ERP systems, Excel, and file storage systems. Without a clean machine record, the anchor points for knowledge are missing.
• introductory call – once the database is set up and you want to know exactly how data entry and retrieval work together, including which product lines will be addressed first.

In both cases, the rule is: Start with the product lines where the next discontinuation is scheduled, even if the documentation for those lines is the most limited.