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

Название этапа нужно превратить в условие, которое можно проверить. Для нашей учебной сделки «Предложение обсуждается» означает: покупатель подтвердил получение и согласовал обсуждение. Отправленный файл доказывает отправку. Согласованное обсуждение доказывает другой факт.

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

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

Обязательные поля по стадиям уже есть в готовых CRM. В документации Битрикс24 описана настройка, при которой сотрудник не сможет сохранить или переместить карточку без нужного поля. Обязательность можно задать для отдельных стадий; доступность зависит от тарифа. Это проверено по документации вендора 8 октября 2026.

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

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

Причину остановки нельзя свести к обязательному списку отказов. В учебной сделке закупщик может ждать утверждения бюджета. Это пауза с датой пересмотра. Он может сообщить, что закупку отменили. Это отказ с подтверждением. А если менеджер не связался с закупщиком, причина пока не выяснена.

Просроченное действие должно попадать в список внимания руководителя. Само истечение срока не доказывает отказ и не даёт оснований автоматически закрыть сделку. Иначе статистика начнёт описывать таймер CRM вместо решений покупателей. Для подтверждённой паузы нужен срок возврата; для неизвестной причины нужен ответственный за её выяснение.

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

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

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

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

У нас нет клиентского кейса, в котором такая доработка сократила зависание сделок. Наш опыт относится к vibecoding.ru: инженер ведёт машину агентов, она исполняет записанные правила, а ошибки становятся поводом изменить код и проверки. Карта нашей машины показывает её устройство. Показатели сайта нельзя выдавать за эффект автоматизации чужого отдела.

В нашей машине «Контакты» показывают, кто оставил обращение, а «Ручейки» помогают разбирать путь до него. Запись контакта ещё не подтверждает весь путь: если следа касания нет, источник остаётся «Не записано». Придуманный источник испортил бы выводы о привлечении так же, как придуманная причина отказа искажает отчёт CRM.

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

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

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

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

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

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

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

Если штатных настроек не хватает, разработка по подписке подходит для реализации и последующих правок правила. В тарифе «Один проект» на 8 октября 2026 цена 250 000 ₽ в месяц. Это цена подписки, не смета одной проверки и не обещание срока. Инженер ведёт машину агентов, которая дописывает код CRM; смысл этапов и решение по покупателю остаются за руководителем.

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

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

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