Как контролировать следующий шаг по сделке в CRM

Открытая сделка может неделями оставаться в воронке, хотя менеджер не запланировал следующее действие. Бывает и иначе: задача создана, но после смены стадии устарела, а отметка «выполнено» не подтверждена результатом контакта.

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

Какую проблему решает контроль следующего шага

Для каждой открытой сделки нужно различать три сущности:

1. Факт прошлого контакта — что уже произошло: состоялась встреча, получено письмо, отправлен документ.
2. Текущая стадия — в каком состоянии находится сделка сейчас.
3. Следующий шаг — кто, что и к какому сроку должен сделать, чтобы продвинуть сделку или зафиксировать решение.

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

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

Поисковый спрос и выдача по этой теме не измерялись. Связь материала с задачами внедрения — редакционная гипотеза, а не доказанная конверсия.

Какие данные нужны для следующего действия

Состав полей зависит от цикла продаж и последствий пропуска. Для начала можно использовать такую запись:

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

Формулировка «позвонить клиенту» станет проверяемой, если записать: «до 24 октября менеджер звонит, чтобы согласовать дату демонстрации; результат — дата встречи или зафиксированный отказ». Это пример структуры, а не норматив срока для любой компании.

Как связать стадию сделки и задачу менеджера

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

В Dynamics 365 Sales шаблоны последовательностей содержат набор действий, который направляет продавца к следующему действию в заданном сценарии. Шаги шаблона можно добавлять и удалять с учётом требований организации. Это документированная возможность Dynamics 365 Sales, а не подтверждение такой функции в любой CRM. Доступность зависит, в частности, от лицензии, роли, включённых функций и используемого приложения.

Для будущего внедрения стоит задать ещё три требования:

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

Когда создавать, изменять и закрывать задачу

Состояние задачи меняется вслед за подтверждёнными событиями процесса.

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

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

В обзорном материале Битрикс24 сказано, что Comindware CRM после переговоров может фиксировать договорённости и обещания и назначать исполнителей. Это вторичный обзор другого вендора, а не документация Comindware и не опыт внедрения Switch On AI. Наличие функции, условия доступа и качество извлечения договорённостей нужно отдельно проверять в выбранном продукте.

Как устроить напоминание и передачу исключения

Напоминание и эскалация решают разные задачи.

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

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

Dynamics 365 Sales с включённой функцией email engagement позволяет задать для отправленного письма напоминание на определённую дату и время. Для отслеживаемых писем также доступны условия «нет ответа» и «письмо не открыто». Эти возможности относятся к письмам в Dynamics 365 Sales и не доказывают наличие универсального контроля задач в другой CRM. Настройка времени зависит от часового пояса приложения.

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

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

Как подтвердить выполнение следующего шага

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

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

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

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

Условный пример прохождения сделки

Ниже — синтетический учебный пример. Это не клиентский кейс Switch On AI и не результат выполненного теста.

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

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

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

Проверка, ограничения и подготовка внедрения

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

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

Функции зависят от продукта, тарифа, включённых возможностей, ролей, API и настроек. Документация Dynamics 365 Sales не подтверждает совместимость с другой CRM. Наличие защиты от дублей, истории изменений и нужной логики по умолчанию тоже нельзя предполагать: эти свойства проверяют в фактической среде.

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

Для обсуждения проекта подготовьте:

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

Switch On AI помогает разработать и внедрить помощника для продаж, если готовых правил CRM недостаточно. Мы начинаем с разбора одного маршрута, проверяем доступные операции и права, затем согласуем границы действий системы и человека. Бесплатный прототип показывает ключевой фрагмент сценария и не равен полноценному внедрению. Состав работ, трудозатраты, интеграции и сопровождение согласуются отдельно.