A short reply, a signposted route, and nothing clever

This is not confined to health services or charities. It happens on retail sites, software products, utilities and local businesses. A chat window is an open text box that appears to be attended, and open text boxes that appear to be attended receive whatever the person on the other end is carrying.

Sometimes it arrives sideways, attached to an ordinary complaint that escalates in tone across a few messages. Sometimes it arrives cold, with no preamble at all. Either way the business did not invite it and is not equipped for it, which is precisely why the response needs to be prepared rather than improvised.

The instinct to treat this as too rare to plan for is understandable and wrong for the same reason as the bereavement case. The design cost is one rule and one short message. The cost of getting it wrong is a business having said something careless to somebody at their worst moment, in writing, under its own name.

The natural impulse is to have the assistant respond warmly and at length. This is the wrong design for three reasons, and none of them are about liability.

First, a language model producing supportive text is producing something that reads like care from an entity incapable of it, and the person on the other end may engage with it as though it were. That is not a neutral outcome. Second, a longer reply invites a longer conversation, which keeps somebody in a text box with a support widget instead of moving them towards a route where actual help exists. Third, anything composed at the time is unpredictable at exactly the moment predictability is most valuable.

The correct target is not a good conversation. It is a short exchange that ends with the person looking at a route that can actually help, as quickly as possible. Everything that lengthens the exchange works against that, including kindness expressed at length.

A brief, plain acknowledgement. Not clinical, not effusive. One sentence that does not pretend the message was about a delivery.

A clear statement of what this is: a support channel for a business, not a service that can help with this. Said without apology or elaboration, because a lengthy apology is the assistant making the moment about itself.

The route, named specifically, appearing in the message itself rather than as a link the person has to decide to click. This is the only part of the reply that matters, and it should be the part hardest to miss.

And then nothing. No follow up question, no offer to continue, no invitation to say more. The message should be complete and should not solicit a reply, because a reply keeps somebody where they should not be kept.

The right route is different in every country, and in some countries different by region, service, and time of day. It changes over time. Naming the wrong one is genuinely harmful, because somebody may act on it and find it does not exist, does not operate at that hour, or does not cover their situation.

So this article will not name any. Your team has to choose it, deliberately, for the countries you actually serve, from a current official or well established source in that country. Then check it before you put it in the message, and check it again on a schedule, because the details do change.

If you serve multiple countries, decide how you handle that before launch. The honest options are to name the route for your primary market and say plainly that it applies to that country, or to point at an established international directory rather than a single number. What you must not do is name one country's route as though it were universal.

Whatever you choose, put the exact wording in the rule as fixed text. This is not a place for the assistant to summarise, retrieve or paraphrase, because a paraphrased phone number is a wrong phone number waiting to happen.

An instruction in a prompt is a preference expressed to a system that weighs preferences. It will usually be followed. Usually is an acceptable standard for tone and an unacceptable one here, because the cases where it fails are not random: they are the unusual, oblique, or long conversations, which is exactly the distribution of the messages that matter.

A rule that matches before retrieval and produces fixed text behaves identically on the thousandth conversation and the strange one. It cannot be argued out of it by a long exchange, and no retrieved passage can pull the reply somewhere else. That predictability is the entire point.

It also means the wording is auditable. A fixed message is a thing you can put in a document, show to a colleague, revise deliberately, and know is what visitors actually see. Nobody can say the same about a sentence a model composed last Tuesday.

Decide in advance whether a person should be notified when this fires, and be honest about what they would do with the notification. In most businesses there is nothing useful to do, and a notification exists only to make somebody feel involved. In some, there is a genuine duty of care route, particularly where staff or students are the likely visitors.

If you do notify, notify one named person rather than a shared channel, and say why in the notice. A conversation like this appearing in a general support channel is a privacy problem and turns somebody's worst evening into a topic of conversation.

And review the transcripts sparingly. There is a legitimate reason to look at them, which is to check the rule fired and the wording behaved, but that is a narrow purpose and does not require the whole team to read the message. Decide who reviews these, keep the group small, and write that decision down alongside the rule.