ИИ-менеджер в мессенджерах: единый процесс обращений

Открыть схему крупнее ↗

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

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

Опишите единицу работы первой линии

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

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

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

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

Распределяйте обращения по задаче клиента

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

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

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

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

Сохраняйте контекст без опасного объединения людей

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

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

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

Если клиент переходит в другой канал, объясните, какая информация будет доступна там. Не обещайте автоматический перенос истории, пока он не реализован. Состав полей и правила повторов подробнее разобраны в материале о CRM и контексте клиента.

Для сотрудника полезны краткое резюме и доступ к исходным репликам в пределах его прав. Резюме ускоряет работу, а исходная переписка позволяет проверить детали и избежать домыслов.

Сделайте передачу явным изменением ответственности

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

В документации Copilot Studio описана передача истории и переменных разговора через подключённую систему обслуживания. Это пример реализуемой архитектуры; для конкретного проекта требуется своё согласованное подключение. См. руководство Microsoft по передаче человеку.

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

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

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

Проверьте общий процесс на пересечении каналов

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

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

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

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

Чек-лист единой первой линии

Перед расширением числа каналов убедитесь:

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

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

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