Как AI определяет следующий шаг по сделке

Я смотрю на «Как AI определяет следующий шаг по сделке» глазами менеджера, который открыл CRM и должен понять следующий шаг. Для сделки правило простое: если система добавляет ему ещё одну проверку или ещё одно непонятное поле, она не помогает продажам.

В CRM стоит стадия «Коммерческое предложение отправлено». Последняя активность — письмо недельной давности. Менеджер уверен, что клиент «думает», а в переписке уже есть конкретное возражение по срокам запуска.

Система напоминает позвонить, хотя покупатель просил вернуться с расчётом в четверг. Здесь проблема не в отсутствии follow-up. Проблема в том, что следующий шаг выбран без понимания состояния сделки.

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

CRM при этом остаётся источником истины, а не фоном для «умной» памяти агента.

Коротко: как AI выбирает следующий шаг по сделке

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

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

Автоматически можно создать внутреннюю задачу с понятным основанием. Отправлять сообщение клиенту безопасно только в узких сценариях с утверждённым содержанием. Если контекст противоречив, AI не «дожимает», а просит менеджера проверить сделку.

Сначала восстановите фактическое состояние сделки

Стадия в CRM редко содержит всю правду. Менеджер мог не передвинуть карточку после встречи. Клиент мог ответить в Telegram, пока вся переписка хранится в почте. Обещанный расчёт мог существовать только в заметке.

Если AI видит один источник, рекомендация будет аккуратной по форме и ошибочной по сути.

Перед выбором действия формируется «досье сделки» на определённый момент времени:

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

Важно различать факт и вывод. «Клиент открыл письмо» — событие. «Клиент заинтересован» — интерпретация. «На встрече попросили расчёт для 50 пользователей к 12 августа» — договорённость. Каждому типу данных нужен свой вес и срок актуальности.

Пять сигналов, которые меняют рекомендацию

Стадия сделки

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

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

История контактов

AI должен видеть не только последнее сообщение. Фраза «давайте позже» после трёх неотвеченных писем означает одно. Та же фраза после согласованной встречи и просьбы вернуться после совета директоров — другое. История помогает не путать паузу по договорённости с потерей интереса.

Просроченные обязательства

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

Возражения и блокеры

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

Вероятность ответа

Здесь я смотрю на процесс глазами менеджера.

Модель может оценить, насколько уместен канал и момент контакта, но этот прогноз не должен отменять явную договорённость. Если клиент попросил написать в четверг, статистически «лучший» вторник не имеет значения. Явное обещание важнее вероятностного сигнала.

Матрица действий: не путать активность с движением сделки

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

«До 15:00 уточнить у Ирины, согласован ли бюджет на 50 лицензий. Если нет — перенести сделку в ожидание бюджета до 1 октября» — рабочая.

Как выглядит рекомендация в CRM

Менеджеру не нужен ещё один длинный пересказ сделки. Карточка рекомендации должна помещаться в рабочий экран:

• Действие: подготовить расчёт на 50 пользователей;
• Срок: сегодня до 16:00;
• Основание: клиент запросил расчёт на встрече 10 августа;
• Контекст: важен запуск до конца квартала;
• Уверенность: высокая, подтверждена явной договорённостью;
• Владелец: менеджер сделки;
• Завершение: файл прикреплён и отправлен после проверки;
• Альтернатива: если тариф неизвестен — запросить подтверждение у пресейла.

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

Как я связываю событие со следующим шагом

События о сделке поступают из CRM, почты, телефонии, календаря и разрешённых мессенджеров. Нормализатор связывает их с одной карточкой и удаляет дубли.

Сервис состояния собирает факты на текущий момент. AI выделяет договорённости, вопросы и блокеры, но не записывает их напрямую в критичные поля.

Policy layer проверяет, допустимо ли предложенное действие на этой стадии, не нарушает ли оно стоп-лист коммуникаций, сроки и полномочия. Затем recommendation service создаёт предложение.

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

HubSpot Deals API и Salesforce REST API дают программный доступ к сделкам, но сам API не решает вопрос истинности данных. Для каждого обновления нужны источник события, версия карточки и идемпотентный ключ. Повтор webhook не должен создавать вторую задачу.

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

Что даёт кейс Flow AI — и чего он не доказывает

В кейсе Flow AI описан движок для outreach в недвижимости, где автоматизация объединяет голосовой канал и рабочий процесс. Для next-best-action полезен сам паттерн: действие зависит от текущего состояния и результатов предыдущего контакта, а не генерируется в вакууме.

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

Где рекомендации ломаются

Стадия устарела. AI предлагает действие для квалификации, хотя договор уже у юриста. Сначала обновляют состояние из фактов, затем строят рекомендацию.

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

Просроченная рекомендация остаётся активной. После ответа клиента старый follow-up должен автоматически погаснуть. Рекомендация имеет срок действия и список событий отмены.

Модель придумывает обязательство. Любая ссылка на обещание должна вести к звонку, письму или заметке. Если источника нет, формулировка маркируется как предположение.

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

AI отправляет клиенту без контроля. Внешняя коммуникация может создать обещание или ошибочно раскрыть данные. Сначала автоматизируют внутреннюю рекомендацию; отправку разрешают только для проверенных узких шаблонов.

CRM и агент хранят разные состояния. Собственная память агента не может быть второй базой сделок. После каждого изменения он перечитывает актуальную версию карточки.

Метрики: отделить качество совета от дисциплины исполнения

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

Пилот на одной части воронки

1. Выберите момент, где сделки застывают. Например, период после демонстрации до получения обратной связи.
2. Опишите допустимые действия. Запрос данных, расчёт, встреча, подключение эксперта, пауза, закрытие.
3. Очистите обязательные поля. Стадия, владелец, следующий контакт, продукт и сумма должны иметь понятные правила.
4. Соберите историю событий. Свяжите письма, задачи и встречи с карточкой, не копируя лишние персональные данные.
5. Запустите теневой режим. AI предлагает шаг рядом с реальным решением менеджера, но не создаёт задачу.
6. Разберите расхождения. Ошибка состояния, контекста, правила, владельца или формулировки — разные причины и разные исправления.
7. Разрешите создание внутренних задач. Добавьте дедупликацию, срок жизни и события отмены.
8. Оценивайте на одинаковых сегментах. Не смешивайте новые лиды, продления и крупные проекты.

Где команда чаще всего сомневается

Может ли AI сам менять стадию сделки?

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

Нужно ли анализировать звонки?

Если ключевые договорённости принимаются на звонках, без них состояние будет неполным. Храните не бесконечный пересказ, а проверяемые факты, вопросы, обязательства и ссылку на исходный фрагмент.

Как не превратить рекомендации в микроменеджмент?

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

Можно ли автоматически отправлять follow-up?

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

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

Смотреть причины по сегментам. Возможно, не хватает канала, устарела стадия или правило не подходит типу сделки. Низкое принятие — диагностический сигнал, а не повод заставлять менеджера нажимать «принять».

Для меня «Как AI определяет следующий шаг по сделке» работает только тогда, когда менеджеру понятен следующий шаг и сделка реально движется. Если CRM стала сложнее — я бы вернулась и упростила процесс.

Источники и рабочие ограничения

Интеграционные допущения сверены с официальной документацией HubSpot и Salesforce, требования к контролю риска — с NIST AI RMF и рекомендациями OWASP для AI-агентов. Кейс Flow AI используется как пример связанного workflow, а не как обещание аналогичных результатов. Решения о коммуникации и обработке данных должны учитывать регламенты компании и применимое законодательство.