Как сохранять контекст клиента между сайтом, Telegram и WhatsApp

Общий контекст между каналами строится вокруг подтверждённого профиля клиента, а не совпадения имени или похожего номера телефона. Система должна знать, что сообщение в чате на сайте, аккаунт в Telegram и номер или идентификатор в WhatsApp принадлежат одному человеку, — и знать это на основании проверенной процедуры: входа в личный кабинет, официальной авторизации или подтверждения через уже известный канал. Без такого основания истории не объединяют, даже если это кажется удобным. Ошибочное объединение профилей — не мелкое неудобство: оператор или ИИ-ассистент может показать постороннему человеку чужие заказы, адрес или сумму долга.

После этой статьи вы сможете решить, какие данные переносить между каналами, как связать аккаунты, что видит оператор при передаче разговора и что делать, если профили объединили ошибочно.

Что именно переносится между каналами

«Сохранить контекст» звучит как одна задача, но на деле речь идёт о четырёх разных типах данных, и для каждого нужны свои правила.

Подтверждённые факты из CRM или учётной системы. Номер договора, статус заказа, тариф, дата последней оплаты. У этих данных есть владелец и источник. Бот не должен их «запоминать»: когда они нужны, он должен каждый раз считывать их из системы, потому что вчерашний статус заказа сегодня уже может быть другим.

Последние сообщения. Несколько реплик из предыдущего разговора помогают не переспрашивать клиента, о чём он говорил час назад. Но они привязаны к конкретному каналу и времени, и их ценность быстро снижается.

Открытые задачи. Заявка на возврат, запрос на звонок, незавершённое оформление. Здесь перенос контекста приносит наибольшую пользу: клиент, который начал на сайте и продолжил в Telegram, не должен заново объяснять, что ждёт возврата денег.

Краткое резюме. Сжатое изложение предыдущих обращений, которое готовит ИИ или оператор. Оно удобно, но это производные данные: в резюме может попасть неточность, а если сверить его с исходными сообщениями нельзя, ошибка будет повторяться в каждом следующем разговоре.

Практическое правило: факты считываются из источника, история хранится со ссылкой на канал и дату, а из резюме всегда можно вернуться к сообщениям, на которых оно основано.

Единый профиль: внутренний customer_id и отдельные идентификаторы каналов

Каждый канал предоставляет свой идентификатор пользователя, и ни один из них сам по себе не является идентификатором человека в вашем бизнесе.

Telegram присваивает каждому пользователю числовой идентификатор. Он может содержать до 52 значащих битов, поэтому для хранения подходит знаковое 64-битное целое число. Но этот идентификатор действует только в Telegram и не подтверждает, что тот же человек пользовался вашим сайтом.

Для WhatsApp также сохраняйте идентификатор, который фактически предоставляет ваша интеграция, как отдельную запись канала. Не считайте сам номер телефона или имя в сообщении подтверждённым профилем клиента. Перед реализацией проверьте актуальный контракт WhatsApp Business Platform для вашего способа подключения: набор полей и правила идентификации могут меняться.

Отсюда базовая модель данных: у вас есть собственный внутренний customer_id, к которому привязаны отдельные записи каналов. В каждой записи указаны идентификатор в канале (channel_user_id), способ подтверждения связи, дата подтверждения и перечень данных, которые разрешено показывать в этом канале.

Такая таблица кажется бюрократией, пока не произойдёт первый инцидент. Тогда именно она позволяет за несколько минут выяснить, почему два аккаунта считались аккаунтами одного человека и кто так решил.

Подтверждение связи: почему имени и похожего номера недостаточно

Самый распространённый соблазн — склеивать профили по совпадению: одинаковое имя, похожий номер телефона, тот же адрес электронной почты, указанный в сообщении. Проблема в том, что любые из этих данных может ввести кто угодно. Имя «Олена Коваленко» не уникально. Номер, который человек написал в чате, не доказывает, что он им владеет. Можно указать чужой адрес электронной почты.

