История запусков и повтор: как спасти упавший шаг процесса

Четверг, 08:40. Менеджер приёмной комиссии открывает панель и видит, что ни один из тридцати восьми абитуриентов, заполнивших форму вчера вечером, не получил приветственное сообщение. Процесс при этом не выглядит сломанным: статус «активен», триггер сработал тридцать восемь раз, первые два шага завершены. Упал только третий шаг — у канала, который несёт сообщение, в 23:10 истекла авторизация, и каждый запуск после этого останавливался в одной и той же точке. Никто ничего не настроил неправильно. Просто никто не посмотрел и никто не перезапустил.

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

Где именно ломается запуск?

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

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

На какой вопрос должна отвечать история запусков?

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

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

Какие ошибки стоит повторять, а какие бесполезно?

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

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

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

Отправит ли повтор второе сообщение?

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

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

Когда массовый повтор — верное решение?

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

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

Почему копятся недоведённые запуски?

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

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

Чинить процесс или спасать запуск?

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

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

Кто и как быстро должен узнать об ошибке?

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

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

Где отрепетировать восстановление до публикации?

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

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

Как превратить это в еженедельную привычку?

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

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

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

Повтор запускает процесс с самого начала?

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

Сколько раз повторять разумно?

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

Какие запуски повторять нельзя?

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

Есть ли смысл повторять старый запуск спустя дни?

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