Михаил Иванов, руководитель B2B-продаж «Слетать.ру», рассказывает, какие задачи после общения с клиентом действительно можно передать ИИ, а где решение всё равно должно оставаться за менеджером и руководителем отдела продаж.
Когда компании начинают экспериментировать с ИИ в продажах, первым делом обычно показывают что-нибудь эффектное. Нейросеть пишет письмо, делает саммари звонка, предлагает скрипт или за несколько секунд превращает длинный разговор в аккуратный текст.
Выглядит убедительно. Но в реальной работе продавца есть более приземлённая проблема .
Допустим, клиент обозначил условие. Менеджер пообещал прислать расчёт. Ещё договорились вернуться к вопросу после внутреннего совещания клиента.
Проходит день. В CRM написано «думает». Задача есть, но без даты. Прогноз по сделке не изменился. Сам разговор при этом мог пройти хорошо.
И вот здесь ИИ становится интересен не как «виртуальный продавец», а как инструмент, который помогает не потерять то, о чём люди только что договорились.
После одного звонка нужны два разных результата У менеджера и руководителя отдела продаж после клиентского контакта разные задачи.
Менеджеру нужен понятный рабочий итог: что важно клиенту, какие условия уже подтверждены, что осталось открытым, кто и что должен сделать дальше.
РОПу совершенно не обязательно читать расшифровку каждого разговора.
Ему интереснее другое: где что-то пошло не так .
Например:
клиентская задача понятна, а следующего события нет; менеджер обещал отправить материал, но срок уже прошёл; изменилась сумма или дата, а прогноз остался прежним; решение зависит от человека, которого ещё даже не подключили; одна и та же проблема повторяется сразу у нескольких сотрудников. Источник при этом один: звонок, встреча или переписка. Но результат из него нужен разный.
Для менеджера ИИ может сократить путь от разговора до следующего действия. Для руководителя — подсветить места, где реальные договорённости уже разошлись с тем, что происходит в процессе.
Это принципиально разные задачи.
Мы сначала попытались свести всё к одному баллу. Не получилось В одном из внутренних проектов мы калибровали пилотный стандарт качества B2B-диалогов сразу для двух направлений.
Первая версия была довольно очевидной: взять разговор и дальнейшее ведение сделки и свести всё к одной итоговой оценке. На практике эта логика быстро начала ломаться .
Один пропущенный следующий шаг мог несколько раз снижать итоговый результат. Отметка «не применимо» трактовалась по-разному. Хорошо заполненная CRM могла скрывать слабый разговор. А качественный разговор, наоборот, соседствовать с плохо оформленным следующим шагом.
В итоге один средний балл не объяснял, что именно сломалось. Поэтому методику разделили на два независимых контура .
Первый — качество самого диалога: задача клиента, критерии выбора, договорённости, открытые вопросы.
Второй — то, что произошло после: запись в CRM, действие и дата, ответственный, изменение прогноза.
Для разных типов звонков появились свои профили . Для «не применимо» стало обязательным пояснение. Один дефект учитывается один раз. Часть выборки проходит двойную проверку.
И важный момент : пилот нужен для калибровки правил, а не для рейтинга сотрудников или санкций. Смысл такого разделения простой: сначала понять причину сбоя, а уже потом решать, что с ней делать.
Что ИИ может сделать для менеджера До разговора помощник может собрать контекст из разрешённых источников: предыдущие договорённости, открытые вопросы, обещания сторон, изменения в карточке клиента.
При этом задача не в том, чтобы написать менеджеру жёсткий сценарий разговора. Полезнее подсветить пробелы .
Кто на самом деле принимает решение? Какое событие определяет срок? Что клиент уже отверг? Какие данные ещё нужно уточнить?
После разговора хороший результат тоже довольно конкретный.
Во-первых, факты со стороны клиента: его задача, ограничения, критерии выбора, участники и сроки. Только то, что действительно прозвучало.
Во-вторых, обязательства сторон: что пообещал менеджер и какое действие подтвердил сам клиент.
Дальше — следующий шаг: что сделать, когда, кто отвечает и по какому каналу продолжить общение. Плюс открытые вопросы и риски, которые нельзя закрыть догадкой. И только после этого — черновики резюме, follow-up и изменений в CRM.
Здесь для меня ключевое слово — черновики . Если модель неправильно распознала сумму, дату или участника сделки, автоматическая запись не исправит проблему. Она просто быстрее перенесёт ошибку дальше.
Поэтому последнее подтверждение остаётся за человеком.
А руководителю не нужен ещё один архив расшифровок С РОПом ситуация другая.
Если ИИ просто собирает для него все разговоры менеджеров в одну большую папку, ценность довольно сомнительная. Руководитель и без того не страдает от нехватки информации.
Ему нужна короткая очередь ситуаций, где действительно требуется внимание.
По каждой из них должно быть понятно: что произошло, как это может повлиять на сделку или прогноз, кто отвечает за следующий шаг и до какого момента вмешательство вообще имеет смысл.
В этом случае ИИ снимает с руководителя не саму управленческую работу, а поиск материала для неё .
Решение всё равно остаётся за РОПом: подключаться ли к переговорам, менять ли приоритет, пересматривать ли прогноз, какой навык разбирать с сотрудником.
ИИ здесь полезен до момента принятия решения. Не вместо него.
Голосовые сообщения: хороший пример границы Один из случаев был совсем бытовым.
Потенциальный партнёр прислал четыре голосовых сообщения с вопросами о формате работы, документах и условиях. ИИ локально расшифровал сообщения, собрал вопросы в одну структуру и подготовил черновик ответа.
Для менеджера это уже ощутимая экономия времени: не нужно несколько раз переслушивать голосовые и вручную собирать из них список вопросов. Но на проверке в черновике обнаружилась формулировка об отсутствии штрафов при досрочном прекращении.
Она не была подтверждена. Такую вещь уже нельзя просто отправить клиенту — сначала нужно свериться с договором. В итоге ИИ сделал полезную часть работы: разобрал входящий материал и подготовил структуру ответа. Но обещание клиенту от своего имени не дал.
Именно так, на мой взгляд, и должна проходить граница.
Ещё одна проблема — когда сами данные устарели Другой внутренний проект был связан с управленческим экраном, который собирал данные из нескольких источников. В какой-то момент система дала сразу два ложных сигнала.
Устаревший срез CRM показал отсутствие продаж в одном направлении. А изменившаяся структура еженедельной таблицы привела к тому, что факты разных продуктов объединились.
Если смотреть только на итоговую цифру, можно было сделать вполне убедительный — и неправильный — вывод. Пришлось развести источники.
Денежный факт берётся из рабочей таблицы. Воронка и действия — из CRM. Рядом показывается актуальность данных.
Если информация устарела, система не подставляет ноль и не пытается решить за руководителя, что произошло. Она показывает, что есть ограничение или расхождение.
Для ИИ-помощника это особенно важно. Любой управленческий сигнал должен отвечать хотя бы на два вопроса: откуда взялись данные и насколько они актуальны.
Если источники расходятся, задача системы — показать расхождение, а не замаскировать его красивым выводом.
Что я бы точно не отдавал ИИ Есть задачи, где автоматизация выглядит особенно соблазнительно, но риск ошибки уже слишком дорогой.
ИИ может найти нужный фрагмент разговора, сопоставить его с правилами процесса, подготовить текст или обратить внимание на отклонение.
Но самостоятельно обещать клиенту скидку — нет. Менять коммерческие условия — нет. Переносить сумму в прогноз без подтверждения — тоже нет. Так же как приписывать клиенту мотивы или делать кадровые выводы о сотруднике по одному разговору.
Есть и отдельный вопрос доступа к информации .
Записи разговоров, контакты и коммерческие условия должны обрабатываться только в утверждённом контуре. Для аналитики имеет смысл использовать минимально необходимый набор данных, а не размножать полные расшифровки и персональную информацию по таблицам и рабочим чатам.
Как начать без большого «ИИ-проекта» Я бы вообще не начинал с покупки универсального «ИИ-продавца». Проще взять одно конкретное событие: закончился содержательный разговор с клиентом. И посмотреть, что должно произойти после него.
Менеджеру нужен проверяемый рабочий итог. Руководителю — список отклонений, где его вмешательство ещё может что-то изменить .
Дальше можно зафиксировать обязательный формат: факты, обязательства сторон, следующий шаг, открытые вопросы, изменение прогноза.
Перед записью в CRM и отправкой сообщения клиенту оставить подтверждение менеджера. РОПу показывать не все разговоры подряд, а только отклонения.
А первые недели отдельно смотреть, что сотрудники исправляют в предложениях модели и с какими выводами не согласны. Это хороший материал для настройки правил. И уже после этого считать эффект.
Например, смотреть, сколько времени проходит от разговора до содержательной записи в CRM. У какой доли сделок есть согласованный следующий шаг. Выполняется ли обещанный follow-up. Насколько быстро изменения попадают в прогноз. И как часто сотрудникам приходится исправлять то, что предложил ИИ.
Это куда полезнее, чем просто считать количество сгенерированных текстов .
Главный критерий довольно простой Если после внедрения ИИ текстов стало больше, а после разговора с клиентом всё ещё непонятно, кто, что и когда должен сделать, большого смысла в такой автоматизации нет. Это просто ещё один сервис генерации контента.
Полезный инструмент начинается в другом месте : когда после контакта остаются проверенные факты, обязательства и следующий шаг. А руководитель узнаёт об отклонении не тогда, когда сделка уже потеряна, а пока ещё может на неё повлиять.
Комментарии