When somebody writes to say a customer has died

The person writing is usually a family member, sometimes an executor, occasionally a friend who has been asked to deal with the accounts. They are working through a list. Your business is one line on that list, somewhere between the phone company and the gas supplier, and they have already had several versions of this conversation today.

What they type is administrative, because the administrative framing is the only way to get through it. Please cancel this subscription. How do I close the account. Can you stop sending these emails. The fact underneath appears in a subordinate clause or in a single sentence at the end, and sometimes not at all until the second message.

This is why the case is so easy to miss in design. Nobody testing an assistant types this message. It does not appear on a list of top intents, it does not show up in keyword research, and it will never be a large share of your volume. It is still the message where the gap between good and bad handling is widest.

The standard flow answers the administrative question. It is genuinely capable of doing so, the material covers cancellation, and the answer would be correct. Delivered to this person, a correct set of cancellation instructions reads as though nobody heard the important sentence.

The standard flow also does several things that are actively harmful in this context. It may ask for account verification, which means asking a grieving relative to produce credentials they do not have. It may offer a retention path, because cancellation flows are frequently built to prevent cancellation. An automated offer of a discount to stay is the worst possible outcome, and it is a completely ordinary thing for a cancellation flow to do.

It may also do nothing wrong at all and still fail, simply by being brisk. A support assistant's default register is efficient and slightly upbeat. That register is correct for a delivery question and inappropriate here, and the mismatch is noticeable even when the content is fine.

Stop, acknowledge, hand over. In that order, in a small number of sentences, with no attempt at the administrative task even though the answer is available.

Stop means the rule fires before retrieval and the knowledge base is not consulted. There is nothing in your documents that improves this reply, and there is quite a lot in them that could damage it. The correct behaviour is a fixed message, written by a person in advance, rather than anything composed at the time.

Hand over means to a named human route, not to a form that sits in a queue. This is the one case where it is worth breaking your usual routing to put the message in front of somebody quickly, because the follow up requires judgement, discretion and probably an exception to a policy. If you have a phone number where a person answers, this is the conversation that should be offered it.

Do not ask questions. Not for an account number, not for proof, not for a date. Every question is a small additional demand on somebody who is already doing paperwork on the worst week of their year, and none of the answers are needed before a person picks it up.

Keep it short. Three sentences is enough and four is usually too many. Length reads as performance here, and performance is the thing to avoid.

Acknowledge simply and directly. A plain sentence of condolence, in ordinary words, without elaboration. Avoid the vocabulary of customer service entirely: no thanking them for getting in touch, no assuring them their enquiry is important, no apologising for the inconvenience. These phrases are ordinary politeness in every other context and jarring in this one.

Then say what will happen, concretely. Somebody from the team will pick this up, and here is when. Say that they will not need to explain it again, because having to repeat it is the specific fear, and it is a promise your team can keep if you write the handover note properly.

Finally, say nothing about the account. Not that it has been paused, not that billing has stopped, not what documents will be required. Every one of those is a commitment the assistant cannot verify and a demand it should not make. The person picking it up can say all of it, once they know the situation.

The assistant's job ends in a few sentences. Everything after that is an operational question, and it is the part most businesses have genuinely not decided. Who handles these. What happens to billing immediately, before anything is verified. What documentation is actually required, and whether the first request for it can wait until the second contact rather than the first.

Decide the billing question in advance, because it is the one that produces the memorable failure. A payment taken from a deceased person's account after the business was told is the kind of thing that gets screenshotted. If your system can stop collection on a flag before any verification, that should be the default, with the tidying up done afterwards.

Write the internal note format too. The person who picks this up should be able to see, in one line, what happened and what has already been said, so the family member does not have to start again. A handover that loses the context recreates the exact harm the careful wording was designed to avoid.

Put the wording in front of two or three people before it goes live and read it out loud. Sentences that look fine on screen frequently sound like a form letter when spoken, and speaking is the closest test available to how it lands.

Then check the rule actually fires. Type the phrasings people really use, including the oblique ones, and including the ones that mention nothing until the last clause. This is a case where testing the obvious phrasing tells you almost nothing, because the obvious phrasing is not how people write it.

Review it once a year and after any change to your cancellation flow. Cancellation flows attract optimisation, and an optimisation that adds a retention step will silently reintroduce the discount offer into this conversation unless somebody remembers the exception exists.