Общий контекст каналов: одна история без смешивания собеседников

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

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

Разделите транспорт, личность и разговор

Канал отвечает за доставку события. Внешний аккаунт или профиль даёт идентификатор внутри этого канала. Разговор описывает предмет и участников. Эти сущности нельзя превращать в одну строку. Один пользователь может иметь личный и рабочий аккаунт; групповой чат включает нескольких людей; номер телефона может перейти другому владельцу.

Создайте таблицу связей с происхождением и состоянием подтверждения. Авторизованное приложение может дать более сильную связь, чем совпавшее отображаемое имя. Ручное объединение оператором тоже должно оставлять след: кто принял решение, на каком основании и как его отменить.

До подтверждения показывайте диалоги раздельно. Удобство не оправдывает раскрытие чужого заказа или документа.

Определите область переносимого контекста

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

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

Контекст получает версию и время. Старое предпочтение нельзя подавать как текущее без подтверждения, если оно влияет на действие.

Маршрутизируйте до генерации ответа

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

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

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

Моделируемый сценарий

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

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

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

Проверьте разъединение и конфликт

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

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

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

Карта для первого пилота

Нарисуйте три дорожки: события канала, идентичность, бизнес-объект. Стрелкой соединяйте их только там, где есть проверяемое основание. Рядом запишите, какие данные можно показать в каждом ответном канале и кто вправе изменить связь.

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

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

Правила связывания диалогов

Объединять сообщения можно только по устойчивой идентичности, подтверждённой для конкретной организации. Совпадение имени, подписи или номера заказа недостаточно: два человека могут называться одинаково, а общий ящик — принадлежать целой команде. Таблица соответствий должна хранить происхождение связи, дату подтверждения и область, в которой её разрешено использовать. Автоматическое слияние по догадке опаснее временно раздельной истории.

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

Моделируемый сценарий: человек сначала пишет в Telegram, затем обращается через приложение и ссылается на прежний разговор. Агент не склеивает профили по одинаковому имени. Он предлагает предусмотренную проверку, после которой показывает нейтральную сводку и просит подтвердить, что речь идёт о той же задаче. Внутренняя причина эскалации остаётся у операторов. При отказе от проверки оба диалога продолжаются отдельно, без утечки старых сообщений.

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

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