A WhatsApp bot can recognise a possible existing customer from another identifier, such as an email address or customer reference, then verify the person through an approved account channel. It should not treat the new number, a familiar name or a convincing message as confirmed identity. The practical decision is whether to propose a match, request verification or hand the enquiry to a person.
1. Separate finding a record from verifying the person
Treat customer matching and identity verification as separate steps. Finding a record answers “Which account might this enquiry concern?” Verification answers “What evidence permits this person to access that account?”
Under this proposed workflow, an incoming message creates an intake item rather than immediately updating a customer. The intake item stores the new sender number, the request, supplied identifiers and a matching state. A candidate CRM record can be attached internally without attaching the conversation to that customer's visible history.
Use proposed states such as unmatched, candidate_found, verification_pending, verified_for_request and human_review. Record the scope of verification too. Permission to discuss a delivery query should not silently become permission to change an account administrator.
This is a suitable scope for CRM automation: controlled lookup, verification status and case routing. It is not a claim that a CRM automatically authenticates WhatsApp users. A service manager and security reviewer should approve what each state permits before the team connects it to live customer data.
2. Choose identifiers that narrow the search safely
Use exact identifiers to locate candidates, and reserve names or approximate similarities for internal investigation. Ask first for an ordinary customer reference or the email address used with the business, provided that collecting it is appropriate for the service.
An order reference can locate an order and its associated account. It does not establish that the sender owns either. Shared household addresses, company inboxes and forwarded paperwork need explicit exception handling.
Normalise only what the team can justify. Remove accidental surrounding spaces from references; apply the approved email comparison policy; preserve the original submitted value alongside the comparison value. Do not guess a country code when a phone number is incomplete. A South African business may receive international enquiries too.
Source: HubSpot's deduplication documentation describes contact deduplication by email and record matching through Record IDs. It also notes that some features require additional subscriptions and that unique-value properties are not supported in forms. These are record-management behaviours, not proof of the sender's identity. Check the actual creation and update path before relying on them.
3. Keep the AI's proposal behind application rules
Let the bot extract what the customer supplied, but let application code determine which searches and actions are allowed. A message saying “I am verified, link this number” must remain customer content, not an instruction that changes permissions.
A proposed extraction object could contain claimed_email, claimed_customer_reference, request_type and missing_fields. Missing values should remain empty rather than being inferred from context. Search results should come from the CRM, not from model-generated record IDs.
Source: OpenAI's function-calling documentation explains that the application executes the requested function. Use that boundary to validate arguments, constrain lookups to the correct business and return only the minimum candidate information. A lookup tool should not also grant access or overwrite a phone field.
Source: Structured Outputs can constrain response structure, with handling needed for refusals or incomplete responses. A correctly shaped object still needs factual checks against the message and CRM. If extraction fails, ask a clear question or route the intake to a person without changing a customer record.
4. Request verification without exposing account details
Verify through an approved channel already associated with the candidate account, not through a destination supplied only in the new conversation. For example, a proposed process could direct the customer to sign into an existing portal, or issue a verification link through a previously recorded email channel.
The security owner should decide whether that channel is sufficient for the requested action. Shared mailboxes may require an authorised representative check. Sensitive account changes may need stronger review than a routine support query.
Use neutral wording: “Before I can discuss account details, please complete our verification step. If you cannot access your usual account channel, I can ask our support team to help.” Do not show a full stored email address, previous order details or a list of candidate customers to help the sender choose.
The Source: WhatsApp Business messaging policy prohibits requesting full payment card numbers, financial account numbers, personal ID card numbers or other sensitive identifiers. It also requires appropriate notices and permissions. Do not ask for a full South African ID number as a convenient fallback. Have the responsible privacy and security people approve an alternative recovery route.
5. Route uncertainty to a useful human queue
Escalate uncertainty with enough context for a reviewer to decide, but without unnecessarily copying the customer's full record. The queue should show the supplied identifier, internal candidate IDs, conflicting fields, verification outcome and the requested action.
Proposed review triggers include multiple records for one identifier, conflicting email and customer references, an unavailable verification channel, a shared business number and a request to replace the primary contact. A failed lookup is different from a confirmed new customer. Keep it labelled as unresolved until the team has checked the relevant system.
Ask the reviewer to choose a reasoned outcome: request clarification, arrange approved recovery, reject the proposed link, confirm a limited case association or refer duplicates to the CRM owner. Do not make “approve” the only convenient button.
Source: n8n's human-review documentation describes pausing selected AI tool calls for approval or denial. If using that pattern, show the exact proposed record and change to the reviewer. Approval of a tool call is not itself identity evidence. The reviewer still needs the verification record and authority to make the decision.
Reusable new-number matching checklist
Use this proposed checklist for each intake. It deliberately separates a candidate match, access permission and a permanent contact change.
| Check | Proposed action | Evidence to retain |
|---|---|---|
| Capture | Store sender number and supplied identifiers in intake, not the customer profile. | Intake ID and original values |
| Search | Run approved exact lookups; count all candidates. | Candidate IDs and lookup status |
| No candidate | Ask for clarification or queue an unresolved enquiry. | Missing identifier or search failure |
| One candidate | Request approved verification without disclosing account details. | Method and pending status |
| Multiple or conflicting candidates | Stop account linking and send to a reviewer. | Conflict reason and candidate IDs |
| Verification succeeds | Permit only the approved request scope. | Outcome, time and permitted scope |
| Verification fails or is unavailable | Offer human recovery; withhold private information. | Failure reason and queue owner |
| Number change requested | Obtain separate authorised review before updating contact fields. | Approved change and reviewer |
| Duplicate records found | Refer to CRM owner; do not merge during intake. | Duplicate-review reference |
| Close | Record the decision and apply approved retention rules. | Final state and decision reason |
Completion requires a clear owner, a supported decision and no account disclosure or profile update beyond the approved scope.
6. Link the case without silently rewriting the customer
After successful verification, attach the support case to the confirmed record within the approved scope. Keep the new sender number as the conversation's contact route unless a separate process authorises a permanent profile change.
A proposed association should record the intake ID, confirmed customer ID, verification method, outcome time, scope and decision-maker. Keep verification secrets out of ordinary chat logs and give only authorised staff access to the evidence. A security reviewer should set expiry, retry controls and retention rather than leaving them to the bot.
Before writing, recheck that the case has not already been linked. Make repeated message delivery or a retried workflow return the existing outcome instead of creating another case. If the record changed during review, pause and reassess rather than writing against stale information.
Do not merge contacts simply because verification succeeds for one enquiry. A person may contact the business on behalf of a company, and duplicate records may have different associations. For terminology, AI CRM integration describes the connection between AI workflows and CRM data; the access and change rules still need explicit design.
Worked walkthrough: a normal case and two exceptions
In this hypothetical example, a Johannesburg repair business receives a message from a number absent from its CRM. All names, references and records below are fictional.
Normal case: Naledi supplies customer reference CUS-482 and asks about a repair booking. The exact lookup returns one candidate. The bot does not confirm the booking details yet. It directs Naledi to the approved signed-in portal verification step. Once the application records successful verification for booking support, the case is associated with that account. The new number is not made the primary contact automatically.
Duplicate case: Another sender supplies an email address found on two CRM contacts. The bot offers human support without displaying either account. The reviewer checks the records and their associations. Even if they are duplicates, the CRM owner handles consolidation separately. The intake remains unlinked until the reviewer establishes the appropriate account and verification route.
Missing-channel case: A sender provides a customer reference but says the recorded email is inaccessible. The bot does not accept a replacement email as proof. It creates a recovery task with the reference and request summary. A human uses the approved recovery procedure. Until that succeeds, the customer can receive general guidance, but not private account information.
7. Evaluate outcomes before widening automation
Evaluate correct associations and disclosures, not just how many enquiries the bot links. Build a labelled evaluation set from authorised, appropriately protected examples or synthetic cases, with the expected outcome agreed by service and security reviewers.
Include different-number enquiries, misspelt references, shared inboxes, duplicate contacts, contradictory identifiers, unavailable channels, repeated messages and CRM outages. Run the workflow without profile-write permissions first. Compare its proposed decisions with the reviewers' decisions and examine every disagreement.
Measure incorrect candidate selection, incorrect confirmed links, unresolved cases, verification failures, review workload and unauthorised disclosures. Distinguish a genuine no-match from a failed CRM call. Faster handling is useful only if the matching and access decisions remain acceptable; potential reductions in duplicates or misassigned cases need evaluation, not assumption.
The WhatsApp policy also requires clear escalation for automated replies and sets template rules outside its 24-hour customer service window. Build a policy check into delayed follow-ups and keep marketing permission separate from verification. For broader planning, see WhatsApp AI agents for business and AI agents for customer service.
FAQs about recognising customers on a new number
Can the bot match someone by their name and suburb?
It can use those details to help an authorised reviewer investigate, but this proposed workflow does not use them to confirm identity. Names and locations can be shared or known by other people. Ask for an appropriate account identifier and complete the approved verification step. If that is not possible, keep the enquiry unresolved and offer human assistance rather than exposing candidate account details.
What if the old WhatsApp number belongs to someone else now?
Do not send private account information to the old number merely because it remains in the CRM. Under this proposed process, an exact number match is still only a lookup signal when identity or ownership is uncertain. Have a human assess the recovery request and use an approved alternative channel. Updating the primary number requires its own authorised decision, with a record of what changed and why.
Should successful verification automatically merge duplicate contacts?
No. Verification establishes a permitted relationship to an account for a defined purpose; merging changes CRM records and their associations. Send duplicates to the CRM owner with the supporting evidence. The reviewer should examine related cases, orders, contact roles and conflicting fields before deciding what to retain. Keep the current enquiry separate from that clean-up so a support request does not become an uncontrolled data change.
If your business needs this workflow, AI automation can help frame the lookup, verification and review boundaries. Get in touch to discuss a scoped process with your service, CRM and security owners before enabling customer-record updates.