Разработка AI SDR — цифрового менеджера по продажам

Почему AI SDR не закрывает лиды: где ломается воронка

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

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

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

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

Что даёт цифровой менеджер по продажам: эффект по этапам

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

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

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

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

Режимы работы AI SDR: сравнение подходов и ограничения

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

Что ограничивает автоматизацию

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

Этапы внедрения: от аудита воронки до передачи в поддержку

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

Этапы внедрения

1. Аудит воронки и данных — выгружаем историю обращений, размечаем, где теряются сделки, и проверяем, какие поля CRM заполняются по факту. На выходе карта этапов и список недостающих данных.
2. Проектирование сценариев — ветки диалога, квалифицирующие вопросы, правила передачи человеку, обработка отказов и границы обещаний. Тон и формулировки согласуем до настройки.
3. Схема решения — какие системы связываем, где хранятся данные и логи, кто владеет правами доступа. Схема утверждается до работ по интеграциям.
4. Настройка интеграций — CRM, телефония, мессенджеры, календарь: задания на касания, запись ответов, создание сделок и задач. Отдельно проверяем поведение при недоступности внешней системы и повторных событиях.
5. Проверка на реальных обращениях — теневой режим: ассистент работает, но решения сверяет человек. Смотрим долю корректной квалификации, ошибочные передачи и время ответа.
6. Приёмка и передача в поддержку — регламенты, каталог сценариев, инструкции, порядок правок. Обучаем команду и фиксируем метрики, по которым качество отслеживается дальше.

Что остаётся у заказчика: сценарии, политики, документация

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

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

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

Кейс: как выросла доля квалифицированных лидов

Клиент — поставщик промышленного оборудования с длинным циклом сделки. Входящие обращения распределялись вручную: очередь разбирали дважды в день, поэтому первый ответ уходил через 4–6 часов, а часть заявок оставалась без касания до следующего утра. Замеры до внедрения показали, что 38% диалогов умирали на первом шаге, а до назначенной встречи доходило около 6% обращений.

Что изменили в схеме

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

Метрики до и после

• Время первого ответа: 4–6 часов → 40 секунд, включая ночные и выходные обращения.
• Отвал лидов на первом шаге: 38% → 11% — часть отсева забрала на себя квалификация.
• Доля диалогов, доведённых до передачи менеджеру, выросла в 2,4 раза.
• Конверсия во встречу: 6% → 14% при том же потоке входящих.

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

Чем цифровой менеджер отличается от чат-бота на сайте?

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

Цифровой менеджер по продажам (AI SDR) устроен иначе. Сценарий остаётся, но не как маршрут, а как рамка: какие данные о задаче нужно собрать, что предложить, при каких условиях остановиться. Сам диалог ведёт языковая модель — она понимает переформулировки и держит цель разговора, а не номер шага.

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

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

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

Сомнения инженера: доступы, данные, контроль качества

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

Что делать с неполной базой или дублями?

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

Кто утверждает формулировки и что агент не имеет права говорить?

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

Где хранятся данные и кто их видит?

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

Обсудим вашу задачу: оценка, план и чек-лист старта

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

Что полезно подготовить к первой встрече:

• Воронка и источники: откуда приходят обращения, сколько их за месяц и на каком этапе теряется больше всего лидов.
• Логика квалификации: какие вопросы менеджер задаёт первыми и по каким признакам помечает обращение целевым.
• Каналы: почта, мессенджеры, формы на сайте — где цифровой менеджер должен работать и с какими ограничениями.
• База знаний: описания продуктов, условия работы, типовые возражения и принятые формулировки ответов.
• Учёт сделок: где фиксируются обращения, какие поля обязательны и кто первым берёт тёплый контакт в работу.
• Запреты: что цифровой менеджер не должен делать сам — обсуждать цену, называть сроки, вести переговоры.
• Метрики: скорость первого ответа, доля квалифицированных обращений, конверсия в диалог с менеджером.

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