Philippines staffing guide · 10 min read · Published November 10, 2026

Write a Customer Identity Verification Script for Offshore Support

Decide which actions need verification, use evidence-based steps, and handle failed checks without exposing account data or tipping off a bad actor.

On this page

The short answer

A customer identity verification script tells an offshore support agent when to verify, what evidence to request, and what to do when the check fails. Tie the steps to the risk of the action rather than to every conversation, and use the same process for every customer in the same situation. The script should protect account data, avoid revealing whether a guess was correct, and route high-risk cases to a named owner. Use offshore staffing services and the research library to connect the script to the role's access boundary. Review failed checks and false rejections so the process stays usable.

Require verification for account changes, payments, and data disclosure.
Use evidence-based steps tied to the risk of the requested action.
Never confirm or deny account details during a failed check.
Review false rejections and social engineering attempts every month.

Decide which actions require verification

Not every question needs a full identity check, but every consequential action does. List the actions that change an account, move money, disclose personal data, add a user, change a contact method, or close an account. Give each action a verification level, from a standard check to a step-up review with a second agent. A password reset may need a different check from a bank detail change. Write the list where agents can see it during the conversation rather than in a policy PDF. Review the list when a new product or payment method launches.

Write the script around the evidence, not the answers

Knowledge-based questions such as date of birth or last order are easy to find and easy to guess. Prefer evidence that the legitimate customer can produce and a bad actor is less likely to have, such as a one-time code sent to the registered contact, a recent transaction detail, or a document that matches the account record. The script should say what evidence is acceptable, how to compare it, and what to do when the customer cannot provide it. Do not ask for a full password or a complete card number. Record the evidence type and the result, not the secret itself. The agent should verify the record, not the customer's confidence.

Set step-up options for each channel

Phone, chat, email, and social media have different risks and different evidence options. Write a step-up path for each channel, such as a callback to the registered number, a secure link, an in-app confirmation, or an in-person visit for the highest-risk change. State which options the agent may offer and which require a supervisor. If the customer cannot use any option, the script should explain the alternative process rather than improvising a workaround. Keep the options current when the organization changes its phone system or portal. A channel without a step-up path will either block legitimate customers or accept weak evidence.

Handle failed verification without exposing data

A failed check is the moment when a script is most likely to leak information. The agent should not confirm whether an email, phone number, order, or account exists. Use a neutral response that explains the next step without validating the guess. Do not ask the customer to try another answer until one works, because that turns verification into a guessing game. Record the failed attempt and the evidence type, then route the case to the review path. If the customer becomes abusive, follow the standard de-escalation and safety process. The same neutral response should apply whether the customer is legitimate or not.

Record the verification outcome

Every consequential action should have a verification record with the action, the evidence type, the result, the agent, the time, and the approval if one was required. Do not store the one-time code, the full document number, or the password in the ticket. Link to the system record that holds the evidence where possible. If a supervisor overrides a failed check, record the reason and the evidence they reviewed. This record lets a later reviewer reconstruct the decision and shows whether the script is being followed. It also gives the team a way to measure false rejections without exposing customer data.

A caller may sound internal, urgent, or authoritative, and that is not evidence of identity. Train agents to recognize pressure to skip a step, a request to read back a code, a claim that a manager already approved the change, or a story that requires immediate access. The script should require the agent to end the call and use the published verification path when any of those signals appear. Do not let a familiar voice or a previous conversation replace the current check. Record the pattern and share it with the team without including unnecessary personal detail. Social engineering changes quickly, so the examples need regular refresh.

Review exceptions and false rejections

A verification process that blocks too many legitimate customers creates its own cost. Sample failed checks and overrides each month and ask whether the evidence was genuinely insufficient or the script was too rigid. Look for customers who failed because they had a new phone, a changed address, or a language barrier. Compare the rejection rate by channel, agent, and customer group. At the same time, review any override that bypassed a required step. Fix the script, the evidence options, or the training rather than telling agents to use better judgment. The aim is a consistent decision that protects the account and the customer.

Update the script when products change

A new subscription, payment provider, family account, or business portal can change who is allowed to act and what evidence is available. Review the script whenever a product, channel, or access model changes. Test the new flow with a normal customer, a customer who lost access to the registered contact, and a case that should be escalated. Confirm that the agent can complete the step without exposing data or promising an outcome. Update the examples and the escalation contacts at the same time. Keep a version date so the team knows which script is current.

Sources and further reading

NIST Digital Identity Guidelines, SP 800-63Identity assurance guidance used to frame verification levels.
CISA, Cyber EssentialsPublic guidance used to frame account protection and social engineering awareness.
Federal Trade Commission, Identity theftPublic guidance used to frame customer data protection.
NIST Privacy FrameworkPrivacy framework used to limit data collection during verification.

Questions managers ask

Should the agent ask for the customer's password?

No. A support agent should never ask for or accept a password. Use a one-time code, a registered contact, or another approved evidence path.

What if the customer cannot pass verification?

Follow the documented alternative path, such as a callback, secure link, or in-person check. Do not invent a workaround or disclose account details to move the conversation along.

A practical decision framework

Define the task, evidence, authority boundary, reviewer, and stop condition before assigning live work. Test a normal case and an exception, then expand access or volume only after the evidence is consistently reviewable.

Compare offshore staffing services, review the research library, or request a role plan grounded in your systems and approval boundaries.