kakinang INSIGHTS · 2026-10-05
How can a company tell whether messages from different channels belong to one customer?
A customer may ask about a product on the website, message a social account the next day and call later. Bringing context together can prevent repetition, but merging two people by mistake can expose private history. Names, profile pictures and writing style only suggest a possibility. A cross-channel relationship needs evidence reviewed by an authorised person, with its source and an undo path preserved. AI I want to connect website and social enquiries carefully without mixing customer identities. may organise context; a guess is not identity proof.
Preserve each message's original channel
A website chat, social message and phone note may concern the same item but have different sources, account identities and reply routes. Record channel, time, identifier available within that channel, information the customer actually supplied and the staff member involved. Do not discard the source when building a timeline. A salesperson needs to know where a statement was made and which channel can receive a valid reply. Platform permissions and message windows have their own rules; a combined view is not permission to send freely across channels.
Microsoft's customer-data unification guidance says that name alone should not establish a match because different people can share one. It recommends attention to identifier quality and progressively checked rules. This is a general data-governance reference, not a claim that kakinang runs Dynamics' matching algorithm. A small business can ask a simpler first question: does this service task actually require the two conversations to appear as one person? A public question about specifications does not justify gathering more personal data or rushing to unify an identity.
Treat clues as stronger or weaker, rather than as magic keys. An email, phone or order detail actively confirmed in an appropriate process is more reliable than a displayed social name. Even then, a family phone, shared work mailbox or reassigned number can be misleading. To answer a private order question, verify authority in the established business process; do not quote purchase history merely because names look close on a timeline. NIST's digital identity guidance separates identity proofing and authentication concepts, reminding teams to match the strength of checking to the situation.
Make links with human review and preserve an undo route
kakinang's customer timeline can show authorised staff the source and interaction context, with manual identity linking available. Before linking, inspect clues customers voluntarily supplied in each record and ask why a unified view is needed for this service task. Confirm contact information in the original channel or enough details through the existing order process, then allow an authorised role to make the link. Without reliable evidence, leave entries separate. A note saying “possibly related, not confirmed” is safer than a silent merge.
Record when a link was made, who confirmed it, the category of evidence and the service purpose. Do not put full identity numbers or needless sensitive values into notes. If stronger verification is required, perform it in the original business system and retain only the necessary result on the timeline. Distinguish customer statements, staff-confirmed facts and unresolved inferences in human notes. Control who can view a combined history and who can change its relationships.
A wrong link must be detectable and reversible. If somebody says “that is not my order”, stop relying on the merged context, unlink the records and inspect whether a reply or note used another person's information. Ask owners to recheck pending promises and contact routes. Splitting the display alone is not enough if an old summary still carries the wrong history. A shared company mailbox may represent several contacts at one organisation, not one natural person; model the business relationship instead of forcing an individual match.
Practise with a three-channel enquiry
Imagine Ms Lin asking about a workshop through the website on Monday, an Instagram account with the same name asking about dates on Wednesday, and a company mailbox asking about a group package on Thursday. These may belong to the same person, colleagues or unrelated visitors. Answer public course questions within their original channels. If the team needs to continue an individual quotation, ask for a previously supplied contact route or another sufficiently distinctive condition. This is a hypothetical example, not a real customer record.
If the Instagram user says only “I asked before”, ask on what day, through which entry point and about which course, then check a contact email. If evidence remains weak, keep the records apart and do not paste the website visitor's phone number into a social reply. After verification, an authorised person can manually connect the timeline so later staff see the Monday need and Wednesday change. If several employees use the company mailbox, separate the organisation from the actual correspondent so a group request is not tied to one private account.
Each month sample linked and unlinked cases. Can staff trace why a link was made? Were two people with the same name wrongly merged? Did a missing channel source lead to a reply in the wrong place? Did notes retain a different person's details after unlinking? Record false splits and false merges separately; a false merge risks exposing one person's information to another and is usually the more serious error. A shared name or phone number is weak evidence, not automatic permission to merge. Use de-identified cases for training rather than real personal details. When evidence remains insufficient, keep records separate and tell the next colleague why. The goal is correct context when it is needed and protection of unrelated customers. Public questions without an identity need can remain anonymous or separate.
Questions teams ask
Can we merge matching names and ask for confirmation later?
Avoid that order. Two people can share a name, and by the time somebody notices the error staff may already have seen or answered using another person's private record. Keep entries separate, ask suitable verification questions, then let an authorised person connect them.
Does a matching phone number or email prove identity?
Consider how the data was obtained and whether it is current. Shared phones, team inboxes, forms completed by others and recycled numbers can mislead. Use several consistent clues and the service context, and ask the customer when needed. No single field is absolute proof.
How do we repair an incorrect link?
Stop using the combined context, have an authorised person unlink it and review notes, replies and pending work for another person's data. Record why and when it was corrected. Owners of affected commitments may need to verify them again.
Can AI decide customer identity for the team?
Similarity in names, language or questions is not authentication. AI can point out that records may be related and identify what needs checking. An authorised person should make or reverse a cross-channel link. Public chat must not reveal another record's personal information during that process.
Sources and further reading
- Data unification best practices — Microsoft Learn
- Digital Identity Guidelines — NIST