Клиент не должен повторять историю три раза: как память диалога меняет сервис

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

Почему клиенту приходится рассказывать всё заново

Человек обращается в компанию через сайт, затем звонит, а через несколько дней пишет в Telegram или MAX. Для клиента это одна продолжающаяся ситуация. Для сотрудников же переписка, телефонный разговор и карточка заявки могут существовать отдельно. Если новый сотрудник не видит, что уже выяснили коллеги, он задаёт те же вопросы, а клиенту приходится снова описывать проблему.

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

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

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

Какой контекст полезен для ответа

Для большинства обращений достаточно небольшой выжимки, связанной с текущей задачей. Ключевые сведения — последнее обращение, заказ, статус заявки и уже обещанное клиенту действие. Например: «вчера сообщил о недостающей детали; заказ №… ожидает поставки; специалист обещал перезвонить после уточнения; срок ответа — сегодня». Такой контекст помогает сотруднику продолжить работу, не заставляя клиента восстанавливать ход событий.

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

Мы предлагаем начинать с перечня вопросов, на которые команда должна ответить при продолжении разговора:

• О чём клиент обращался в последний раз и чем завершилось обращение?
• Какой заказ, запись или заявка связаны с текущим вопросом?
• Каков актуальный статус и когда он обновлялся?
• Что компания уже пообещала сделать и кто отвечает за следующий шаг?
• Нужно ли передать разговор конкретному сотруднику или подразделению?

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

Память — не полная история клиента

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

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

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

Подход	Что видит сотрудник или ИИ	Преимущество	Ограничение
Вся история без отбора	Много сообщений и сведений, в том числе не связанных с запросом	Не нужно заранее решать, что выбрать	Сложнее быстро найти важное и ограничить доступ к лишним данным
Краткая выжимка обращения	Тема, итог, текущий статус и следующий шаг	Удобно продолжить диалог без повторных вопросов	Выжимку нужно обновлять и проверять на точность
Контекст по правилам доступа	Только нужные сведения для конкретной задачи и роли	Проще контролировать состав и круг пользователей	Требуется настроить источники, права и порядок передачи

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

Какие ограничения нужны для защиты данных

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

Если обрабатываются персональные данные, компании нужно учитывать требования 152-ФЗ и определить свои обязанности как оператора данных. Это включает цель обработки, необходимый состав сведений, основания обработки, порядок доступа и сроки хранения. Мы не подменяем юридическую оценку настройкой программы: до запуска правила обработки стоит согласовать с ответственным за персональные данные или юристом компании.

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

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

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

Как встроить память в обслуживание без лишней сложности

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

1. Опишите сценарий. Укажите, кто принимает обращение, какие шаги выполняются и когда вопрос считается решённым.
2. Составьте короткий перечень данных. Для каждого поля объясните, зачем оно нужно, откуда берётся и какая роль вправе его видеть.
3. Установите правила передачи. Определите, как система связывает обращения, что делает при нехватке данных и в каких случаях передаёт разговор сотруднику.
4. Проверьте ответы на примерах. Используйте типовые и сложные случаи, в том числе устаревший статус, несколько заказов и невозможность подтвердить личность.
5. Запустите ограниченный пилот. Оставьте сотрудникам возможность исправить контекст и сообщить о неточностях, затем оцените показатели и скорректируйте правила.

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

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

Как понять, что память действительно помогает

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

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

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

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

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

Какой порядок действий выбрать руководителю

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

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

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

Когда узкий сценарий работает предсказуемо, можно рассмотреть следующий. Не расширяйте доступ и сроки хранения автоматически вместе с охватом: для каждого нового процесса снова определите цель, состав сведений и ответственных. Если в поддержку добавляются рекламные сообщения, отдельно проверьте применимость требований 38-ФЗ о рекламе и правила получения согласий. Обслуживание по запросу клиента и рекламная рассылка — не одно и то же.

Следующий шаг по теме

Базовые материалы и инструменты KM2B для внедрения ИИ в бизнес.

• Услуги KM2B по внедрению ИИ
• Калькулятор экономики ИИ
• ИИ-агенты для бизнеса: что дают и с чего начать
• Автоматизация бизнес-процессов нейросетями: с чего начать