Handling WhatsApp complaints without losing the thread

A complaint arriving on WhatsApp is the same complaint that might have arrived by email, and it will not be experienced that way by either side. The channel changes the dynamics in three specific ways, and each one raises the cost of handling it badly.

The first is pace. WhatsApp is where people have immediate conversations, so a silence that would be unremarkable in an email thread reads as being ignored. A customer who has waited an hour for an acknowledgement has, in the context of this channel, waited a long time.

The second is that the customer holds the whole history. Every message the business has ever sent them sits in one scrollable thread, including the confirmation that promised a delivery date and the reminder that got the time wrong. A business that contradicts something it said earlier will be corrected with a screenshot, and the record is on the customer's device rather than in a system the business controls.

The third is that the block button is immediately available. A customer who has decided the conversation is hopeless can end the relationship, and blocks feed the quality signals that determine how many people the business can reach. A badly handled complaint is not only a lost customer but a small, cumulative cost to the channel itself.

The most common failure is the well-intentioned one: the business reads the complaint, starts looking into it, and says nothing until it has an answer. From the inside that is diligence. From the outside it is indistinguishable from being ignored, and the customer's next message is usually angrier than the first.

Acknowledging first costs one message and changes the dynamic entirely. It should do three things: confirm the specific problem in the business's own words, so the customer knows they were understood rather than processed; say what happens next and roughly when; and avoid conceding or denying anything about fault before the facts are known.

Restating the problem specifically is what separates a useful acknowledgement from a form response. "Sorry for the trouble, we're looking into it" could be a reply to anything. "Sorry — so the parcel arrived but the size is wrong, and you need it before the weekend. Let me check what we can do and come back to you within the hour" demonstrates that somebody read it.

That last part is a commitment, and it should be one the business can keep. A stated time that passes without contact converts a manageable complaint into a second grievance about being ignored, which is harder to resolve than the original problem.

Complaints rarely disappear because someone decided to ignore them. They disappear at handovers, and there are a small number of recognisable points where it happens.

The first is the informal internal forward. Somebody screenshots the conversation, sends it to a colleague, and the colleague either does not see it or assumes it was handled. Nobody owns the item, and the customer's thread goes quiet while, internally, everyone believes it is being dealt with.

The second is the shift change. A conversation half-resolved at the end of one person's day is context that exists only in that person's head. The next person sees a thread with no indication of what was already checked, and either starts again — asking the customer questions they have answered once — or waits for the first person to return.

The third is waiting on something external. A complaint that depends on a supplier, a courier or a refund process has a natural dead period, and dead periods are where things are forgotten. The customer, who cannot see that anyone is waiting on anything, experiences it as abandonment.

The fourth is the almost-resolved case. A replacement dispatched, a refund initiated, an apology accepted — and nobody confirms that the thing actually happened. These close in the business's mind and stay open in the customer's.

The remedy is not necessarily a support system. It is making four things explicit, by whatever means the business already has.

Ownership: one named person is responsible for each open complaint at any moment. Not a team, not a group chat, one person — because responsibility distributed across several people is responsibility nobody feels. If it moves, the handover is explicit and acknowledged rather than assumed.

State: what has been checked, what is being waited on, and what the next step is, written where the next person can read it rather than held in someone's memory. Enough that a colleague can pick up the conversation without asking the customer to repeat themselves.

A next action with a date: every open complaint has one, even when the next action is only "check whether the courier has responded". An item with no dated next step is the definition of a dropped one.

A closing confirmation: the customer is told, explicitly, that the thing is done. This is the cheapest of the four and the most frequently skipped, and it is what stops a resolved complaint from being reopened by a customer who never learnt it was resolved.

Whichever tool a business uses, whether a shared inbox with assignment, a spreadsheet or a notebook, those four are what matter. A sophisticated system used without them fails in the same places.

There is a mechanical constraint on complaint handling that is easy to overlook. Free-form replies are only available inside the customer service window, which closes 24 hours after the customer's last message. A complaint that takes three days to investigate will outlive the window, and the business will find it cannot simply send an update.

This matters most for exactly the complaints that are hardest to resolve, since those are the ones that take longest. A business that has been quietly waiting for a supplier to respond may discover that the channel it was going to use to explain the delay is no longer available for free-form messaging.

Two habits address this. First, do not let the window lapse in silence: an interim update sent while it is still open both keeps the customer informed and, if it prompts a reply, resets the window. This is a genuine reason to send progress updates rather than waiting for a resolution.

Second, have an approved utility template suitable for a case update, prepared before it is needed. A business that discovers mid-complaint that it needs a template, and that approval takes time, is stuck with a customer it cannot reach and no way to shorten the wait. That is a foreseeable problem, and foreseeing it is considerably cheaper than living through it.

Individually a complaint is a problem to fix. Collectively complaints are the cheapest research a business has access to, and most of that value is discarded because nothing is recorded beyond the resolution.

A minimal record is enough: what the complaint was about, in a category consistent enough to count. Even a rough tally reveals things that are invisible case by case. The same delivery estimate producing repeated complaints is a wrong estimate rather than a series of unlucky orders. Repeated confusion about what is included in a service is a description problem. Repeated complaints traceable to one supplier are a supplier problem being absorbed as customer service work.

The pattern that most rewards attention is the complaint that should have been prevented by information the business already had. A customer complaining they were not told about a charge is describing a gap in a confirmation template. One asking where an order is may not be complaining about the delivery at all, but about not being told. Those complaints are the ones with the highest return on fixing, because the fix removes a whole class of future messages rather than resolving one case.

Which is also the honest measure of whether complaint handling is improving: not how quickly complaints are resolved, but whether the same complaints keep arriving.