How to preserve customer context across your website, Telegram, and WhatsApp

Shared context across channels should be built around a verified customer profile, not a matching name or a similar phone number. Your system needs to know that a message in your website chat, a Telegram account, and a WhatsApp number or identifier belong to the same person—and it needs a verified basis for that conclusion: a sign-in to an account, official authorization, or confirmation through a channel already on file. Without that basis, do not merge histories, even if doing so seems convenient. A mistaken profile merge is more than a minor inconvenience: an agent or AI assistant could show someone else another person’s orders, address, or debt balance.

After reading this article, you will be able to decide which data should move between channels, how to link accounts, what an agent should see when a conversation is handed over, and what to do when profiles are merged by mistake.

What exactly moves between channels

“Preserve context” sounds like one task, but it actually involves four different data types, each of which needs its own rules.

Verified facts from your CRM or system of record. A contract number, order status, plan, or date of last payment. These data have an owner and a source. The bot should not “remember” them; it should read them from the system whenever they are needed, because yesterday’s order status may already have changed today.

Recent messages. A few turns from the previous conversation help avoid asking the customer to repeat what they said an hour ago. But they are tied to a particular channel and time, and their value fades quickly.

Open tasks. A refund request, a request for a call, or an unfinished checkout. This is where moving context brings the most value: a customer who started on your website and continued in Telegram should not have to explain again that they are waiting for a refund.

A short summary. A condensed account of previous interactions prepared by AI or an agent. It is convenient, but it is derived data: an inaccuracy can get into the summary, and if it cannot be checked against the original messages, the error will carry into every later conversation.

Practical rule: read facts from their source, store history with its channel and date, and make sure every summary can be traced back to the messages it was based on.

One profile: an internal customer_id and separate channel identifiers

Each channel provides its own user identifier, and none of them is, by itself, the identifier of a person in your business.

Telegram assigns each user a numeric identifier. It can contain up to 52 significant bits, so a signed 64-bit integer is suitable for storing it. But the identifier applies only within Telegram; it does not verify that the same person has used your website.

For WhatsApp, also store the identifier actually provided by your integration as a separate channel record. Do not treat a phone number or the name in a message as a verified customer profile. Before implementation, check the current WhatsApp Business Platform contract for your connection method: available fields and identification rules can change.

That leads to a basic data model: you have your own internal customer_id, with separate channel records linked to it. Each record has an identifier in the channel (channel_user_id), the method used to verify the link, the verification date, and a list of data that may be shown in that channel.

This table may look bureaucratic until the first incident. Then it is what lets you determine within minutes why two accounts were treated as one person’s and who made that decision.

Verifying a link: why a name and a similar number are not enough

The most common temptation is to join profiles based on a match: the same name, a similar phone number, or the same email address written in a message. The problem is that anyone can enter any of these details. “Olena Kovalenko” is not a unique name. A number someone types into chat does not prove they own it. They can provide someone else’s email address.

More reliable verification methods include:

• Signing in to the website account, after which the customer selects “connect Telegram” or “connect WhatsApp,” and the system sends a one-time code or link to that channel.
• The channel’s official sign-in flow. Telegram supports sign-in through OpenID Connect. After the user consents, your server receives a signed token containing their identifier and verifies its signature, issuer, audience, and expiry. A phone number is included only with separate consent. For a new integration, use the current sign-in flow rather than the legacy widget.
• A one-time code sent to a channel already verified. For example, a code is sent to an email address the customer previously verified and must be entered in another channel.
• Agent verification for complex cases, with a record of who linked the accounts and on what basis.

A training example: one customer, two channels, and someone else with the same name

This is a fictional scenario to explain the logic, not a description of a real project.

1. A customer writes in the website chat without signing in: “When will my order arrive?” The system does not know who she is. The bot can explain general delivery times, but it does not show the status of any specific order. The conversation is stored as an anonymous session.
2. The customer signs in to her account. The website chat session is now linked to her customer_id. The bot can see the open order and respond to the question.
3. In her account, she selects “Get notifications in Telegram.” The bot opens, and she confirms sign-in through Telegram’s official authorization flow. Only then is a record created: customer_id → telegram → Telegram identifier → method “Telegram authorization” → date. The Telegram bot can now continue the conversation about the same order.
4. The next day, someone writes in WhatsApp, gives the same name, and asks about “my order.” The number is not linked to any profile. The system does not merge this conversation with the customer’s history. The bot asks the person to verify their identity—for example, by signing in through a link or entering a code sent to a contact that was already verified. If it really is the same customer, she can confirm the link through the current process. If not, no one else’s data is disclosed.

