Want help applying this guide?Ask the DripTell team
A customer asks in chat to replace the email address on an account. They know the name, order number, and postcode. That may help an agent find the record. It does not prove that the person is allowed to change it.
The safe answer is not to collect more secrets in the same chat. Start with the requested action, judge the harm of a wrong approval, and use a verification path your business has approved. Do not turn the transcript into a store of passwords, one time codes, identity documents, or recovery answers.
Begin with the requested action
Identity checks should protect an action, not satisfy a vague rule that every customer must answer the same questions. A delivery status request, a contact detail change, an account recovery, and a payout instruction do not create the same harm if the requester is an impostor.
- 1Name the actionIdentify exactly what the customer wants the team to reveal, change, or release.
- 2Assess the harmJudge the consequence of approving the action for the wrong person.
- 3Choose the routeUse the verification or recovery path already approved for that risk.
- 4Keep proof separateDo not ask the customer to paste passwords, codes, or documents into chat.
- 5Record the outcomeStore the result, owner, and next action rather than raw secret evidence.
Write down which actions need no account access, which need an authenticated customer, and which require a stronger recovery or approval path. That policy should be visible in the team inbox, not left to an agent's memory. The agent can then explain the next step without improvising a personal question.
NIST's current Digital Identity Guidelines explain formal processes and requirements for identity proofing, authentication, and federation, including security, privacy, and customer experience. They are not a script every support team should copy. The useful operating lesson is to design the path before a pressured conversation begins.
Match the check to possible harm
Ask one practical question first. What becomes possible if this request is approved for the wrong person? The answer sets the strength of the check and who may approve an exception.
| Requested action | Possible harm if wrong | Safer verification response | What the transcript should retain |
|---|---|---|---|
| Explain a public return policy | Little or no account harm | No identity proof is normally needed | The question and answer |
| Reveal order or account details | Private information reaches another person | Use an existing authenticated account or approved factor | Verification outcome and time |
| Change an email address or recovery factor | Future access may be redirected | Use the documented recovery path and stronger review | Result, reviewer, and next action |
| Release money, access, or a valuable item | Direct loss or physical access | Require the approved high risk control and any second approval | Decision and authorization reference |
Do not add extra questions because a customer sounds nervous, foreign, angry, or unusually confident. The requested action and evidence should drive the decision. Consistent rules reduce both fraud risk and unfair treatment.
Move proof out of open chat
A public chat window proves only that someone can type into it. Even a familiar WhatsApp number can be reassigned, shared, or accessed from a compromised device. Conversation history helps with context, but history is not authentication.
For sensitive work, move the person to a trusted route your organization controls. That may be a signed-in account, an approved confirmation link, a verified callback, or a formal recovery flow. The exact factor depends on your system and risk policy. The important boundary is that an agent should not ask the customer to paste a password, a one time code, a full payment number, or a copy of an identity document into an ordinary transcript.
This boundary belongs in the security model and in the channel playbook. A WhatsApp support workflow should say what the channel can do, what it cannot prove, and how a sensitive request moves elsewhere without abandoning the customer.
Record the result not the secret
Support records still need an audit trail. The useful record is usually compact: the requested action, the approved verification path, whether it passed, who handled an exception, and what happened next. Raw evidence often adds risk without helping the next agent.
NIST SP 800-63A-4 defines identity proofing as a process in which evidence supports an identity assertion at a useful assurance level. A support team should keep the same boundary clear. Finding an account is not the same as authenticating the requester, and neither requires storing raw proof in the transcript. Keep only the outcome the policy needs.
Keep the verified outcome beside the customer record in the CRM when appropriate. Restrict who can see sensitive status and audit information. Set retention rules. Do not reward agents for collecting more evidence than policy requires.
Give an honest failure path
A legitimate customer will sometimes lose the old phone, email address, authenticator, or accessibility route. The answer cannot be to keep asking easier questions until one works. That turns persistence into proof.
Define a recovery path with a named owner, allowed evidence, waiting period where needed, and clear customer updates. High consequence exceptions may need a second reviewer. If the organization cannot verify the request safely, the agent should be able to stop the action without closing the conversation as solved.
Good support operations make that refusal useful. Tell the customer what cannot be done yet, what approved option remains, who owns the next step, and when they will hear back. Do not reveal which answer was wrong or expose stored account details while explaining the failure.
Build a workflow agents can follow
Start with ten common sensitive requests. For each one, name the harm, accepted route, exception owner, forbidden transcript data, audit fields, and customer wording. Test the path with new agents and with people who cannot use the default method.
Use automation to route and remind, not to decide that a person is genuine from weak clues. A rule can send an account change to the right queue, pause the action, and assign a reviewer. It should not convert a matching name or a familiar phone number into verified identity.
Review a sample of passed, failed, and abandoned checks. Look for agents improvising questions, customers repeating data, exceptions with no owner, or transcripts holding secrets. The best identity check is not the longest. It is the smallest approved check that protects the requested action and leaves a clear next step.
Frequently Asked Questions
Is an order number enough to verify a customer
Usually not for a sensitive action. An order number can help locate a record, but it may appear in email, packaging, or shared documents. Use the verification path approved for the action.
Should an agent ask for a one time code in chat
No. The customer should enter a one time code only in the approved authentication flow. Asking them to paste it into chat trains unsafe behavior and places a live secret in the transcript.
Does a familiar phone number prove identity
No. A known number is useful context, but phones and accounts can be shared, reassigned, or compromised. Match the check to the consequence of the requested action.
What should happen when verification fails
Stop the sensitive action, keep ownership of the conversation, and offer the documented recovery or exception route. Record the outcome and next step without revealing the failed answer or storing unnecessary evidence.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy