Я собрал ИИ-продавца и понял: вовремя позвать менеджера важнее красивого диалога

Я собрал ИИ-продавца и понял: вовремя позвать менеджера важнее красивого диалога

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

Продавец и консультант — не одно и то же

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

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

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

Ловушка ещё одного вопроса

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

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

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

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

Ложные обещания дешевле, чем кажется

Отдельная история — когда бот отвечает уверенно там, где должен был передать слово человеку. Сроки, индивидуальные условия, «да, скорее всего, так можно», «обычно мы идём навстречу». Формально это не обман, а вежливая неопределённость. По факту клиент услышал обещание и запомнил его именно как обещание. Дальше менеджеру приходится не продавать, а разбираться с ожиданиями, которые нафантазировал его же собственный бот.

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

Что считать готовностью

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

GPT-ЛОГИЯ

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

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

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

Что уходит менеджеру вместе с лидом

Самая недооценённая часть — не сам переключатель, а то, что после него остаётся. Если менеджер получает уведомление «клиент хочет поговорить» и пустую историю, ему может понадобиться начинать разговор с нуля. Клиент второй раз рассказывает то же самое, настроение падает, и весь смысл ИИ-продавца испаряется.

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

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

Как это описано у Market-GPT

По описанию на сайте Market-GPT, ИИ-продавец встроен в общий маршрут: заявка на лендинге, затем продолжение диалога в Telegram или MAX, уточняющие вопросы, фиксация ответов и передача подготовленного клиента менеджеру. В сводке для менеджера заявлены интерес, бюджет и этап диалога, а в контроле лидов — статусы «Новый», «В диалоге», «Нужен человек», «Обработан» и «Закрыт». Именно статус «Нужен человек» здесь и есть самое интересное место всей конструкции.

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

Ценность такой схемы, на мой взгляд, не в том, что бот «умный». А в том, что передача менеджеру встроена в поток как нормальный этап, а не как аварийный выход. В заявленной логике у лида есть путь, менеджеру передаётся контекст, у статуса есть смысл.

Если хочется посмотреть, как это устроено не в виде теории, а в виде конкретной логики заявки и передачи, у Market-GPT есть открытое описание — market-gpt.ru. Не как волшебная кнопка, а как пример того, что цепочку «заявка — диалог — человек» кто-то собирает целиком, а не по частям.

Где всё ломается

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

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

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