Шаг ожидания согласования: как добавить решение человека в автоматизацию

Четверг, 16:40. В отделе продаж мебельного оптовика процесс по коммерческим предложениям третий раз за день делает одно и то же: предложение собрано, PDF сформирован, письмо ушло клиенту. В этот раз в предложении скидка 34 процента — менеджер прочитал прайс строкой ниже. Процесс не возразил, потому что возражать ему никто не поручал. Руководитель отдела увидел скидку на следующее утро, уже после того как клиент написал «согласны». Автоматизация отработала безупречно. Проблема была в том, что она нигде не остановилась.

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

Какие шаги действительно заслуживают человеческого взгляда?

Ворота согласования не бесплатны. Каждые новые ворота добавляют процессу ожидание, уведомление и кусок чьего-то внимания. Поэтому вопрос звучит не «куда бы поставить согласование», а «какой шаг нельзя пропускать без присмотра». Единственный рабочий критерий — обратимость: если шаг отработал неверно, исправление — это один клик или звонок с извинениями?

Обратимость проверяется четырьмя вопросами. Отправляет ли шаг что-то за пределы компании? Содержит ли он денежное обязательство — скидку, возврат, рассрочку? Удаляет или закрывает ли он запись безвозвратно? И кто заметит ошибку первым: вы или клиент? Шаг, который отвечает «да» дважды, должен упираться в человека.

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

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

Где шаг ожидания согласования на самом деле останавливает процесс?

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

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

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

Кому вешать согласование: человеку или роли?

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

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

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

Что согласующий должен видеть на экране?

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

Хорошо собранный запрос несёт предмет решения, величину отклонения, ориентир для сравнения и имя инициатора. То есть не «скидка 34 процента», а «скидка 34 процента: по этому клиенту в среднем 12, потолок категории 20, запросил Дмитрий». Единственное, что остаётся взвесить согласующему, — обоснование отклонения.

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

По каким критериям выставить порог?

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

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

Тип шага	Пример порога	Кто согласует	По истечении срока
Стандартное предложение	Не ниже прайса	Не требуется	—
Предложение со скидкой	До потолка категории	Руководитель группы	Эскалация через 4 часа
Скидка сверх потолка	Любой процент выше потолка	Руководитель отдела	Остаётся в ожидании
Возврат средств	Независимо от суммы	Финансы и руководитель	Остаётся в ожидании
Массовая рассылка	Выше заданного числа адресатов	Ответственный за маркетинг	Отмена через 24 часа

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

Что делать процессу, когда срок истёк?

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

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

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

Как ожидание выглядит со стороны клиента?

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

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

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

Как отрепетировать шаг до публикации?

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

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

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

По каким числам понять, что ворота работают?

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

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

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

Где ворота согласования только мешают?

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

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

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

Если хотите попробовать поставить ворота перед рискованным шагом в своём процессе, создайте аккаунт в Rocketly и опишите первые ворота за несколько минут.

Частые вопросы

Сколько запуск может ждать согласования?

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

Что будет, если согласующий в отпуске?

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

Блокирует ли шаг согласования другие ветки процесса?

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

Можно ли потом проверить, кто и что согласовал?

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