Philippines staffing guide · Published
Write a customer identity check script for outsourced support
Verification works when the script names the risky actions, the minimum evidence, and the branch for every outcome. Protect the record as carefully as the check.
The short answer
Limit verification to the actions that can cause real harm. Ask for the smallest proof of control, write a branch for every outcome, and store only the record a reviewer needs. Review real cases monthly so the script stays clear under pressure.
Decide which requests need verification
Not every support request needs the same identity check. A password reset, a bank detail change, and a request to close an account carry more risk than a question about store hours. Start by listing the actions that can expose an account, move money, or reveal personal data.
The list becomes the trigger for a verification step, and everything else can follow the normal path. Keep the list short enough that the coordinator can apply it without a lookup.
Write the list with the support team and the security owner in the same room. The support team knows which requests arrive often, while the security owner knows which ones cause lasting harm. Record the reason beside each action so the rule survives staff changes.
Review the list when a new tool or payment method goes live. A trigger without a stated reason is easy to drop during a busy week.
Collect the minimum evidence
Ask for the smallest piece of evidence that proves the person controls the account. That may be a reply from the email address on file, a one-time code, or an answer to a detail that is not public. Do not collect a full identity document when a simpler check will do.
Every extra field creates another copy of sensitive data that must be protected. The best verification step is the one that resolves the risk without becoming a new risk.
Never accept a screenshot as proof of control when the screenshot can be edited. Use a channel the business controls, such as a code sent to the registered address or a callback to the number already on file. If the customer has lost access to those channels, move the request to a separate recovery path.
The standard path should not be stretched to cover a case it was not designed for. A separate path can carry the extra checks and the extra review.
Write the script in plain language
The script should tell the coordinator what to ask, in what order, and what to do with each answer. Keep the wording neutral so the customer does not feel accused. Explain why the check is happening and how long it will take.
A calm explanation reduces pushback and makes customers more willing to complete the step. Read the script aloud before publishing it to catch phrases that sound sharp.
Include a branch for each likely outcome: match, partial match, no match, and customer refusal. Write the exact next action for each branch, including the hold message and the handback trigger. Do not let the coordinator improvise a workaround during a live chat.
Improvisation is where verification quietly turns into a guess. The branch should name the person who takes over when the script runs out.
Handle failed and partial matches
A failed check is not proof of fraud, and a passed check is not proof of identity. Treat the result as one signal and follow the written branch. For a partial match, ask one additional question from the approved list rather than repeating the same step louder.
If the answers still do not fit, hand the case to the security owner with the evidence collected so far. Explain the delay to the customer instead of leaving the conversation open.
Record the outcome without recording unnecessary personal data. Store the check type, the time, the result, and the owner who reviewed it. Mask any identifier that is not needed for the decision.
The record should let a reviewer reconstruct the decision without turning the support tool into a second identity database. Delete or archive the record on the schedule the privacy owner sets.
Protect the verification record
Restrict access to verification records to the people who need them for a decision. A support queue does not need a searchable archive of every customer's answers. Set a retention period with the privacy owner and delete the data when it expires.
Review who can export the records, because an export is often the easiest path for a leak. Check the access list after every team change, not only during the annual review.
Train the team on what not to paste into chat. A common failure is a coordinator sharing a customer's answer in a channel with a wider audience than the case. Use the case record for evidence and keep chat for coordination.
When a mistake happens, treat it as a process gap and fix the channel permissions. Do not rely on a reminder when a technical control would prevent the exposure.
Review the script after real cases
Pull ten verification cases each month and read the full exchange. Look for skipped steps, repeated questions, and customers who dropped out before completing the check. Ask the coordinator which question caused the most confusion.
The answer often reveals wording that sounds clear to the team but not to a worried customer. Change the wording and test it on the next ten cases.
Update the script when a new product, payment path, or recovery option changes the risk. Keep a version date and a short note explaining the change. Share the update with the security owner and the provider supervisor.
A script that never changes is usually a script that nobody is reading with care. A script that changes too often needs a clearer underlying rule.
Questions to copy for the sales call
- "Which customer actions require a verification step, and why?"
- "What is the smallest proof of account control we accept?"
- "What does the coordinator say when a customer refuses the check?"
- "Who reviews a failed match, and how quickly must they respond?"
Sources
- FTC: Protecting Personal Information: Small-business guidance on limiting access to personal information and protecting it.
- NIST Privacy Framework: A voluntary framework for managing privacy risk across data collection and use.
- CISA: Cybersecurity Best Practices: Practical guidance on authentication and protecting accounts and data.
Common questions
Is a security question enough to verify a customer?
Only if the answer is not public and the question is not easy to guess from social media. Prefer a one-time code or a controlled callback for high-risk actions.
What should the coordinator do when a customer becomes angry?
Follow the same branch and offer the recovery path. Do not skip verification to calm the customer; escalate to the security owner if the conversation cannot continue.
How long should verification records be kept?
Set the period with the privacy owner and the legal requirements that apply to your business. Keep the record only as long as it supports a decision or an investigation.