Knowing who you're talking to is a safety issue
The moment a chat moves from general questions to account-specific ones — order details, billing, personal data, account changes — you need to know the person is who they claim to be. Skipping verification risks handing one customer's information to another, or letting a bad actor change an account they don't own. Verification isn't bureaucracy; it's protecting the real customer.
Verify with what's safe to share
Good verification confirms identity without collecting the very things attackers want. An order number plus a matching email, a recent detail only the real customer would know — these confirm identity safely. What you should never do is ask a customer to paste a password, a full card number, or a government ID into chat. If the answer to “how do I verify?” involves a secret, you're asking for the wrong thing.
Never collect what chat shouldn't hold
Live chat is not a secure vault, and its transcripts persist. Sensitive credentials and payment details do not belong in it — not because a customer wouldn't offer them, but precisely because they might. If a customer starts typing a password or card number, stop them and route to your secure flow. Drawing that line firmly protects the customer even from their own convenience.
Know where the line is, and hand off past it
Some actions carry too much risk for a chat to complete on its own — a password reset, a change of registered email, anything that could lock the real owner out. Those belong behind your proper authentication flow, not an agent's judgment in a chat window. Being genuinely helpful up to that line, then handing off securely past it, is the mark of a mature support process.
How MyLiveChat fits
MyLiveChat gives you the transcript trail that matters when identity is in question, canned responses to keep verification steps consistent and correct, and a clean way to escalate an account-sensitive request into your secure systems. It handles the conversation while credentials and payment details stay where they belong — out of the chat and inside your authenticated flows.
A worked example of a safe exchange
The safe pattern is to confirm that the person already knows something only the account holder
would know, rather than asking them to hand you anything sensitive. A workable exchange looks
like this: the visitor says they cannot access their order; the agent asks for the order
reference and the postcode it shipped to; the agent confirms both match and proceeds with
non-sensitive help. Nothing secret changed hands, and the agent has reasonable confidence.
Contrast that with the unsafe version, which is easy to slip into when an agent wants to be
helpful: asking for a password, a full card number, a security code, or a scan of an identity
document so the agent can “check it for you”. Once that data is in a transcript it is
stored, backed up, and readable by anyone with access to the history. The correct response to a
visitor who volunteers it anyway is to say plainly that they should not send it, and to ask them
to change it if it was a password.
Write the acceptable identifiers down as a short list and treat it as policy rather than
judgment. Order references, the email on file, a postcode, the last four digits of a reference
number and the approximate date of a transaction are all reasonable. Anything that would let a
person take over the account is not. Agents make good decisions under time pressure only when the
decision was made in advance.
Know what chat cannot do
A public chat widget is not an authentication channel and should never be treated as one. It
sits on a public page, anyone can open it, and the person typing is unverified by definition. The
checks described above raise your confidence; they do not prove identity, and no phrasing makes
them do so. That distinction decides where the line sits.
So the rule is about consequences rather than certainty. Low-consequence help — order
status, explaining a policy, resending a receipt to the address already on file — is
reasonable after a light check. Anything that changes control of the account is not: changing the
registered email or phone number, resetting a password directly, adding a user, altering payout
details, or disclosing information the visitor has not already demonstrated they know. Those
belong in an authenticated flow the visitor completes themselves, such as a password reset sent
to the address on record.
Hand off without making the visitor feel accused. “I can get that changed for you, but
for account security it has to go through the verified link rather than chat — I have sent
it to the address on file, and I will stay here while you open it” keeps the conversation
warm while keeping the boundary firm. Staying present through the handoff is what stops the
policy from reading as a brush-off.
What to measure
The number worth watching is how often agents have to refuse a request in chat and redirect it
to an authenticated flow. A steady low rate is healthy. A rising rate usually means the
self-service path is hard to find, and the fix is on the account page rather than in the chat
team.
Audit a sample of transcripts each month specifically for sensitive data that should never
have been collected. Finding some is normal and is a coaching moment rather than a scandal;
finding the same agent repeatedly means the policy was never made concrete for them. Also track
how many verification attempts fail on the first try — if legitimate customers routinely
cannot answer your questions, the questions are wrong, and you are adding friction for honest
people without adding much safety.