Cross-Channel Context

Cross-channel context is the conversation state that travels with a customer when they change channels: who they are, what they have already asked, what the bot or agent already answered, and any data collected along the way.

When cross-channel context exists, a customer can start on your website widget, continue on WhatsApp and finish in your mobile app without repeating themselves. When it does not, each channel switch is a cold start.

This single property is what separates omnichannel from multichannel. Channel count is a marketing number; context persistence is the functional definition.

"Context" is vague unless you enumerate it. In a chatbot deployment it usually means four distinct things:

1. Identity. A stable key linking channel-specific identifiers - a phone number on WhatsApp, a page-scoped ID on Messenger, an anonymous visitor ID on the web - to one person.
2. Transcript. The message history, including the automated portion, so nobody re-treads ground the bot already covered.
3. Collected variables. Answers the customer already gave: order number, plan, location, issue category. Re-asking these is the most visible failure.
4. Journey state. Where the customer is in a flow, whether they were escalated, and what the outcome was.

A platform can share the transcript but not the variables, or the variables but not the escalation state. Partial sharing produces the confusing middle ground where a bot "remembers" some things and not others.

Context cannot follow a customer without something to follow them by. Every channel supplies a different identifier and none of them match by default.

The usual approaches, in increasing order of reliability:

• Volunteered contact detail. Ask for an email or phone at a natural point in the flow and use it as the join key. Simple, and it works across every channel.
• Authenticated account. If the customer logs in - on your site or in your app - the account ID is the strongest key available.
• Deliberate session linking. A one-time code, magic link or QR scan that explicitly binds a new device or channel to an existing session.
• Channel-native identifiers. A verified phone number on WhatsApp can be matched against a CRM record you already hold.

Anonymous web visitors are the hard case: there is nothing to resolve against until the visitor gives you something. This is why a lead-capture step early in a flow does double duty as an identity step.

Cross-channel context breaks in recognisable ways:

• Re-asking known data. The bot requests an order number the customer supplied ten minutes earlier on another channel - the most damaging and most noticeable failure.
• Contradictory answers. Two channels answer the same policy question differently because they were built from separate content.
• Escalation amnesia. A customer escalated to a human on one channel gets pushed back into automation when they return on another.
• Stale context. Context that never expires resurfaces a resolved issue weeks later as if it were still open. Sensible time-to-live matters as much as persistence.
• Over-personalisation. Referencing history in a way that feels surveillant rather than helpful, particularly across channels the customer considers private.

That last point is worth designing for deliberately: acknowledge prior context briefly and factually rather than performing familiarity.

Linking identities across channels is exactly the kind of processing that data-protection regimes scrutinise. Practical guidance:

• Collect the identity key transparently. Explain why you are asking for an email or phone number rather than harvesting it silently.
• Set a retention window. Context should have a defined lifespan tied to the purpose it was collected for.
• Support deletion. A deletion request should clear linked conversation history across every channel, not just the one it was made on.
• Keep sensitive fields out of transcripts. Payment details and similar data should be masked at capture, not scrubbed afterwards.

See human handoff for how context should travel specifically at the bot-to-agent boundary, which is where sensitive information most often leaks into notes.

A workable sequence for teams adding this to an existing deployment:

1. Pick one identity key and instrument every channel to capture it at a natural moment.
2. Consolidate to one flow and one knowledge base so answers cannot diverge between channels.
3. Route all channels into one agent queue so the human side sees the same continuous history.
4. Decide a context lifetime - long enough to span a realistic support journey, short enough not to resurface closed issues.
5. Test the crossing explicitly. Start on channel A, switch to channel B mid-issue, and confirm nothing is re-asked. This is the only test that matters.

On Conferbot, a single build deploys to 13 destinations with a shared flow, knowledge base, agent inbox and analytics, and conversation records carry a channel attribute so cross-channel journeys are visible in reporting rather than split across dashboards.