Заявки из мессенджеров и звонков в CRM: где помогает ИИ и где нужен менеджер

Нарисуйте путь одной заявки до первой реакции

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

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

Что агент может сделать до менеджера

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

Пример входа: «Нужно внедрить ИИ в отдел продаж, 12 менеджеров, звонки в телефонии, CRM есть. Сколько стоит?» Выход для менеджера: размер команды, система, цель, недостающие сведения и ссылка на оригинальное сообщение. Цену без вводных агент не придумывает.

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

Схема передачи: от сообщения до CRM

Если интеграция с CRM временно не работает, заявка должна остаться в очереди с сигналом оператору. «Отправили API-запрос» не равно «карточка успешно создана»; проверяйте подтверждение и повтор без дубля.

Когда нужен человек, а не следующий ответ модели

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

В руководстве по передаче от виртуального агента человеку Google описывает сам принцип маршрутизации; конкретная реализация зависит от вашего контакт-центра. Продумайте также рабочие часы: обещание «менеджер сейчас подключится» вечером создаст ложное ожидание.

Как проверить, что поток стал лучше

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

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

Что делать с повторным обращением

Клиент может сначала написать в форму, потом в мессенджер и позвонить через час. Если система создаст три независимые заявки, менеджеры начнут отвечать несогласованно. Если ошибочно сольёт обращения разных людей с похожими именами, проблема ещё серьёзнее. Начните с предложения «возможно, это дубль» для сотрудника. Автоматическое объединение допускайте только при надёжных идентификаторах и проверенном правиле.

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

Вопросы перед подключением ещё одного канала

Кто отвечает, если из нового канала не приходит контакт? Как сохраняется согласие на обработку? Что происходит при сбое сервиса и повторной доставке одного сообщения? Есть ли единое правило, когда клиент получает автоматическое подтверждение? Ответьте на эти вопросы до подключения, иначе каждый канал создаст собственную логическую «дыру».

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

Два рабочих маршрута для разных заявок

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

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

Как не исказить смысл голосового обращения

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

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

Отчёт, который действительно поможет руководителю

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

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

Минимальный план запуска по неделям

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

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