The Complaint That Was a Knowledge Problem

A complaint lands. The customer was told one thing on Monday and another on Thursday. Or they were promised a waiver that isn’t available. Or they followed the steps they were given and those steps were last year’s.

The file usually names an agent. Sometimes two. Quality listens to the calls, finds the miss, coaches whoever is still employed. Remediation writes the cheque. Everyone treats it as a handling failure.

Peel it back one layer and a lot of these are knowledge problems that showed up wearing an agent’s name.

How a page becomes a complaint

The pattern is boring, which is why it keeps happening.

The process changed. The article got updated. The floor didn’t. Half of them are still quoting the old rule. Customer A gets the new answer. Customer B, same week, same situation, gets the old one. Customer B finds out, and now you have a complaint and a consistency problem for Risk.

Or the article was current and incomplete. The standard case was written. The exception wasn’t. The except-when lived in someone’s head. The agent who didn’t know that person guessed, and guessed wrong in a way that sounded helpful.

Or there were three articles. The agent searched, opened the first one, and that one was the leftover. Nobody had archived it because it still looked official.

Or the widget in the CRM and the page in the knowledge base had drifted. The human and the bot gave different answers. The customer believed whichever one they heard second.

None of that starts as malice. It starts as two sources of truth. The complaint is how you find out.

In regulated work this is not just a refund. Two customers, different outcomes, same facts. That’s the sentence that turns a quality miss into a remediation file. The agent is the last person in a chain that was already broken.

What the complaint file should trigger

When I was in QA, the useful question after a complaint was not “what did the agent do”. It was “what did they have in front of them”.

If they followed a page and the page was wrong, the page is the incident. Fix it. Archive the extras. Put a review date so it can’t sit wrong for another year. Ask who else opened that page this month, because those customers may be in the same boat and haven’t written in yet.

If they didn’t open anything, that is a different problem. Search failed, or they thought they already knew. Failed searches will tell you the first. The floor leaves that list for you. The second is habit, and habit needs coaching, not another article nobody will open.

If two systems said two things, you do not have a training issue. You have a split brain. One current version, everywhere a human, a widget, or an AI might answer from. Until that’s true, you will keep buying the same complaint.

Write the finding down in the article, not only in the complaint notes. Complaint notes live in a case tool. The next agent never sees them. The next customer gets the same answer that caused the file.

The honest bit

Not every complaint is a knowledge problem. Some people mishandle a call that was written down clearly, and dressing that up as a content gap is how you stop having a standard. I have sat on both sides of that argument.

The tell is whether a careful person, using what you actually published, could have avoided it. If yes, coach the person. If no, the article, the leftover, or the missing exception is the defect, and coaching is how you make yourself feel finished.

A tool can hold one current version, show you who was asked to read the update, and show you the searches that came back empty. I built KnowledgeScout to close the part of this that is a system. It cannot write the complaint response, and it cannot decide whether this file was sloppy handling or a page you should have killed last quarter. That part is still a human looking at the call and the article side by side.

If your complaint themes repeat, stop starting the investigation at the agent. Start at what they were allowed to believe was true.

The KnowledgeScout Team