Очистка зависших запусков: сценарии, оборвавшиеся на полпути

Четверг, 15:20. Руководитель операционного отдела открывает список еженедельных проверок, смотрит историю запусков и замечает деталь: в сценарии «Follow-up после отправки КП» 63 запуска до сих пор в статусе «выполняется», а самый старый из них стартовал одиннадцать дней назад. Одиннадцать дней без перехода ко второму шагу. В этом примере никто не пожаловался, ни один клиент не написал «вы мне так и не ответили» — потому что никто не замечает отсутствия письма, которого не ждал. В этом и опасность зависших запусков: они не шумят, они тихо копятся и всплывают потом внутри отчётов.

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

Что на самом деле происходит, когда сценарий «завис»?

У любой автоматизации два слоя: конструкция и запуск. Конструкция — это сценарий в том виде, в каком он лежит на канвасе: шаги, условия, ожидания. Запуск — одна копия этой конструкции, стартовавшая для одного человека. Запуск для Анны движется независимо от запуска для Сергея, у него собственная позиция в цепочке и собственный таймер ожидания. Когда говорят «сценарий завис», почти всегда имеют в виду, что перестали двигаться отдельные запуски, а не что сломалась конструкция.

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

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

Почему незавершённый запуск не безобиден

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

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

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

Где начинается зависание: шесть частых причин

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

• Неподключённый канал. В сценарии есть шаг WhatsApp, но подключение отвалилось или его не сделали вовсе. Шаг не может отправить, часто даже не выдаёт ошибку и стоит в очереди.
• Ожидание без потолка. Условие «ждать, пока клиент ответит» написано без верхней границы. Если ответа нет, запуск ждёт бесконечно.
• Внешняя система не отвечает. Вебхук вызван, на той стороне сбой или очень долгий ответ. Если таймаут не задан, шаг повисает.
• Согласование без хозяина. Шаг ожидания согласования есть, но согласующий в отпуске, ушёл из компании или не увидел уведомление.
• Условие ветвления, которое не выполняется. В связке if/else не прописана ветка «иначе», и при невыполнении условия запуску некуда идти.
• Нехватка данных. Шаг ждёт номер телефона, а в карточке его нет. Одни движки считают это ошибкой, другие просто держат запуск.

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

Когда считать запуск мёртвым?

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

Состояние запуска	Нормальная длительность	Порог «мёртвого»	Рекомендуемое действие
Плановый шаг ожидания	Как задано в шаге	Заданное время + 24 часа	Разбудить, затем пометить
Ожидание согласования	1-2 рабочих дня	3 рабочих дня	Эскалировать, затем закрыть
Ответ на внешний вызов	Секунды	15 минут	Повторить, затем пометить ошибкой
Шаг с ошибкой канала	-	3 неудачные попытки	Сообщить о канале, закрыть запуск
Общий срок жизни запуска	Зависит от конструкции	2 ожидаемых срока	Разобрать и в архив

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

Как написать правило очистки?

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

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

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

Раз в сутки — разумная частота очистки. Ежечасная добавляет лишний риск сценариям с длинными ожиданиями. Раз в неделю — слишком редко: удлиняется окно, в котором зависший запуск держит контакт заблокированным.

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

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

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

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

Удалить, повторить или закрыть?

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

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

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

Привычки проектирования, которые снимают зависания заранее

Уборка лечит симптом. Настоящий выигрыш — строить сценарии так, чтобы они не зависали. Хватает пяти привычек.

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

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

Как понять, что уборка работает?

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

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

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

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

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

Удаление зависшего запуска удалит и данные?

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

Через сколько дней считать запуск мёртвым?

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

Что делать, если я случайно оборву действительно живой сценарий?

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

Если менять только одно, чтобы избежать зависаний, — что именно?

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