How do you document a complaint properly?

With a short closing note covering six points: the fault, the product concerned, the cause, the solution, what was agreed with the customer and the lesson learned. Five minutes once 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 technician’s head, the credit note in the ERP. None of these can be searched by problem – if you search for the fault, you find neither the email nor the credit note.

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

Both, with clearly divided roles: the ERP handles the transaction – return, credit note, replacement delivery – and remains the master system for it. The knowledge base adds the solution: the diagnosis, the correspondence, what worked and what didn’t. The ERP knows what happened; the knowledge base knows how it was solved.

What does a searchable collection of solutions actually achieve?

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

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

Start writing the closing note from the next case onwards – a lot can be added after the fact from existing email threads and service reports. Routine matters more than completeness: it’s better to document every new case briefly than to launch a one-off big project that fizzles out.

Handling complaints: how did we solve this last time?

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

In brief

Solving the first complaint inevitably takes effort – an identical second complaint should take almost none, but in most companies it still does.
Knowledge about complaints is currently scattered across mailboxes, phone notes and people’s heads; the ERP only records the paperwork.
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 to lay the foundation for a searchable collection of solutions.
With an AI query that cites its source, even a new colleague quickly finds the solution used last time.

Why does the second complaint cost more than it should?

When a problem crops up for the first time, effort is unavoidable: finding the cause, ringing the supplier, agreeing a solution with the customer. That effort is the price of learning – and money well spent if the company learns from it.

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

On top of that comes quiet damage to the customer relationship: a company that is visibly puzzling over the same problem for the second time seems far less sure of itself than one that can say: “We know this one – we’ll fix 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 is spread across at least four places: the correspondence sits in the case handler’s mailbox, the technical diagnosis in the technician’s head, the photos on someone’s phone and the credit note in the ERP. None of these can be found on its own once nobody remembers who dealt with the case.

The ERP looks like documentation, but it isn’t: it reliably tells you that the customer received a credit note and which items were affected. Why there was a credit note, what caused the problem and what should be done differently next time – the record says nothing about that. That isn’t a flaw in the ERP; it simply isn’t its job.

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

What does a well-documented complaint include?

Well documented doesn’t mean documented at length. Six building blocks, jotted down in a few words, 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 most important building block is the solution, including the false starts. The fact that rework was enough and a replacement wasn’t needed is precisely the information that saves time and discussion on the next case – and it appears in no other record.

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

The roles are clearly divided, and they should stay that way: the ERP or accounting system handles the transaction – return, credit note, replacement delivery, warranty processing. These records belong in the master system and nowhere else; a knowledge base doesn’t change that.

The knowledge base adds the knowledge that has no place 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 the full 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 up the collection of solutions step by step?

Make the closing note a routine: every closed case ends with five minutes of documentation following the six building blocks – as routine as issuing the credit note itself.
Keep the template short: half a page with six fields is enough; anything longer puts people off. Dictating is explicitly allowed – a voice note is better than no note.
Store it centrally: keep notes, key emails and photos in one place, assigned to the customer and the case – rather than spread across personal mailboxes.
Add old cases: write up the biggest cases from the last two or three years using email threads and service reports – the material already exists.
Make it searchable with 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?”

The practical guide to the AI knowledge base shows how companies make routines like this a lasting part of everyday work – not only for complaints.

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 come to light – if the same fault turns up for the third time, the company can talk to the supplier on the strength of documented cases rather than vague memories.

Onboarding changes too. New employees learn from real cases in their own company rather than from dry theory: how we respond to which complaint, what was promised to whom, which solutions have worked. Experienced colleagues’ knowledge stays available, even when they are on holiday or long retired.

The limits should be stated honestly: AI can get things wrong, so checking the cited source document is part of the routine before promising anything to the customer. And documentation doesn’t happen by itself – management has to want the five-minute routine, lead by example and insist on it.

If you’d like to introduce this in your own company, the implementation process shows how existing emails and reports become a searchable collection of solutions within a few weeks.