Как выбрать подрядчика по ИИ-продавцам, если почти каждый показывает убедительное демо?
На демонстрации агент отвечает быстро, знает продукт и уверенно ведёт разговор. Но в живой работе может слишком рано просить телефон, повторять вопросы, терять контекст, обещать лишнее или передавать менеджеру длинную переписку без понятного следующего шага.
Поэтому вопрос «какую платформу выбрать» лучше ставить не первым. Сначала нужно определить, какой конкретный маршрут обращения должен стать управляемым.
Например:
- пациент написал в клинику вечером;
- покупатель спросил о стоимости дома на Авито;
- человек оставил заявку на программу обучения;
- потенциальный клиент запросил расчёт на сайте.
Хороший подрядчик начинает не с перечня функций. Он разбирает один маршрут от первого сообщения до передачи человеку и помогает заранее договориться, что считать полезным результатом.
Ниже — девять вопросов, которые стоит задать до пилота.
Сначала — маршрут и результат
1. Какой бизнес-маршрут мы проверяем первым?
Фраза «автоматизируем продажи» слишком широкая. Внутри неё могут быть десятки каналов, продуктов, команд и исключений.
Для старта нужен один маршрут: один источник обращения, один тип запроса, один ответственный сотрудник и один понятный следующий шаг.
Если подрядчик сразу предлагает подключить все каналы и продукты, попросите показать, как будет работать один конкретный сценарий. Это быстро отделяет рабочий проект от презентации возможностей.
2. Что агент должен сделать в первые минуты?
Быстрый ответ важен, но сам по себе ничего не завершает.
Нужно заранее определить задачу первой части диалога: понять предмет запроса, уточнить несколько полей, получить согласованный контакт, объяснить следующий шаг и передать разговор человеку.
Если нет этой последовательности, агент может поддерживать приятную беседу, но не собирать полноценную заявку.
3. Какие данные действительно нужны менеджеру?
Поля квалификации зависят от бизнеса. Для строительства важны объект, участок, сроки и бюджетный ориентир. Для обучения — программа, задача, сроки и готовность к разговору. Для клиники — запрос пациента, удобное время, канал связи и уже обсуждённый контекст.
Универсального списка для всех нет.
Попросите подрядчика показать карточку, которую получит ваш сотрудник. Если карточка непонятна менеджеру, значит и агент пока настроен не под реальную работу.
На примере стоматологии я отдельно разобрал, что должна содержать карточка обращения после переписки.
Затем — границы и данные
4. Где заканчивается роль агента и начинается роль человека?
Это один из главных вопросов безопасности и качества.
Нужно заранее определить, какие вопросы агент задаёт, какие темы не обсуждает, когда прекращает уточнения, в какой момент передаёт диалог, кто принимает обращение и что происходит, если человек сразу просит живого сотрудника.
Хорошая автоматизация не прячет человека. Она готовит для него контекст и сокращает повторяющуюся часть работы.
5. Какие формулировки должны быть закреплены заранее?
Свободная генерация текста удобна не во всех точках.
Условия, ограничения, цены, правила передачи, юридически значимые фразы и чувствительные темы часто требуют заранее проверенных формулировок.
Спросите, какие части диалога будут фиксированными, а какие агент сможет формулировать сам. Также уточните, кто со стороны вашего бизнеса согласует эти тексты и как будут вноситься изменения.
6. Какие данные и подключения нужны для старта?
Интеграция с CRM полезна, когда понятно, что именно туда передавать. Но сложное подключение до проверки сценария может затянуть запуск и скрыть главную проблему.
Для первого пилота иногда достаточно одного канала, согласованного сценария, передачи карточки в рабочую группу, ручной фиксации результата и понятного владельца процесса.
Попросите разделить обязательное для старта и то, что понадобится только после успешной проверки. Это защищает проект от лишней сложности.
Потом — правила пилота
7. Как будет устроен пилот?
Пилот нужен не для того, чтобы «посмотреть на ИИ». Он нужен для решения: продолжать, доработать или остановить.
До старта должны быть зафиксированы один маршрут, период проверки, объём доступных обращений, ответственный со стороны бизнеса, способ разбора диалогов и дата решения.
Если в конце пилота нет заранее назначенной точки решения, проект легко превращается в бесконечную настройку.
8. Что мы будем сравнивать?
Нельзя честно оценить изменение без исходной точки.
До запуска стоит посмотреть несколько последних обращений и зафиксировать время до первого ответа, долю диалогов с нужным контекстом, полноту карточки, качество передачи человеку и наличие следующего шага.
Не обязательно строить большую аналитическую систему. Для начала достаточно согласованного способа читать один маршрут до и после запуска. Практический пример такого разбора — статья как проверить обработку заявок после первого ответа.
Подрядчик не должен обещать точный рост выручки до данных вашего бизнеса. Пилот как раз и нужен, чтобы заменить общие обещания наблюдаемыми фактами.
9. Кто отвечает за работу после запуска?
Даже хороший сценарий меняется. Появляются новые вопросы клиентов, продукты, сотрудники и исключения.
Уточните заранее, кто смотрит проблемные диалоги, как исправляются ошибки, кто обновляет базу знаний, что входит в сопровождение, где проходит граница доработок и кому принадлежат доступы.
Без этого агент может хорошо работать в день запуска и постепенно расходиться с реальным процессом.
Красные флажки при выборе подрядчика
Я бы насторожился, если подрядчик:
- начинает только с функций платформы;
- показывает идеальный пример, но не просит реальные диалоги;
- обещает одинаковый результат в разных нишах;
- не может показать карточку для сотрудника;
- не фиксирует момент передачи человеку;
- предлагает большую интеграцию до проверки сценария;
- не называет дату и критерии решения по пилоту;
- обещает окупаемость без ваших данных;
- не объясняет, кто поддерживает систему после запуска.
Это не означает, что такой проект обязательно провалится. Но риск купить демонстрацию вместо рабочего процесса становится выше.
Как принять решение без долгой перестройки
Практичный порядок выглядит так:
- Выбрать один маршрут обращения.
- Взять 10–20 обезличенных диалогов.
- Определить несколько полей карточки.
- Согласовать границу передачи человеку.
- Запустить ограниченную проверку.
- Назначить дату решения.
- Масштабировать только после фактов.
Такой подход не требует сразу менять всю CRM или перестраивать отдел продаж. Он позволяет увидеть, способен ли подрядчик превратить живое обращение в понятный следующий шаг.
Если вы выбираете подрядчика по ИИ-продавцам, начните с одного реального маршрута. На странице ИИ-Квалификатора ALIOT можно посмотреть механику и перейти к разбору своих обращений.
