Linking customer conversations safely across channels

Linking conversations across channels requires reliable identity evidence and appropriate access controls. A mistaken merge can reveal another customer's information, so uncertain matches need a review or verification path.

Key takeaways

• A customer may use web chat, WhatsApp and a phone call for one request.
• Keep uncertain records separate until the required evidence is available. Give staff a way to review a possible match and correct an incorrect association.
• These are engineering considerations, not a description of a verified automatic matching algorithm inside ZINQ.
• Linking conversations across channels requires reliable identity evidence and appropriate access controls.
• A mistaken merge can reveal another customer's information, so uncertain matches need a review or verification path.

A customer asks a question on WhatsApp in the morning, fills in a form on your website at lunch, and calls in the afternoon. To most tools, that’s three different people. To your team, it’s three half-conversations they have to mentally stitch together, usually by asking the customer to repeat themselves.

Keeping one person as one person, across every channel, is the job of the contacts primitive. Here’s how we think about it.

Define the identity evidence

A customer may use web chat, WhatsApp and a phone call for one request. Those events do not automatically prove a shared identity. Names can repeat, phone numbers can be shared and contact details can change.

Before associating records, define which evidence is sufficient for the information or action involved. Verification for a public enquiry may differ from verification for an account change.

Design for uncertainty

Keep uncertain records separate until the required evidence is available. Give staff a way to review a possible match and correct an incorrect association. Limit access to the information needed for the task.

Test shared phone numbers, mistyped email addresses and a customer switching devices. Also test how a correction affects the history visible to the next person handling the case.

Distinguish design from implementation

These are engineering considerations, not a description of a verified automatic matching algorithm inside ZINQ. The supported contacts workflow associates profiles and history where configuration allows; confirm the specific behavior for your deployment.

The practical tradeoff is between asking for additional verification and risking an incorrect association. Evaluate that tradeoff against the sensitivity of the data. A continuous history is useful only when the team can trust whose history it is.

The problem isn’t matching, it’s matching safely

It’s easy to merge two records when they share a phone number. The hard part is the grey area: a web-chat visitor with no identifier yet, a call from a number that isn’t saved, a name typed three slightly different ways. Merge too eagerly and you blend two real customers into one, a worse failure than not merging at all, because now the agent says the wrong thing to the wrong person.

So resolution runs on a spectrum of confidence, not a yes/no:

• Strong signals, a verified phone number, an email confirmed on a booking, merge automatically.
• Weak signals, a similar name, an overlapping device, associate the threads without collapsing them, and surface the maybe-match to your team rather than guessing.
• No signal yet, a fresh web-chat session stays its own provisional contact until the customer gives something that ties it to a known record (books, shares a number, logs in).

Why the agent cares

The agent reads the resolved contact before it replies. That’s what lets it say “welcome back” to a returning customer instead of re-asking what they already told you on another channel and what lets a human stepping in see the whole story, not just the last message.

The honest trade-off: we’d rather under-merge and ask than over-merge and be confidently wrong. A split record is a tidy-up. A blended one is a trust problem. We optimise for the second never happening.

Conclusion

A useful multichannel setup gives the team one current customer record while respecting the rules of each channel. Begin with identity matching and handoff context, then add automation only where the business can verify what happened.

Frequently asked questions

How should an omnichannel workflow be measured?

Measure the customer journey and final outcome across channels, then inspect transfers, repeated questions and unresolved cases. Channel-level volume can hide duplicated work.

How should teams link conversations across channels?

Use approved identity evidence and keep uncertainty visible. A matching name or phone number may be insufficient for sensitive actions.

Should every channel use the same message?

Keep service rules and facts consistent, but adapt length, timing and interaction design to each channel’s constraints and customer expectations.