A public chat widget on a public page accepts input from anyone who loads it. It can confirm that
somebody typed a name and an order number. It cannot confirm that the person typing is the person
those details belong to. That distinction is the whole subject, and most bad outcomes come from
quietly forgetting it under time pressure.
So the honest position is: a public chat widget is not an authentication channel. It is excellent
at answering questions, capturing intent, and routing people to the right place. It is not a
substitute for a login, and it should not be the last line of defence in front of anything that
matters.
Knowledge is not identity
The common workaround is to ask for something only the real customer would know. The trouble is
that the details usually chosen are not secret at all. An order number appears in a confirmation
email that may be forwarded, sitting in a shared inbox, or visible on a printed packing slip. A
billing address is frequently public. A date of birth is not a secret in any meaningful sense. An
email address is the least private of all.
Anything shared with the customer is, by definition, available to whoever else has seen it. So
these details are reasonable as a low-friction sanity check on a low-stakes request, and they are not
adequate as a gate in front of anything sensitive. The mistake is not using them — it is
treating having asked as though it settled the question.
Match the check to the consequence
Rather than one verification ritual applied to everything, sort requests by what goes wrong if the
person is not who they claim.
- No verification needed. Public information — how something works, what your policies are, whether a feature exists. Most chat volume lives here, and adding friction to it helps nobody.
- Light check, low stakes. Confirming a shipping date on an order the person can already identify. If the details are wrong, little is exposed.
- Do not do this in chat. Anything that changes access, moves money, reveals stored personal data, or affects the account itself — password and email changes, refunds to a new destination, address changes, plan or billing changes, disclosing what is stored about someone.
The third category is not a matter of asking more questions. It is a matter of moving the request
to a channel that can actually establish identity: the authenticated account area, a verified email
flow, or whatever your business already uses for exactly this purpose.
Refuse in a way that helps
Agents comply with pressure when the alternative feels like being unhelpful. The fix is to give
them wording that is protective and warm at the same time, so declining does not feel like failing.
“I am not able to change the email on an account from chat — that one has to come
through the account settings, because it is the change that would let someone take an account over.
I can walk you through exactly where it is, and if you are locked out I will point you at the
recovery step that works.”
That explains the reason, keeps the customer moving, and does not imply they are a suspect. The
explanation matters: a rule with a stated purpose is much easier for an agent to hold when someone
pushes, and much easier for a genuine customer to accept.
Make it explicit that no agent will be criticised for declining a sensitive request. Where that is
unclear, urgency wins, and urgency is exactly the lever a social engineer uses.
Do not collect what you cannot protect
Verification attempts create their own risk, because whatever is typed into chat is now in the
transcript. Asking for a card number, a password, or a government identifier to prove identity turns
a stored conversation into a record you now have to safeguard and eventually delete — and
those details should never be in a chat transcript in the first place.
If a customer volunteers something sensitive unprompted, the right move is to say plainly that it
is not needed and not to repeat it back. Repeating it back is what most often duplicates it into the
permanent record. Retention discipline is the backstop here: the less you keep, and the shorter you
keep it, the smaller the consequence of any of this going wrong.
Write it down, then check it holds
The failure mode in practice is not a missing policy but an unevenly applied one, where the answer
depends on which agent is working and how insistent the customer is. Put the boundary in writing as a
short list of what chat never handles, cover it during onboarding, and revisit it when someone gets
close to the line.
Transcripts make this reviewable after the fact, which is the only way to find out whether the
policy is real. Read a sample periodically and look for requests that should have been redirected and
were not. On the console side, keep access to those transcripts limited to the people who need it,
and remove agents promptly when they leave — verification discipline at the widget is worth
little if the stored conversations behind it are broadly readable.