Modular Support Knowledge: Cases Emerge Instead of Being Written

The building-block principle breaks support knowledge down into reusable cause, symptom, and solution components, from which cases combine automatically instead of manually. Anyone who maintains technical documentation for service knows the classic alternative: every new error message, every new machine variant, and every new combination of cause and symptom means a new document, or, as many companies call it, a new case, the complete description of cause, symptom, and solution for a specific fault pattern, with its own metadata.

For already complex product portfolios, the number of these documents quickly grows into the thousands, and with it the effort of keeping them consistent with every change.

The way out is to stop maintaining the finished case and instead maintain its components. Three building blocks form the core:

• Cause: the description of what triggers a fault or an undesired behavior. It is the central element to which symptoms and solutions are assigned.
• Symptom: the description of the accompanying effect that makes a fault recognizable. This also includes error messages, the text displayed on a machine's or system's user interface.
• Solution: the description of the process that resolves the cause.

These building blocks are linked through clearly defined relationships instead of being reformulated in every single case. Even though the symptom is often the first visible clue for the user, it makes sense to start maintenance with the cause. From there, both relationships can be assigned cleanly: which symptom it triggers and which solution resolves it.

Fictional, for illustration only: The customer reports the symptom "gearbox makes unusual noises". Different causes and solutions come into question. If oil is missing, the solution is to top up the gear oil. If a gear wheel is damaged, the gearbox has to be replaced.

From a single symptom, two causes, and two solutions, two complete cases can already be combined, without having to write two separate documents. This is exactly why a case is not created from the symptom alone, but from the combination of symptom, cause, and matching solution.

If a third cause is added later, for example a worn bearing, the number of cases grows automatically, without touching the existing building blocks.

The most important effect of this principle: a solution, once maintained, can be assigned to any number of cases without existing multiple times. If a solution is adjusted, the change automatically applies to every case in which it is used. The same applies to symptoms. Instead of maintaining copies, a building block is reused.

This also affects translation. Each building block is translated only once, regardless of how many different cases it later appears in. Depending on usage, causes alone can save around 60 to 70 percent of the content that would otherwise need to be maintained.

Companies that break their cases down into such building blocks from the start gain noticeable time and cost advantages, especially in translation costs and creation effort, and benefit accordingly.

Not every building block applies everywhere. Assignments to product categories or individual articles can restrict where a cause, symptom, or solution actually applies. Instead of writing a separate document for every variant, the scope of a building block is simply maintained.

Depending on the type of relationship, this scope is inherited by related objects, or not, depending on what makes sense from a subject-matter perspective.

Beyond the pure content, evaluation attributes can also be maintained on the building blocks: how likely a cause is, how much labor time and material cost a solution requires, how much inspection time is realistic to plan, and how relevant a case is for publicly accessible online help.

This evaluation is editorial work: it later ensures that service staff see the matching cases in a sensible order, taking probability, effort, and cost into account.

New case combinations form automatically and regularly in the background as soon as new assignments between building blocks arise. Before a change is released, the editorial team reviews the affected case combinations. A report shows which cases an edited building block affects, including language selection and release status.

If a combination loses its basis, for example because an underlying building block changes, the system automatically withdraws an existing release. This lets the editorial team check, before release, whether the created or changed cases are complete and correct from a subject-matter perspective.

What matters is that not just theoretically possible cases are created, but cases that actually occur in day-to-day service work. Many companies already have a wealth of experience for this: known fault patterns, proven solution paths, and feedback from past deployments. This knowledge forms the basis for maintaining the building blocks.

Whatever is newly noticed or still missing in the field can be raised specifically through feedback from service technicians and then reviewed editorially. This way, the knowledge base grows not detached from practice, but along the cases that are genuinely relevant in service.

How strongly the building-block principle pays off can be shown with a simple example. If ten causes are each combined with five symptoms and three possible solutions, this already results in 150 possible case combinations.

In larger knowledge bases, this leverage grows accordingly: the number of usable cases increases significantly, while the maintenance effort remains limited to the individual building blocks.

A building-block system of causes, symptoms, and solutions cannot be represented as a loose collection of documents. For usable knowledge to emerge from it in service, data structure and system functionality have to work together.

On the data side

It is not enough to treat cause, symptom, and solution as plain text sections. Each building block must be an independent, referenceable object. This includes its own metadata and clearly defined relationships to other building blocks.

The concrete scope of validity, however, only emerges at the level of the case, or the case combination: that is where it is defined for which product category, article, or context this combination actually applies. Evaluation attributes such as probability, effort, or relevance also need to be available in structured form so they can later be evaluated and used to determine order in service.

On the system side

What's needed here is the ability to automatically form matching case combinations from these relationships and to control their release in a targeted way. Once a solution is known, the system can also derive concrete actions from it. If the solution is, for example, "replace the motor", a step-by-step guide for the service technician can be attached to it. This turns the case combination into more than just a pointer to cause and solution: it becomes directly usable support during a service call.

Without these two levels, the building-block principle remains a good idea on paper. It only becomes practically usable through the data structure and the system capabilities behind it.

The building-block principle changes where editorial work actually happens: no longer in writing individual cases, but in maintaining the building blocks and controlling the combinations that result from them.

Causes, symptoms, and solutions can usually already be linked from a subject-matter perspective at the point of capture. An extensive case database is not strictly required for this from the start. Existing cases can additionally be analyzed to reveal further patterns and reuse potential.

If a case database already exists, it is worth looking at what can be consolidated: which symptoms actually trace back to the same cause, which solutions repeat, and which categories can be grouped together. These commonalities give rise to the actual knowledge building blocks from which new cases can later be combined.

Anyone struggling with a growing volume of documents should do exactly that: check their own knowledge base to see how many of the documents currently maintained can be traced back to reusable building blocks.

If you would like to go deeper into this topic, or simply exchange ideas about it, you are warmly invited to get in touch. We have been working on exactly these kinds of questions around technical documentation and knowledge management for more than 30 years.