Recognise the moment it changes
Most chats that end up mattering legally do not start that way. They begin as an ordinary
complaint and shift, usually in a single sentence: a mention of a solicitor or lawyer, a threat to
report you to a regulator or ombudsman, a demand for compensation beyond a refund, a reference to
injury or financial loss, or a statement that the customer is recording the conversation or
intends to publish it.
Agents need to recognise that shift in the moment, because everything useful happens in the
next two or three messages. The instinct in that moment is to reassure, explain and take
responsibility — which is exactly the instinct that creates problems, because it produces
statements about cause and liability that nobody has verified.
This is not legal advice, and neither is your agent
To be explicit: this guide describes operational handling, not law. What counts as an
admission, what your obligations are, and how any of it applies where you trade are questions for
a qualified adviser in your jurisdiction. The point of the guidance below is to keep the situation
open until that adviser can look at it.
The same boundary applies inside the chat. A support agent should never characterise fault,
interpret terms and conditions, or speculate about what a court or regulator would say. That is
not caution for its own sake: an agent's off-hand interpretation becomes a written statement by
your company, and it will be read later without any of the surrounding context.
Stop speculating about the cause
The single most damaging habit in these conversations is diagnosing out loud. That
sounds like the bug we had last week and the warehouse has been mislabelling those
are helpful instincts and terrible sentences. They assert a cause the agent has not established,
they imply the problem was known, and they are now written down and timestamped.
Replace diagnosis with description. Record what the customer reports, what you can verify from
your own systems, and nothing else. I can see the order shipped on the fourth and a refund has
not been issued is a fact you can stand behind. I think this happened because…
is a guess that will be quoted back to you.
Acknowledge the person without admitting the claim
Agents often think the only alternative to admitting fault is going cold, so they retreat
into stiff, formal language that reads as contempt and escalates the situation further. There is a
middle position, and it is the one to train: acknowledge the experience and the seriousness of the
concern without accepting the characterisation of what caused it.
I am sorry this has happened and I can see why you are frustrated. I want to make sure this
is looked at properly, so I am passing it to the team who handle this — they will come back
to you. That sentence contains genuine empathy and no admission. Apologising for a person's
experience is not the same as accepting liability for it, and treating those as identical is what
produces the robotic tone that makes complaints worse.
Preserve the record before anything else
Before the conversation is closed, tagged or tidied, make sure the record is intact and
findable later. That means the full chat transcript, any
files exchanged, and the surrounding context — which chats came before, which agents were
involved, what was promised. A summary written from memory a week later is worth very little.
Two practical cautions. Do not edit or delete anything, including embarrassing messages from
your own side; an altered record is far worse than an awkward one. And check the interaction with
your ordinary retention schedule, because a policy that deletes transcripts on a fixed cycle can
quietly destroy the one conversation you needed to keep. Whoever owns retention should be told
that this chat is an exception, in writing, on the day it happens.
Route it, then stop replying
Once a chat has turned legal, the agent's remaining job is a clean handover, not a
resolution. Continuing to negotiate — even generously, even to make the customer feel better
— keeps generating statements on a matter that has left support's authority. Offering
compensation to settle it is particularly risky, because an informal offer can be treated as
significant later.
Say plainly that you are passing it to the right team and give a realistic timescale, then stop.
Silence with an explanation is far better than continued improvisation. Route it to a named owner
rather than a shared inbox: these situations go wrong most often when everyone assumed somebody
else had picked it up.
Write the policy before you need it
None of the above works if the first time an agent thinks about it is mid-conversation.
The policy should fit on one page and answer three questions: which phrases trigger it, exactly
what the agent says next, and who it goes to. Practise it once in training with a realistic
transcript, because reading a policy and using it under pressure are different skills.
Give agents explicit permission to stop. The most common cause of a bad transcript is a
conscientious person trying to fix something they were never authorised to settle, because ending
the conversation felt like failing the customer. Make it clear that routing it correctly is the
successful outcome.
What to measure
These are rare events, so rates matter less than reliability. Audit whether flagged chats
were actually routed to a named owner and how long that took. Review the transcripts themselves
for speculation about cause, which is the failure mode worth catching early. Check that retention
exceptions were recorded rather than assumed. And track whether the same product area or policy
keeps producing them — a cluster is telling you about a defect or a term that reads
unreasonably, and fixing that upstream is worth more than any improvement in handling.