ИИ в CRM: какие задачи можно проверить на звонках и переписке

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

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

Какую работу после разговора можно проверить

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

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

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

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

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

У звонка и переписки разные исходные данные

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

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

Как связать результат с карточкой клиента

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

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

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

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

Какие ошибки включить в тест

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

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

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

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

Что должен подтвердить менеджер

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

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

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

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

Как считать полезность сценария

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

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

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

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

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