Customer identity verification in support is not about collecting documents. It answers one question: may the person in the chat see the delivery address, the products or the billing details? Someone may know the order number from a parcel label or a forwarded email. That is enough to find the case, not to reveal what is inside it.
This guide shows how to split information into levels, how to confirm a person through the channel recorded with the order and when to escalate. A customer pasting card details into the chat is covered in the guide on sensitive data in chat. Here the question is who you may answer.
An order number points to a case, not a person
Separate two tasks: finding the order and checking whether the person asking is connected to it. An order number, surname or town helps with the first. The second needs something a stranger lacks: a signed-in account, the email stored with the order or the checkout phone number. A sender name in an email or messaging app can be set to anything, so it proves nothing alone.
An example from a fictional tea shop: someone writes, "I'm Anna's husband, tell me where the parcel went and what she ordered," and quotes a valid order number. A helpful agent replies with full details. Yet nothing confirmed that the person is her husband, or that Anna agrees to her address being shared. Politeness does not replace an authorisation check.
The OWASP Authorization Cheat Sheet recommends denying by default and checking permission for the specific object on every request, rather than trusting hard-to-guess identifiers. It is written for applications, not support teams; we borrow only the idea that knowing a number does not grant access.
Split information into levels
Not every answer needs the same confirmation. General delivery rules are public, so anyone can have them. The details of one order reveal personal data, and a change of address or recipient can send a parcel to someone else. The table is an example for a small online shop, not a standard; adapt it to your data and risk.
Scroll the table sideways to see all columns.
| Type of request | Example | Example confirmation |
|---|---|---|
| General information | How long international shipping takes | None, answer from the knowledge base |
| Status without personal data | Has the order been shipped | Order number and a reply with no address or products |
| Order details | Delivery address, products, amount, billing details | Signed-in account or a reply to the email stored with the order |
| Order change | New address, different recipient, new email | Confirmation from a known channel and a decision by an authorised person |
The second row takes discipline. "Your parcel left yesterday" reveals only the status. "Your parcel left yesterday for Lime Street in Leeds" is an address. If status questions are frequent, reduce them at the source, as the guide on where-is-my-order questions describes.
Confirm the person through the channel on the order
The strongest confirmation is one that already exists. A signed-in customer was authenticated at login, and the checkout email is a channel the order owner controls. When the conversation happens elsewhere, move its sensitive part to that channel instead of running security questions in the chat.
- Name the request.Is it about status, details or a change? That decides whether you need confirmation at all.
- Check the current channel.A customer who is signed in, or who replies in a thread you started to the order email, can continue. An address first given in this chat does not count.
- Move the reply.Email the address on the order and ask for a reply. Never send details to a new address the person supplies.
- Keep data out of your questions.Instead of "Is it 5 Lime Street?", ask the customer to state the detail. A question containing the answer reveals it.
- Record the outcome.Note which channel confirmed the person and when, without copying the address or billing details.
Send the confirmation request in one message that explains the purpose and what you do not need. Three unexplained questions in a row feel like an interrogation. The guide on requesting missing support details shows how to combine them into one clear request.
What not to ask customers for
An ID scan looks safe, but in an online shop it usually settles nothing. You do not know what this person's real document looks like, and anyone could have typed the name on the order. Once you accept it, you hold data that must be protected and deleted. Never ask for an account password, a full card number or a text-message code from a bank or another service either.
EDPB Guidelines 01/2022 on the right of access (version 2.0, adopted on 28 March 2023) call it disproportionate to demand an ID copy from a person who is already authenticated, for example signed in to an account. They treat an ID copy in the authentication process as generally inappropriate unless it is strictly necessary and in line with national law. EDPB Guidelines 01/2022. They cover GDPR access requests, not every parcel question.
The same proportionality works for everyday order questions: collect only what strengthens the link between person and order. This article is not legal advice. If rules in your sector require a document, agree a secure channel for it with a lawyer. If a customer sends a scan anyway, follow the guide on sensitive data pasted into chat.
Requests on someone's behalf and time pressure
Some people genuinely act for the customer: a family member, an assistant, a purchasing team. You need not turn them away, but confirmation should come from the order owner, ideally through a known channel. Until then, share the status without personal data. Leave a change of address or recipient to the person entitled to decide, and tell them what was checked.
Watch for pressure signals: an urgent deadline, alleged approval from "the boss", a request to send data to a new email, or contact details changed just before a question about the order. Together they justify escalating to a named person. An agent allowed to say "we will check and get back to you" yields to pressure less often.
"Happy to help. To protect order data, we only share details with the email used at checkout or after you sign in. We have sent you a message there; reply to it and we will finish this. We do not need an ID scan or your password." Calm, and without implying the person is lying.
Write the procedure down before the exception happens
meetlead.identify() can attribute a profile to a stable account identifier without an HMAC signature. An accepted result confirms CRM attribution, not permission to read order details or earlier conversations. The team still checks permission for the specific case under its own procedure.
A verification note says what was checked, not the protected data. "Confirmed by a reply from the order email, 14:20" is enough. A template for such entries is in the guide on internal support notes. A public Help Center article can tell customers in advance what you will ask and what you will never request. The same article helps when customers receive scam texts using your shop’s name and ask whether the message came from you.
- Every type of request has an assigned data level.
- The team knows the accepted confirmation channels.
- Details are never sent to an address first given in the chat.
- The reply template is saved and does not accuse the customer.
- It is clear who decides on a change of address or recipient.
- The note describes how the person was confirmed, without copying data.
If you use an AI assistant, do not hand it the decision to reveal a specific order's details. Define its access separately, following the guide on AI agent permissions.
Questions about customer verification
Are an order number and a surname enough to share the delivery address? In most shops, no. Both often appear on the parcel, in a forwarded message or a screenshot. They let you find the order and share a status without personal data. Share details after sign-in or via the email stored with the order.
What if the customer has lost access to the order email? Do not change the address on a chat request. Pass the case to whoever decides on exceptions, and note what the customer can confirm and why the existing channel is unavailable. Until then, share only the status. You do not lock the customer out, and you do not redirect a parcel or data to a stranger.
