We keep a list of what we will not automate, and it gets longer

Refunds over a threshold, anything involving grief, and the first message from an angry customer. The list is the product.

Dark pleated fabric in vertical folds, a band of fine ribbing catching the light across the middle

Every conversation about automation eventually turns into a list of what the agent can do. Ours is shorter, more useful and considerably more revealing the other way round: the list of what it will never be allowed to do, and why.

It started as four lines on a whiteboard. It is now the longest document we maintain, and it grows most months.

What is on it

Refunds above a threshold the customer sets themselves. Anything that mentions bereavement, illness or hardship. The first message from someone who is clearly angry. Anything touching a legal or regulatory complaint. Account closure. Disputes where money has already moved. Requests that arrive from a lawyer, a regulator or a journalist.

None of these are technically out of reach. Several of them are easier than the questions the agent answers a thousand times a day. They are on the list because being wrong in those places is expensive in a way that an apology does not repair.

The rule we use

If getting it wrong would cost trust that a corrected reply cannot buy back, it does not get automated. Speed is never the argument for crossing that line, and neither is volume. The only thing that moves an item off the list is evidence that the failure mode is recoverable.

Why the list keeps growing

Because we keep finding cases, and because the cases are never the ones anyone predicted in a planning meeting.

A customer writing about a delivery that was meant to arrive before a funeral. A cancellation that turned out to be a complaint about a member of staff. An order change from someone who mentioned, in passing and in the third paragraph, that they were in hospital. Each of those got added afterwards, which is the uncomfortable part: the list is written in retrospect, by the conversations that went wrong.

We have stopped treating that as a failure of foresight. A support queue is a sample of everything happening in your customers’ lives, and no workshop is going to enumerate that in advance. What you can do is make the additions cheap, and make them stick.

How something gets added

Deliberately unglamorously. Anyone on the team can propose an entry with a single conversation attached. It goes on within the day, provisionally, and it is reviewed a month later with whatever volume has accumulated behind it.

Somebody flags a conversation that the agent should not have taken. No committee, no threshold.

The category goes on the list the same day, wide rather than precise. Narrow it later.

A month on, look at how much volume it caught and what else it swept up with it.

Keep, narrow, or in rare cases remove — and write down which conversation made the decision.

The last step is the one that matters. A restriction without the case that caused it becomes folklore within a quarter, and folklore is impossible to argue with or revise.

What it costs

Less than teams expect. Across the inboxes we run, the exclusions account for a low single-digit percentage of volume — the topics are serious, not frequent. The cost is not in the messages themselves; it is in the routing, because a restriction is only as good as the handover behind it.

And the benefit is not really about those conversations either. It is about the other ninety-odd percent. A team that knows what the agent will refuse to touch will let it touch everything else. Without the list, every new category becomes an argument, and the safe answer to an argument is always to do nothing.

The three things that came off it

The list is not a ratchet, and it would be dishonest to imply it only grows. Three entries have come off, and all three came off for the same reason: the failure turned out to be visible and reversible, which is a different category of risk from the one we were protecting against.

Password and access problems were the first. They felt sensitive and they are high volume, but a wrong answer produces an immediate, obvious complaint rather than a slow loss of trust — the customer is still standing at the door, and they tell you. Delivery address changes before dispatch were the second, once the carrier integrations made the cut-off explicit rather than a matter of judgement.

The third was returns eligibility, and that one took a year. It came off only after the policy itself was rewritten to be decidable — dates and conditions rather than “at our discretion”. That is the pattern worth noticing: the item did not become safe because the agent improved. It became safe because somebody finally wrote the policy down properly.

Which is the argument for keeping the list in the first place. It is the only artefact we have that reliably turns “the agent cannot handle this” into a specific, answerable question about what your own documentation does not say.

Writing your own

If you are starting one, do not begin with policy. Begin with the last twenty conversations your team escalated by instinct, and ask what they had in common. In our experience it is almost never the topic. It is the presence of something irreversible: money that has moved, a deadline that has passed, a relationship that is already strained.

Then write the list as categories a person can apply in three seconds, not as rules a system can evaluate perfectly. It will be imprecise. Imprecise and used beats exact and ignored, and you will narrow it with real cases soon enough.

A support agent that will not say no is not a product. It is a liability with a good tone of voice, and the list is how you tell the difference.