Ошибки в no-code автоматизации и как их избежать
Практика4 минРедакция Innovialabs
Коротко
Большинство сбоев no-code автоматизаций — не баги платформы, а отсутствие базовой гигиены: оповещений об ошибках, защиты от дублей, общих рабочих аккаунтов, документации и контроля расхода; всё это настраивается за час и экономит недели разбирательств.
Коротко: почему автоматизации ломаются
No-code сценарий легко собрать за вечер, и так же легко забыть о нём до первого сбоя. Почти все проблемы сводятся к шести ошибкам ниже. У каждой есть простое исправление.
1. Нет обработки ошибок
Что происходит: API сервиса временно недоступен, сценарий падает, а заявка теряется. Никто об этом не знает, пока клиент не позвонит сам.
Как исправить:
- Включите уведомления об ошибках на платформе и направьте их в рабочий канал, а не на личную почту одного человека.
- Для ненадёжных шагов настройте повторные попытки: в Make — обработчик Break, в n8n — Retry On Fail и отдельный Error Workflow, в Zapier — автоматический повтор, если он доступен на тарифе.
- Добавьте запасной путь: если CRM не ответила, запишите данные хотя бы в таблицу.
2. Дубли запусков
Что происходит: клиент дважды нажал «Отправить», сервис повторно прислал вебхук или сценарий перезапустили вручную — и в CRM две одинаковые сделки, а менеджеры звонят одному клиенту дважды.
Как исправить:
- Перед созданием записи ищите существующую по уникальному ключу: email, телефон, ID заказа.
- Нормализуйте ключ перед сравнением: телефон к одному формату, email в нижний регистр.
- Храните ID уже обработанных событий (в таблице или хранилище данных платформы) и пропускайте повторы.
3. Жёстко прописанные значения
Что происходит: ID таблицы, имя ответственного, ссылка на чат вписаны прямо в шаги. Сотрудник ушёл, таблицу переименовали — сценарий пишет в пустоту или назначает заявки уволенному.
Как исправить:
- Выносите изменяемые значения в одно место: отдельный лист настроек, хранилище данных или переменные платформы.
- Распределение по менеджерам берите из справочника, а не из условий внутри сценария.
4. Нет документации
Что происходит: автор сценария в отпуске, что-то сломалось, и никто не понимает, что делает «Zap 7 копия (2)».
Как исправить:
- Понятные названия: «Сайт → CRM + Telegram: новые заявки».
- Заметки на шагах: зачем здесь фильтр, откуда берётся значение.
- Реестр автоматизаций — простая таблица:
| Поле | Пример |
|---|---|
| Название | Заявки с сайта в CRM |
| Триггер | Вебхук формы на сайте |
| Что делает | Создаёт сделку, уведомляет отдел продаж |
| Аккаунты | Общий аккаунт отдела продаж |
| Владелец | Ответственный сотрудник |
| Что делать при сбое | Проверить историю, перезапустить, сообщить владельцу |
5. Общие личные аккаунты
Что происходит: интеграции подключены через личный Google или пароль от одного логина знает вся команда. Человек уходит — доступы отзываются, и половина автоматизаций останавливается. Плюс невозможно понять, кто что изменил.
Как исправить:
- Подключайте сервисы через служебные или общие рабочие аккаунты, которыми владеет компания.
- Давайте сотрудникам личные доступы к платформе с нужными ролями вместо одного общего пароля.
- Включите двухфакторную аутентификацию.
- Проверяйте, у кого есть доступ, при каждом увольнении.
6. Неконтролируемый расход задач
Что происходит: сценарий зациклился (обновление строки снова запускает тот же сценарий), итератор умножил операции, или проверка по расписанию раз в минуту тратит лимит на пустые запуски. Итог — исчерпанный лимит в середине месяца или неожиданный счёт.
Как исправить:
- Фильтры в начале сценария, а не в конце.
- Не допускайте петель: сценарий не должен реагировать на изменения, которые сам же и сделал. Помечайте такие записи и отфильтровывайте их.
- Подбирайте интервал опроса под реальную частоту событий или переходите на вебхуки.
- Настройте оповещения о расходе и раз в неделю смотрите, какие сценарии тратят больше всего.
Чек-лист перед запуском
- Сценарий протестирован на реальных данных, включая пустые поля.
- Ошибки приходят в рабочий канал.
- Есть защита от дублей.
- Изменяемые значения вынесены в настройки.
- Подключены рабочие, а не личные аккаунты.
- Сценарий записан в реестр с владельцем.
- Понятно, сколько задач или операций он тратит в месяц.