ИИ и воронка продаж: как увидеть зависшие сделки до того, как клиент уйдёт

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

Что считать зависшей сделкой

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

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

Полезно различать три ситуации:

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

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

Какие признаки помогают заметить задержку

Начните с понятных признаков, которые уже можно увидеть в системе учёта клиентов или журнале продаж. Не нужно сразу подключать анализ переписок и сложные прогнозы. Часто достаточно проверить даты, статусы и зафиксированные задачи.

• Время на этапе. Сделка находится на шаге дольше обычного для вашего процесса. Порог лучше задавать по собственным данным, отдельно для разных услуг и типов покупателей.
• Нет назначенного следующего действия. В карточке не указано, кто и когда должен связаться с клиентом или подготовить расчёт.
• Просрочена задача. Менеджер не выполнил запланированный звонок или не отправил предложение в обозначенный срок.
• Повторяются переносы. Дату встречи или решения сдвигали несколько раз, но причина и новый срок не записаны.
• Клиент ждёт ответ компании. Есть вопрос, запрос расчёта или обещание уточнить наличие, но результат не отмечен.
• Изменилась активность. После серии контактов наступила длинная пауза либо клиент перестал отвечать после получения предложения.

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

Как ИИ переводит сигнал в действие

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

Сценарий можно выстроить постепенно:

1. Система получает ограниченный набор полей: этап, даты переходов, задачи, ответственного и статус контакта.
2. Правила или модель отмечают записи, которые требуют проверки, и объясняют причину.
3. Сотрудник подтверждает, что сигнал уместен, или указывает причину, по которой сделка не зависла.
4. Руководитель раз в неделю проверяет частые причины задержек и меняет процесс, если проблема повторяется.

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

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

С чего начать: узкий пилот вместо большой перестройки

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

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

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

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

Как проверить пользу и не принять совпадение за эффект

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

Для проверки подойдут несколько показателей:

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

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

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

Какие данные и действия ограничить

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

Если используются персональные данные, компания должна учитывать требования 152-ФЗ: определить цель и правовое основание обработки, ограничить доступ, соблюдать установленный порядок хранения и проверить условия привлечения поставщиков. Не загружайте сведения клиентов в сторонний сервис без проверки того, где они обрабатываются, кто получает доступ и какие договорные условия действуют. Для клиник отдельно оцените чувствительность информации и не включайте медицинские подробности в тестовые примеры без необходимости.

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

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

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

Сравнение подходов: что внедрить первым

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

Подход	Что делает	Когда подходит	Ограничение
Правила по датам и задачам	Показывают просроченные этапы и отсутствие следующего шага	Данные заполнены, задержка описывается простыми условиями	Не учитывают контекст, если он не записан в системе
ИИ-анализ истории сделок	Сопоставляет несколько признаков и помогает выделить нетипичные задержки	Есть достаточная история и повторяющиеся процессы	Может ошибаться; нужны проверка сотрудника и настройка
Анализ заметок и обращений	Выделяет обещанный срок, вопрос или отсутствие ответа в тексте	Сотрудники ведут заметки в едином формате	Требует особого внимания к персональным данным и качеству распознавания

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

Что делать, если сотрудники не доверяют предупреждениям

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

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

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

Следующий шаг по теме

Базовые материалы и инструменты KM2B для внедрения ИИ в бизнес.

• Услуги KM2B по внедрению ИИ
• Калькулятор экономики ИИ
• ИИ-агенты для бизнеса: что дают и с чего начать
• Автоматизация бизнес-процессов нейросетями: с чего начать