Prepared with AI assistance and reviewed for clarity, relevance and unsupported claims.
Cross channel customer identity matching helps staff connect a new enquiry to the right existing record. It can also expose someone else’s purchase history if a familiar name, shared phone number or similar profile is treated as proof.
For a Moroccan retailer handling enquiries through social messages, WhatsApp and an order system, the safest starting point is to separate three decisions: finding a possible record, confirming a connection and deciding what information may be shared. These are not the same task.
1. Separate finding a candidate from confirming identity
A customer’s name can help staff search, but it should not establish a match. Different people may share a name, one person may use different spellings, and a social account may represent a household or business rather than an individual.
Likewise, an order reference identifies a transaction. It does not automatically prove that whoever supplied it is authorised to view every detail or change the delivery address.
Use explicit states rather than a single matched checkbox:
- Unlinked: no existing record has been selected.
- Candidate found: a record may be relevant, but the link is unconfirmed.
- Connection verified: the agreed confirmation process has been completed for a defined purpose.
- Review required: details conflict or the requested action needs stronger confirmation.
This structure lets staff keep working without turning uncertainty into a permanent customer relationship.
2. Compare references according to what they actually prove
Start with stable internal references where available: an order identifier, a customer account reference or an existing conversation already linked through a verified process. Check the reference against the source system rather than relying on its appearance.
Phone numbers and email addresses are useful supporting details, but they can be shared, changed or entered incorrectly. Normalising spaces or a country prefix may improve searching; it does not verify ownership.
For names written in Arabic and Latin characters, alternate spellings can help find candidates. They should not increase confidence enough to approve a link on their own. An AI assistant may suggest records for review, but resemblance in language is not identity evidence.
Keep the search result narrow. Staff handling an unresolved social enquiry usually need to know that a possible order exists, not see the person’s full purchasing history.
3. Ask for confirmation without revealing the answer
Ask the customer to provide the relevant reference privately. Avoid leading questions such as “Are you the person who ordered the black suitcase for delivery to this address?” That question discloses information before the connection is established.
The confirmation step should match the risk of the action. Answering a general product question needs no customer match. Sharing order-specific information requires confirmation. Changing a destination or discussing sensitive account details needs a stricter approved process.
A practical staff checklist is:
- Identify the action the customer wants.
- Request only the reference needed to locate the relevant record.
- Check it in the system that owns the order.
- Use an established contact route associated with that order when additional confirmation is needed.
- Record the confirmation method and scope before linking or disclosing details.
Do not request passwords or ask customers to send one-time login codes to staff. If the usual route is unavailable, send the case to a designated reviewer rather than improvising a weaker check.
4. Hypothetical example: a social message about a purchase
Imagine a luggage retailer receiving a private social message: “I bought a cabin bag last week. Can you check where my order is?” The profile name resembles an existing customer, but that is only a search clue.
Staff: Please send the order reference from your confirmation message here in this private conversation. Please do not post it in a public comment.
Customer: The reference is BAG-482.
Staff: Thank you. Before sharing order details here, we’ll confirm through the contact route recorded with the order. If you cannot use that route, a colleague will review the next step.
The staff member finds the reference and follows the retailer’s approved confirmation process. Once completed, they link this enquiry to that order, recording the basis for the connection.
They do not automatically attach the social account to every purchase under a similar name. Nor does confirmation of this order justify combining two customer profiles. If the customer says a relative placed the order, the reviewer considers the requested action and appropriate authorisation separately.
For the related distinction between repeated messages and repeated purchases, see recognising duplicate order requests.
5. Make links reversible and exceptions visible
Linking an enquiry to an order is often safer than immediately merging customer records. Preserve the original channel identifier and the enquiry’s own reference so a mistaken link can be removed without losing the conversation.
Record who approved the link, when, how and for which purpose. Do not copy the customer’s entire verification exchange into several tools if a concise restricted note is sufficient.
Flag conflicting details, shared contact numbers, multiple candidate records and requests made on someone else’s behalf. Assign a reviewer and a next action so “unverified” does not become an abandoned queue. The guide to managing a human handoff queue covers that operational handover.
When correcting a wrong link, also check downstream summaries or tasks created from it. Removing one relationship does not necessarily undo information already copied elsewhere.
6. Choose the smallest useful automation scope
Begin with candidate lookup and a staff confirmation task. Keep permanent merges and consequential account changes outside automatic matching until the rules and exceptions are understood.
This adds friction compared with instant matching, but limits the consequences of a false positive. Conversely, asking for confirmation on every general question creates unnecessary work. Match only when the requested service actually needs it.
Define how long confirmation notes remain useful using purpose-based retention rules. Then test shared numbers, misspelled names, incorrect references and inaccessible contact routes before expanding the workflow.
A custom n8n workflow can be scoped around candidate lookup, approval and reversible linking where the connected tools support it. To discuss that process with FlowAgent, share your channels and current verification steps.