Complaint tracking: a record before it is a conversation

A complaint becomes a fact the day it is written down; until then it is a conversation that ends when the customer calms down or gives up. Tracking one needs a number, an owner, and a closure that names the cause — because the count of the same cause is what tells you whether you have a service problem or a process problem.

Why does the record come before the answer?

Because the answer is recoverable and the record is not. "We will look into it", said on the phone at nine in the morning, leaves no trace; the same sentence in a numbered record is a commitment with a date on it and a person behind it.

The second reason is arithmetic. Three complaints about the same delivery driver mean nothing to a business that cannot count complaints, and a list of forty conversations across WhatsApp, the shop counter and a Facebook page is not a list — it is forty memories. Written down, forty conversations become one number per cause, and the number is what a manager can act on.

Which channels have to land in the same record?

All of them, because every channel loses something different. The phone loses the text. The counter loses the time. The delivery driver loses the order reference. A public comment loses the customer's account, and the customer who complains publicly is the one least willing to repeat themselves.

The rule is simple and hard to keep: one record per complaint, whoever heard it first, and the person who heard it opens the record. That means a colleague who takes a call at the counter needs the same form as the person watching the page — not a message forwarded to the manager, and not a note on paper that reaches the office two days later.

Who owns a complaint?

One named person, not a department, and the owner's job is the next update — not the fix. The person who repairs the fault and the person who answers the customer can be different; what cannot be different is who is accountable for the customer hearing something true by the promised time.

Ownership fails in a predictable way: the complaint is opened against a team, so nobody opens it, and the customer calls again to ask whether anyone read the first message. A name in a field does more work than a status called "in progress".

How fast should the first reply arrive?

Within the working day it arrived, even when the answer is "we do not know yet". A first reply is cheap, and its absence is what turns a complaint into a public one.

Speed of reply and speed of resolution are different promises, and conflating them is how a queue ends up full of items marked urgent. The reply promises attention, with a time for the next contact. The resolution promises the fault is gone, and it depends on parts, a technician, a supplier or a decision that no call centre can make in an hour.

What does closure require?

Four things: what was done, from the customer's side; the cause, in your words; the remedy, whether repair, refund, replacement or an explanation; and confirmation that the customer was told. A closure without a cause is only the end of a conversation.

The cause field is the one people skip, because it requires a judgment rather than a fact. It is also the only field that makes the whole system worth keeping: it turns a list of incidents into a list of reasons, and reasons can be fixed once instead of per customer.

Stage	The record it needs	What it prevents
Intake	Number, channel, who took it	The complaint that evaporates
Ownership	One name and a next-update time	Three people asking the same question
Closure	Cause, remedy, customer told	A repeat arriving as new

How do you see recurrence before it becomes a trend?

Count by cause, not by customer, and read the two counts separately. Three complaints from one customer is a relationship at risk; three complaints with one cause from three customers is a defect, and the second count is the one that costs money.

The monthly view that works is small: causes ranked by count, the oldest open item, the share closed inside the reply promise, and every complaint that came back after being marked resolved. That last column is the honest one — a complaint that returns was closed by the calendar, not by the work.

How do you set this up?

1. Choose one place where a complaint can exist, and make every channel write into it.
2. Number each one, and open it at the moment it is heard rather than at the end of the day.
3. Add the fields that decide something later: channel, order or invoice reference, cause, remedy, who was told.
4. Assign one owner on opening, with a time for the next update.
5. Publish the first-reply promise internally, and make the queue sort by the promise rather than by arrival.
6. Require a cause before closure, and make it a short list rather than free text.
7. Report monthly by cause, and take the top cause to the process review rather than to the team meeting.
8. Reopen rather than duplicate when a closed complaint returns.

Where this goes wrong

• The complaint lives in a personal WhatsApp. The person handling it goes on leave, the customer asks for an update, and the answer starts with "who dealt with you?".
• Everything is urgent. With no promise on the first reply, the queue is ordered by who calls most often.
• Closed to clear the queue. The record says resolved, the customer disagrees, and the same complaint returns a week later as new.
• Cause left as free text. Forty spellings of one fault, and a report that cannot rank anything.
• The complaint is answered, the process is not. The customer is compensated, the same cause produces the same complaint next month, and the cost is paid twice.
• Public complaints get a private answer only. The customer is helped and the audience still sees an unanswered thread, which is the version the next buyer reads.

What this does not cover

This is about the record and the loop, not about scripting what staff say, pricing a compensation, or handling a legal claim — the last one needs a decision from someone with authority, not a field in a form. It also assumes complaints about your own service; a complaint about a courier or a marketplace is a different record with a different owner, and mixing the two hides both.

We build complaint tracking so that every channel lands in one numbered record, one person owns the next update, and the monthly list of causes is short enough to act on.