Более надёжные способы подтверждения:

• Вход в личный кабинет на сайте, после которого клиент сам нажимает «подключить Telegram» или «подключить WhatsApp», а система передаёт в канал одноразовый код или ссылку.
• Официальная авторизация канала. В Telegram можно подтвердить вход через OpenID Connect: после согласия пользователя сервер получает подписанный токен с его идентификатором и проверяет подпись, издателя, адресата и срок действия. Номер телефона передается только с отдельного согласия. Для новой интеграции используйте актуальный способ входа, а не устаревший виджет.
• Одноразовый код в уже подтверждённый канал. Например, код приходит на электронную почту, которую клиент подтвердил ранее, и его нужно ввести в другом канале.
• Проверка оператором — для сложных случаев, с записью того, кто и на каком основании связал аккаунты.

Учебный пример: один клиент, два канала, совпадение имени с посторонним человеком

Это вымышленный сценарий для объяснения логики, а не описание реального проекта.

1. Клиентка пишет в чат на сайте, не входя в кабинет: «Когда приедет мой заказ?» Система не знает, кто она. Бот может объяснить общие сроки доставки, но не показывает статус какого-либо конкретного заказа. Диалог сохраняется как анонимная сессия.
2. Клиентка входит в личный кабинет. Теперь сессия чата на сайте привязывается к её customer_id. Бот видит открытый заказ и отвечает по существу.
3. В кабинете она нажимает «Получать уведомления в Telegram». Открывается бот, и она подтверждает вход через официальную авторизацию Telegram. Только после этого появляется запись: customer_id → telegram → идентификатор Telegram → способ «авторизация Telegram» → дата. Теперь бот в Telegram может продолжить разговор о том же заказе.
4. На следующий день в WhatsApp пишет человек, который называет то же имя и спрашивает о «моём заказе». Номер не привязан ни к одному профилю. Система не объединяет этот разговор с историей клиентки. Бот предлагает подтвердить личность — например, войти в кабинет по ссылке или ввести код, отправленный на уже подтверждённый контакт. Если это действительно та же клиентка, она сможет подтвердить связь по действующей процедуре. Если нет — чужие данные не будут раскрыты.

Ключевой момент примера: настоящей клиентке удобство обходится в один шаг подтверждения, тогда как ошибочное объединение могло бы привести к утечке персональных данных.

Память и актуальность: источник, дата, срок хранения

Контекст, который хранится вечно и без пометок, со временем становится риском. Клиент сменил адрес, номер договора или контактное лицо, а бот уверенно использует старые данные из резюме полуторагодичной давности.

Для каждого факта в памяти стоит хранить:

• источник — CRM, сообщение клиента, вывод оператора или резюме ИИ;
• дату — когда факт получен;
• срок хранения — сколько этот тип данных нужен для цели, ради которой вы его храните;
• статус — подтверждён, сообщён клиентом без проверки, оспорен.

Когда факты противоречат друг другу, приоритет у учётной системы, а не у памяти бота. Если клиент говорит в чате «у меня уже другой адрес», бот не должен молча переписывать адрес в CRM: он может принять изменение по установленной процедуре или передать его на проверку.

Если вы обрабатываете данные людей, на которых распространяется GDPR, соответствующие принципы напрямую относятся к такой памяти: данные должны быть ограничены тем, что необходимо для цели, точными и при необходимости актуализироваться, а неточные — исправляться или удаляться без неоправданной задержки; хранить их в форме, позволяющей идентифицировать человека, можно не дольше, чем это необходимо. Применимость GDPR к вашему бизнесу зависит от того, чьи данные и при каких обстоятельствах вы обрабатываете, поэтому её следует отдельно оценить с юристом; при работе с персональными данными в Украине учитывайте и национальное законодательство. Желание «чтобы бот всё помнил» этих требований не отменяет.

