Почему ломается автоматизация: ошибки и защита сценариев

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

Ломается не «сложная IT-система». Ломается сценарий, который умеет только счастливый путь: все сервисы ответили быстро и правильно. Ниже три опоры, без которых связку рано считать рабочей: явная обработка ошибок, защита от дублей при повторе и журнал, по которому можно восстановить историю.

Слова, которые стоит понимать владельцу

• Сценарий (автоматизация) - цепочка шагов: пришла заявка -> записали в CRM -> написали менеджеру. Может быть в Make, n8n, коде или внутри бота.
• Таймаут - внешний сервис не ответил за отведенное время. Вы не знаете, успел он сохранить данные или нет.
• Код 429 - «слишком много запросов, повторите позже».
• Код 500 - у сервиса внутренняя ошибка. Повторить можно, но не вслепую.
• Идемпотентность - повтор того же действия не создает второй объект. Одна заявка останется одной сделкой, даже если сценарий запустился дважды.
• Журнал событий - хронология: что пришло, что отправили, что ответили, где остановились. Не переписка в чате «у кого-то упало».

Почему сценарий падает «молча»

Типичная настройка: если CRM ответила «ок», идем дальше. Если нет, шаг просто красный в интерфейсе автоматизации, и никто не смотрит туда днями.

• Форма показывает успех, потому что сайт принял данные, а до CRM шаг не дошел.
• CRM приняла сделку, а уведомление менеджеру упало. Клиент ждет, команда не знает.
• Ночной сбой API, утром 15 «зависших» заявок без владельца.
• Ответ «успех», но тело ответа битое. Следующий шаг пишет пустые поля.

Минимум защиты: при любой ошибке сценарий пишет событие в журнал и шлет короткое алерт-сообщение ответственному. В алерте: имя сценария, id заявки, шаг, текст ошибки. Без этого вы чините по ощущениям.

Повтор запроса без второй сделки

После таймаута нельзя быть уверенным, что CRM ничего не записала. Если просто «нажать еще раз», легко получить две сделки, два сообщения клиенту или два списания.

Решение для владельца звучит просто: у каждой заявки есть стабильный ключ. Например, lead-20260722-8421 или id из формы. Перед созданием сделки сценарий спрашивает CRM: «сделка с таким ключом уже есть?» Если да, обновляет ее или идет дальше. Если нет, создает одну.

• Ключ один на жизненный цикл заявки, не новый при каждом рестарте.
• Повтор использует тот же ключ.
• Сообщение клиенту тоже завязано на ключ: «уже отправляли» -> не слать второй раз.
• Ручное восстановление менеджером тоже идет через тот же ключ, а не «создам новую, так быстрее».

Какой журнал событий достаточен

Не нужна дорогая система мониторинга с первого дня. Нужна лента, где за 30 секунд видно судьбу заявки.

Пример (учебный, не лог клиента)

10:14:03 | lead-8421 | заявка принята | key=lead-8421
10:14:05 | lead-8421 | CRM create | попытка 1 | timeout
10:14:07 | lead-8421 | CRM create | попытка 2 | 429, ждем
10:15:07 | lead-8421 | CRM create | попытка 3 | 500, стоп
10:15:08 | lead-8421 | алерт менеджеру | payload сохранен

• Один id связывает вход, попытки, результат и алерт.
• Храните исходные данные заявки (payload), чтобы повторить шаг руками.
• Не пишите в открытый чат полные паспортные данные без нужды. Журнал тоже место с доступом по ролям.
• Срок хранения согласуйте: достаточно, чтобы разобрать спор «куда делась заявка».

Чек-лист до запуска в боевой режим

• Смоделирован таймаут CRM: сценарий не «теряет» заявку молча.
• Смоделирован 429: есть пауза и повтор, не бесконечный цикл.
• Смоделирован 500: после N попыток стоп + алерт человеку.
• Битый ответ не проходит в следующие шаги как нормальные данные.
• Повторный запуск с тем же ключом не создает вторую сделку.
• Тестовая заявка с сайта доходит end-to-end и находится в журнале.
• Назначен человек, который чинит остановленные операции в рабочее время.
• Есть короткая инструкция: как найти заявку по ключу и что нажать.

Чек-лист раз в неделю после запуска

• Сколько ошибок за 7 дней и на каких шагах.
• Сколько алертов без реакции дольше X часов.
• Есть ли дубли сделок с похожими телефонами/ключами.
• Совпадает ли число заявок с сайта, в журнале и в CRM (с допуском на ручные).
• Не истекли ли ключи API и не сменились ли права доступа.

Что попросить у подрядчика простыми словами

1) Где смотреть журнал по id заявки?
2) Что происходит при timeout / 429 / 500?
3) Какой ключ защищает от дублей и где он хранится?
4) Кто получает алерт и что он должен сделать за 15 минут?
5) Как я сам найду «потерянную» заявку без разработчика?
6) Что не покрыто автоматизацией и остается ручным регламентом?

Когда автоматизацию лучше упростить, а не «усложнить защитой»

• Заявок мало, менеджер и так отвечает за минуты. Сначала регламент, потом бот.
• CRM меняется каждый месяц. Сначала стабилизируйте процесс продаж.
• Нет человека, который будет смотреть алерты. Автоматизация без дежурного = тихий долг.
• Хотите «чтобы ИИ сам все решал» без правил передачи человеку. Так растет цена ошибки.

Пример ручного восстановления без дубля

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

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