Як зберігати контекст клієнта між сайтом, 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: після згоди користувача сервер отримує підписаний токен з його ідентифікатором і перевіряє підпис, видавця, адресата та строк дії. Номер телефону передається лише за окремої згоди. Для нової інтеграції використовуйте актуальний потік входу, а не застарілий віджет.
• Одноразовий код у вже підтверджений канал. Наприклад, код надходить на e-mail, який клієнт підтвердив раніше, і його треба ввести в іншому каналі.
• Перевірка оператором — для складних випадків, із записом, хто і на якій підставі зв'язав акаунти.

Навчальний приклад: один клієнт, два канали, сторонній збіг імені

Це вигаданий сценарій для пояснення логіки, а не опис реального проєкту.

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. Забороніть автоматичне злиття за ім'ям, схожим номером чи вказаною в повідомленні адресою. Визначте 1–2 способи підтвердження, які ви реально можете підтримувати.
4. Розділіть типи контексту: факти читаються з CRM, історія зберігається з каналом і датою, резюме має посилання на оригінальні повідомлення.
5. Задайте строки зберігання для кожного типу даних і сценарій виправлення відомостей клієнтом.
6. Опишіть процедуру роз'єднання профілів і перевірте її на тестових даних до запуску.
7. Перевірте, що отримує оператор під час передачі, і приберіть з картки все, що не потрібне для розв'язання звернення.

Часті запитання