The Customer Who Complains Is Still Talking to You

Here is an invented example that most teams will recognise. Two customers hit the same problem on the same afternoon: uploading their monthly invoice file fails with a message that says only "Something went wrong". The first writes a long email to support, copies their account manager and uses the word "unacceptable" twice. The second closes the tab, exports their data the following week and never logs in again.

Inside the company, the first customer becomes a meeting. The second becomes, at most, a line in a churn report a quarter later, with no reason attached. Most teams treat the first customer as the problem. I think the second one is.

Exit and voice

Albert O. Hirschman gave these two customers names in Exit, Voice, and Loyalty (Harvard University Press, 1970). When the quality of what a firm provides slips, he wrote, management finds out through two alternative routes. The first is exit: "Some customers stop buying the firm's products or some members leave the organization: this is the exit option." The second is voice, in which customers "express their dissatisfaction directly to management", to a higher authority, or in public protest to anyone who will listen.

The two routes carry very different amounts of information. Exit arrives as a number: revenue drops, renewals do not happen, a cohort quietly shrinks. In Hirschman's account, the falling revenue is what pushes management to go looking for whatever faults caused the exit. The number tells you that something is wrong, late, and rarely what. Voice arrives with a description, a time, a screen and often a screenshot. It is noisy and sometimes rude, but it is the only one of the two routes that explains itself.

That changes how I read a long, angry email. The person who wrote it is still spending effort on you; they have not left yet. The customer to worry about is the one who had the same experience and decided you were not worth an email.

The ending is what they remember

How you answer matters more than it seems, and two studies co-authored by Daniel Kahneman suggest why. In a 1993 experiment by Kahneman, Barbara Fredrickson, Charles Schreiber and Donald Redelmeier, 32 male students each did two trials. In the short one, they held a hand in water at 14 °C for 60 seconds. In the long one, the other hand stayed in for the same 60 seconds and then 30 seconds more while the water was gradually raised to 15 °C, still painful but less so for most of them. Asked which trial they would rather repeat, 22 of the 32 chose the longer one: more pain in total, with a better end.

In a 1996 study, Redelmeier and Kahneman recorded pain in real time from 154 patients having a colonoscopy and 133 having lithotripsy. Afterwards, patients' judgements of the total pain tracked the worst moment and the last three minutes of the procedure. Durations varied widely, yet the long procedures did not stand out in memory as the painful ones. The 1993 paper calls this a peak-and-end pattern: the memory of an unpleasant episode is often dominated by its worst and final moments, while its length counts for little.

These were studies of pain, not of software, so treat what follows as my inference rather than a measured result. A failure that makes a customer angry enough to write is often the worst moment of their experience with you, and your handling of it is very likely the end. Answer slowly, vaguely or defensively, and that is the version they keep and retell. Answer well, and the worst moment at least comes with a decent ending.

One complaint is evidence, not a verdict

None of this means the loudest customer should set the roadmap. A complaint is one person's account of one experience. Treat it as a ticket to close and you throw the information away; treat it as a demand to satisfy and one customer is steering your product. It deserves an answer and an investigation, not automatically a feature. What a customer asks for is often the apparent issue, and the need behind it can be something else, the distinction I wrote about in Beyond the Obvious.

So treat the complaint as a lead, and go looking for the customers who hit the same problem without telling you. Their exit is not silent in your data. It only looks silent from the support inbox:

• Logs: search for the same error, endpoint and release over the last few weeks, and count distinct accounts, not events.
• Funnels: check whether drop-off at that step changed when the problem started.
• Behaviour after the error: how many of the affected accounts came back within a week, compared with similar accounts that were not affected?
• Other channels: search older tickets, sales notes and app reviews for the same symptom in different words.

If the error shows the user a reference number and writes the same number to the logs, this search takes minutes instead of days, and every future complaint arrives with a pointer to the request that failed. Integrations need the same care. I worked on integrations with Fawry, Payfort and Salesforce at Vezeeta, and the general lesson from that kind of work is simple: when a provider's call fails, the customer does not see the provider. They see you, so your logs had better show which side failed.

The count also tells you what kind of problem you have. In the terms I used when writing about knowing which Kano category a feature belongs to, most complaints about something missing or broken point at must-be or one-dimensional qualities, because by definition those are the ones whose absence makes people unhappy. For a must-be feature, silence is the best result you will ever get. A complaint means it has broken for someone, and the logs tell you for how many.

What to do with the next complaint

1. Reply within the day, to the person, about their case. Say what you know, say when they will hear from you next, and keep that promise.
2. Reproduce it before anyone debates it.
3. Count who else hit it before deciding how big it is.
4. Decide: fix it, offer a workaround, or explain why it will stay as it is. A clear "no" with a reason ends better than "we will look into it".
5. Close the loop. Tell the customer what changed. That message is the end of their story, and if the peak-and-end studies carry over, it is the part that will weigh most.

The angry email is the cheap version of this lesson. The expensive version arrives a quarter later as a number, with no explanation attached.

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise software delivery, from pre-sale to handoff.