Клиент также должен иметь возможность исправить сведения о себе. Самый простой вариант — дать боту сценарий «это неверно», который создаёт задачу на исправление и помечает спорный факт, чтобы им не пользовались до проверки.

Передача человеку: оператор видит необходимое, а не всё

Перенос контекста особенно заметен, когда бот передаёт разговор сотруднику. Клиент не хочет повторять историю заново. Но оператор не должен получать больше, чем нужно для конкретного обращения.

Хорошая карточка передачи содержит:

• кто клиент и как подтверждена связь в текущем канале;
• суть обращения в одном-двух предложениях;
• открытые задачи, относящиеся к обращению;
• что бот уже сообщил клиенту, чтобы оператор не противоречил предыдущим ответам;
• причину передачи: запрос клиента, правило эскалации или неуверенность бота.

По умолчанию в карточке не должно быть полной истории всех каналов за несколько лет, платёжных реквизитов и документов, не относящихся к обращению. Оператор получает доступ к ним по ролям и, при необходимости, с записью в журнале.

Отдельный случай — когда клиент ещё не подтверждён в текущем канале. Тогда оператор видит только текущий разговор и, как и бот, сначала подтверждает личность. Иначе всю защитную логику можно обойти через человека: достаточно попросить оператора «посмотреть мой заказ, я же вам писала в Telegram».

Ошибочное объединение, отзыв согласия и удаление

Даже при хорошо продуманной процедуре возможны ошибки: оператор связал не тот аккаунт, клиент передал телефон родственнику, корпоративный номер перешёл другому сотруднику. Поэтому разъединение профилей должно быть штатной операцией, а не ручным редактированием базы.

Что должно происходить при обнаружении ошибочного объединения:

1. Разорвать связь между customer_id и ошибочной записью канала, сохранив в журнале, когда и кем её создали.
2. Исправить производные данные. Резюме и теги или сегменты, сформированные с учётом чужой истории, нужно пересчитать или пометить как недостоверные.
3. Выяснить, что было раскрыто или использовано. Видел ли посторонний чужие данные, отправляли ли ему сообщения, принимались ли решения на основе смешанной истории. От этого зависят следующие шаги, в том числе наличие оснований сообщить о нарушении в соответствии с применимым законодательством.
4. Повторно проверить доступ в каналах, где связь создавалась тем же способом.

То же относится к отзыву согласия и удалению. Если клиент отключает Telegram, запись канала деактивируется, и бот в Telegram больше не должен иметь доступа к данным профиля. Если клиент просит удалить данные, удалять нужно не только основной профиль, но и копии: резюме, поисковые индексы, журналы разговоров, кеши ИИ-ассистента — с учётом того, что отдельные записи вы можете быть обязаны хранить по другим требованиям.

Также проверьте, как данные попадают во внешние сервисы: поставщику модели, платформе чат-поддержки, аналитике. Если резюме разговоров передаются внешнему подрядчику, условия такой обработки должны быть описаны в договоре.

Что сделать в своём процессе

Начните с небольшого, но проверяемого шага:

1. Составьте список каналов и для каждого запишите, какой идентификатор он предоставляет и стабилен ли он.
2. Введите внутренний customer_id, если его ещё нет, и храните идентификаторы каналов отдельными записями с датой и способом подтверждения.
3. Запретите автоматическое объединение по имени, похожему номеру или адресу, указанному в сообщении. Определите один-два способа подтверждения, которые вы действительно можете поддерживать.
4. Разделите типы контекста: факты считываются из CRM, история хранится с указанием канала и даты, резюме содержит ссылку на исходные сообщения.
5. Установите сроки хранения для каждого типа данных и сценарий исправления сведений клиентом.
6. Опишите процедуру разъединения профилей и проверьте её на тестовых данных до запуска.
7. Проверьте, что получает оператор при передаче, и уберите из карточки всё, что не нужно для решения обращения.

Частые вопросы