How do you document a complaint properly?

With a short closing note that records six points: the fault, the product concerned, the cause, the solution, what was agreed with the customer and the lesson learned. Five minutes after the case is closed is enough – what matters is that the note is stored centrally and can be found again later.

Why are old complaint cases so hard to find again?

Because the knowledge is scattered: the correspondence in the case handler's mailbox, the technical diagnosis in the fitter's head, the credit note in the ERP. None of these places can be searched by problem – if you search for the fault, you find neither the email nor the document.

Do complaints belong in the ERP or in the knowledge base?

Both, with a clear division of roles: the ERP handles the transaction – return, credit note, replacement delivery – and remains the leading system for that. The knowledge base adds the solution: diagnosis, correspondence, what worked and what did not. The ERP knows what happened; the knowledge base knows how it was solved.

What does a searchable collection of solutions actually deliver?

Recurring problems are solved much faster the second time, because the documented solution and its source document can be found immediately. New employees also benefit by learning from real cases, and the company spots clusters that point to a product or supplier problem.

How do we start if nothing has been documented so far?

Start with the closing note from the next case onwards – much can be added retrospectively from email threads and service reports that already exist. Routine matters more than completeness: better to document every new case briefly than to run a one-off big project that fizzles out.

Handling complaints: how did we solve this last time?

A company can only answer the question “How did we solve this last time?” in minutes if problem solutions are documented and can be found again – not just the credit note in the ERP, but the solution behind it. This is exactly where everyday work falls short: the transaction is booked cleanly, but the knowledge of what caused the problem and what helped is scattered across mailboxes and people’s heads. This guide shows how complaints can become a searchable collection of solutions that saves hours on the next case.

In brief

The first complaint inevitably costs effort to solve – the second identical complaint should cost almost nothing, but in most companies it still does.
Complaint knowledge today is scattered across mailboxes, phone notes and people’s heads; the ERP only records the document side.
The ERP knows what happened – return, credit note, replacement delivery. The knowledge base knows how the problem was solved.
A five-minute closing note per case is enough as the foundation for a searchable collection of solutions.
With an AI query that includes its source, even the new colleague quickly finds the solution from back then.

Why is the second complaint more expensive than it needs to be?

When a problem occurs for the first time, effort is unavoidable: finding the cause, phoning the supplier, negotiating a solution with the customer. This effort is the price of learning – and well invested if the company learns from it.

The annoying part is the second, identical complaint two years later. It really ought to be dealt with in half an hour: recognise the fault, look up the documented solution, apply it. Instead, the work of solving it starts from scratch, because nobody remembers any more or the colleague from back then has left.

On top of that comes the silent damage with the customer: anyone visibly puzzling over the same thing for the second time seems less assured than the company that can say: “We know this one – we’ll solve it the way we did last time, that worked.” Complaints are moments of trust, for better or worse.

Where do complaints end up today – and why can’t you find them again?

In most SMEs, a complaint case is spread across at least four places: the correspondence sits in the case handler’s mailbox, the technical diagnosis in the fitter’s head, the photos on someone’s phone and the credit note in the ERP. Each of these places is impossible to find on its own as soon as nobody remembers who was responsible back then.

The ERP looks like documentation, but it isn’t: it reliably answers that the customer received a credit note and which items were affected. Why there was a credit note, what the cause was and what should be done differently next time – the document says nothing about that. This is not a flaw in the ERP; it is simply not its job.

And the full-text search in the mailbox? It assumes you can guess the words used at the time. If you search for “coating flaking off”, you won’t find the email that talked about “paint detaching at the edges”. So the knowledge formally exists but is lost in practice.

What belongs in a well-documented complaint?

Well documented does not mean documented at length. Six building blocks, noted in keywords, make a case reusable later:

Building block	Guiding question	Example
Fault	What exactly was the complaint about?	Coating is detaching at the edges
Product and circumstances	Which product, which batch, which use?	Series X, installed outdoors
Cause	What was really behind it after inspection?	Substrate too damp during processing
Solution	What worked – and what did not?	On-site rework was enough; replacement was unnecessary
Agreements	What was promised to the customer?	Follow-up check agreed after six months
Lesson	What will we do differently in future?	Add moisture measurement before processing to the report

The decisive building block is the solution, including the wrong turns. That the rework was enough and replacement was unnecessary is exactly the information that saves time and discussion on the next case – and it appears in no document.

What roles do the ERP and the knowledge base play in complaints?

The division of roles is clear, and it should stay that way: the ERP or the accounting system handles the transaction – return, credit note, replacement delivery, warranty processing. This document side belongs in the leading system and nowhere else; a knowledge base changes nothing about that.

The knowledge base adds the knowledge side, for which there is no room in the ERP: the closing note, the key emails, the inspection report, the photos with a short caption. In short: the ERP knows what happened – the knowledge base knows how it was solved.

Together they give a complete picture. The case handler sees in the ERP that the customer received a credit note two years ago and asks the knowledge base: “What was the problem back then, and how did we solve it?” The answer comes from the closing note – with its source, so every step can be checked in the original.

How do you build the collection of solutions step by step?

Make the closing note routine: every closed case ends with five minutes of documentation following the six-building-block scheme – as much a matter of course as the credit note itself.
Keep the template short: half a page with six fields is enough; anything longer reduces willingness. Dictating is expressly allowed – a voice note is better than no note.
Store centrally: collect notes, key emails and photos in one place, assigned to the customer and the case – instead of spread across personal mailboxes.
Add old cases: record the biggest cases of the last two or three years from email threads and service reports – the documents already exist.
Make it queryable by AI and test it: add the collection to an AI knowledge base and check it with real questions: “Have we ever had detachment on this product before?”

How companies anchor such routines permanently in everyday work – not only for complaints – is shown in the practical guide to the AI knowledge base.

What changes in everyday work – and where are the limits?

The most noticeable effect: recurring cases are solved in minutes the second time round. Patterns also become visible – if the same fault turns up for the third time, the company talks to the supplier on the basis of documented cases rather than vague memory.

Onboarding changes too. New employees learn from real cases in their own company instead of dry theory: how do we respond to which complaint, what was promised to whom, which solutions have proven themselves. The knowledge of experienced colleagues remains available, even when they are on holiday or long since retired.

The limits should be stated honestly: an AI can be wrong, so checking the cited source document is part of the routine before any commitment to the customer. And documentation does not happen by itself – management has to want the five-minute routine, lead by example and insist on it.

If you would like to introduce this in your own company: the implementation process shows how existing emails and reports become a queryable collection of solutions in a few weeks.