The key point in this example is that the genuine customer pays for convenience with one verification step, while a mistaken merge could expose personal data.

Memory and freshness: source, date, and retention period

Context stored forever without labels eventually becomes a risk. A customer changes their address, contract number, or contact person, but the bot confidently uses old information from a summary created eighteen months ago.

For every fact in memory, consider storing:

• source—CRM, customer message, agent finding, or AI summary;
• date—when the fact was obtained;
• retention period—how long this data type is needed for the purpose for which you store it;
• status—verified, reported by the customer but not verified, or disputed.

When facts conflict, the system of record takes precedence over the bot’s memory. If a customer says in chat, “I have a new address,” the bot should not silently overwrite the address in the CRM; it can accept the change through the established process or send it for verification.

If you process data about people covered by the GDPR, its relevant principles apply directly to this memory: data must be limited to what is necessary for the purpose, accurate and kept up to date where needed, and inaccurate data must be corrected or erased without undue delay; data that identifies a person should be kept no longer than necessary. Whether the GDPR applies to your business depends on whose data you process and in what circumstances, so assess that separately with a lawyer. If you process personal data in Ukraine, account for national data-protection law as well. Wanting the bot to “remember everything” does not cancel these requirements.

Customers should also be able to correct information about themselves. One simple option is to give the bot a “that’s incorrect” flow that creates a correction task and flags the disputed fact so it is not used until checked.

Handover to a person: the agent sees what is needed, not everything

Context matters most when the bot hands a conversation over to an employee. Customers do not want to repeat their story. But an agent should not receive more than is needed for the specific request.

A useful handover card includes:

• who the customer is and how the link was verified in the current channel;
• the reason for the request in one or two sentences;
• open tasks relevant to the request;
• what the bot has already told the customer, so the agent does not contradict earlier answers;
• why the handover happened: a customer request, an escalation rule, or the bot’s uncertainty.

By default, the card should not include the full history of every channel over several years, payment details, or documents unrelated to the request. Agents receive access to those by role and, where needed, with access recorded in a log.

One special case is a customer who has not yet been verified in the current channel. The agent then sees only the current conversation and, like the bot, verifies the person first. Otherwise, the safeguards can be bypassed through a human: all it takes is asking an agent to “check my order, I messaged you on Telegram.”

Mistaken merges, consent withdrawal, and deletion

Errors can happen even with a well-designed process: an agent links the wrong account, a customer gives their phone to a relative, or a company number is reassigned to another employee. That is why unlinking profiles should be a standard operation, not a manual database edit.

When a mistaken merge is found:

1. Break the link between the customer_id and the incorrect channel record, while keeping a log of when and by whom it was created.
2. Correct derived data. Summaries, tags, or segments created using someone else’s history need to be recalculated or marked as unreliable.
3. Find out what was disclosed or used. Did another person see someone else’s data? Were messages sent to them? Were decisions made using mixed history? The answers determine next steps, including whether there are grounds to report a breach under applicable law.
4. Recheck access in channels where the link was created using the same method.

The same applies to withdrawal of consent and deletion. If a customer disconnects Telegram, deactivate the channel record, and the Telegram bot should no longer have access to the profile data. If a customer asks for data to be deleted, delete not only the primary profile but also copies: summaries, search indexes, conversation logs, and AI assistant caches—while accounting for records you may have to retain under other requirements.

Also check how data reaches external services: the model provider, chat support platform, or analytics service. If conversation summaries are sent to an outside contractor, the terms of that processing should be described in the agreement.

What to change in your process

Start with a small step you can verify:

1. List your channels and note the identifier each one provides and whether it is stable.
2. Introduce an internal customer_id, if you do not already have one, and store channel identifiers as separate records with the verification date and method.
3. Prohibit automatic merges based on a name, similar number, or address entered in a message. Choose one or two verification methods you can actually support.
4. Separate context types: read facts from the CRM, store history with the channel and date, and link summaries to the original messages.
5. Set retention periods for each data type and a process for customers to correct their information.
6. Document an unlinking process and test it with sample data before launch.
7. Check what an agent receives at handover and remove anything not needed to resolve the request.

Frequently asked questions