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

Что происходит в момент перехода на стадию?

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

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

Что роботы стадии не видят: откуда сделка пришла. В бизнес-процессе есть переменная с текущей стадией и нет переменной с прошлой. Для платформы переход — это факт присвоения нового значения полю, а не пара «откуда → куда».

Как узнать, с какой стадии пришла сделка?

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

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

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

Как поймать откат сделки назад по воронке?

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

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

Тот же приём отличает «сделка дошла до успеха своим ходом» от «её перетащили из середины воронки сразу в „Сделка успешна“». Разница видна только по прошлой стадии — по текущей обе выглядят одинаково.

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

Роли CRM умеют ограничивать работу с конкретными стадиями: в правах доступа роли задаётся, какие стадии сотрудник видит и меняет. Чего роли не умеют — так это описать правило про сам переход: «только вперёд», «не дальше чем на одну стадию», «нельзя в „Успешна“, пока не приложен акт». Права работают со стадией как с состоянием, а не с парой «откуда → куда».

Правило про переход собирается роботом. На стадии-адресате проверяете, откуда пришла сделка и выполнены ли требования; если правило нарушено — «Обновить сделку по ID» возвращает её на прежнюю стадию, а ответственному уходит уведомление с причиной. Получается не запрет в интерфейсе, а откат за секунду и объяснение — на практике это работает лучше, потому что менеджер узнаёт правило, а не натыкается на серую кнопку. Тонкости, кто и что при этом имеет право делать, разобраны в статье про права доступа и роботов.

Чтобы требования стадии были видны до попытки перехода, а не после, положите их в карточку: поле «Чек-лист по стадии» показывает на каждой стадии свой список обязательных и опциональных действий.

Сколько сделка простояла на стадии?

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

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

Что происходит при переносе сделки в другую воронку?

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

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

Что дальше

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

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