96% of customers who had a high-effort service experience became more disloyal. Reducing effort beats exceeding expectations, and effort is repeat contacts and transfers.
Reducing effort beats exceeding expectations
The most useful piece of research in customer service is also the one that contradicts most of what gets said about it. Matthew Dixon, Karen Freeman and Nicholas Toman, writing in Harvard Business Review in 2010 from a study of more than 75,000 customer interactions, found that delighting customers does not build loyalty in any measurable way — but that making them work hard reliably destroys it.
The numbers are stark: 96% of customers who had a high-effort service experience became more disloyal, against 9% of those who had a low-effort one. High-effort interactions are several times more powerful at driving customers away than exceptional ones are at keeping them.
And effort
turns out to be specific and mundane. Having to make contact more than once. Having to repeat information already given. Being transferred. Switching channels because the first one failed. None of those are failures of warmth. They are failures of process, and they are the things a support organisation can actually fix.
That finding organises this pack. The goal of every prompt here is to resolve the thing on the first attempt, in the customer's own terms, with a next step they do not have to chase.
The shape of a good reply
Nearly every customer-facing prompt in this pack produces the same three-part structure: acknowledge, address, and give a clear next step. Acknowledgement without a resolution is customer-service theatre. A resolution without acknowledgement reads as dismissive to someone who is already frustrated. And a reply without an explicit next step guarantees a second contact, which is the exact thing that destroys loyalty.
There is also a hard constraint running through all of them: they will not invent policy, product behaviour, refunds, timelines, compensation, or an incident all-clear that you have not confirmed. A support reply is a commitment made on behalf of a company, and the fastest way to turn one problem into two is to promise something nobody checked.
When the customer is angry
Reply to an Angry or Frustrated Customer is de-escalation as a technique rather than a temperament. It separates the emotional content from the factual claim, responds to both, and resists the two default failure modes — matching their intensity, or retreating into policy language that reads as a brush-off.
Respond to a Negative Public Review is a different job, because the audience is everyone reading it later rather than the reviewer. The measure of a good public response is what a prospective customer concludes about how you handle problems.
Say No to a Customer Request Without Losing Them gives the actual reason and, where one exists, an alternative. A no with a reason is survivable; a vague no invites another attempt through a different channel, which is more effort for everyone.
Resolving in one contact
Ask a Customer for the Details You Need to Help directly targets the repeat-contact problem. Asking for everything at once, explaining why each item is needed, and making it easy to supply is the difference between one exchange and four.
Explain a Technical Answer to a Non-Technical Customer matters because an explanation the customer cannot act on is not a resolution.
Escalate a Ticket to Another Team With Full Context is the internal version of the same principle. Every escalation that arrives without context creates a round trip, and the customer pays for it in elapsed time.
Follow Up to Confirm an Issue Is Resolved closes the loop and catches the resolutions that did not actually work — which would otherwise return as a new ticket with a more annoyed customer attached.
Triage and Summarize a Support Ticket handles the front of the queue, where mis-routing generates most of the transfers.
Answer it once, then reuse it
Write a Reusable Support Macro for a Common Question produces a macro that still sounds like a person, with the variable parts marked so nobody sends a template with a placeholder in it.
Write a Help-Center Article From a Resolved Issue and Turn Support Tickets Into an FAQ turn resolved work into deflection. Self-service is the lowest-effort channel there is when the article actually answers the question, and among the highest when it does not — so both prompts are written from the customer's phrasing of the problem rather than the internal name for it.
Feeding the rest of the company
Turn Customer Feedback Into Themes for Your Team is the prompt that gives support organisational weight. Support holds the best unfiltered signal about the product in the company, and it is usually trapped in a ticketing system nobody outside the team reads. The prompt separates volume from severity — the loudest theme is not automatically the most important, and a small number of customers hitting something catastrophic outranks a large number mildly inconvenienced. It pairs with product management on the receiving end.
Respond to a Customer Feature Request is written to be honest — acknowledging the underlying need without implying a roadmap commitment that does not exist.
When something is broken for everyone
Write a Customer-Facing Incident or Outage Update has the strictest guardrail in the pack. It states what is known, what is not, what is being done, and when the next update comes — and it will not declare an all-clear or a root cause you have not confirmed. A premature all-clear is the single most damaging thing you can send during an incident.
Operations covers the internal side: Write a Runbook for When Something Breaks and Run a Post-Incident Review Without Blaming Anyone. PR covers the crisis holding statement when it goes beyond your customer base, and customer success covers Recover an Account After You've Let Them Down.
Where this stops
These prompts draft replies from what you tell them and are written not to invent facts, policy, or commitments. Anything involving a legal threat, a data breach, a safety issue, a chargeback dispute, or a regulated product claim stops being a support question at that moment and needs the people who own that risk — breach notification in particular is governed by law with deadlines, and is not a communications judgement call.
Sources
- Matthew Dixon, Karen Freeman and Nicholas Toman, Stop Trying to Delight Your Customers, Harvard Business Review, July–August 2010 — more than 75,000 customer interactions; 96% of customers with high-effort experiences became more disloyal, against 9% with low-effort ones
- Matthew Dixon, Nick Toman and Rick DeLisi, The Effortless Experience, 2013 — the operational framework built from that research