01 / Ситуация
Всё на месте, но не работает
После обновления менеджеры замечают мелочи: задача не создалась, письмо не ушло, поле не заполнилось. Настройки на месте — никто их не менял.
Проходит две недели, прежде чем становится понятно: сломалась не одна настройка, а несколько, и каждая по своей причине.
02 / Причина
Почему перестало
Поля и стадии изменились
Робот ссылается на конкретное поле или этап. Если их переименовали или заменили, условие перестаёт совпадать.
Права и интеграции обновились
Внешние сервисы и доступы тоже меняются. Робот, у которого нет прав, молча пропускает действие.
Автоматизация живёт, когда после каждого обновления её проверяют коротким сценарием, а не ждут жалоб.
03 / Подход
Проверка после
Список критичных действий
Письмо клиенту, задача менеджеру, смена стадии, документ. Пять-семь пунктов, которые проверяются всегда.
Тестовая сделка после обновления
Одна карточка проходит весь путь: от заявки до письма. Пятнадцать минут вместо двух недель жалоб.
Журнал, а не догадки
В карточке видно, запускалась ли автоматизация. Это точнее, чем «вроде работало».
04 / Нюансы
Что учесть
Обновления бывают и в облаке
Даже если сервер ваш, внешние сервисы и интерфейс меняются. Проверка нужна не только в коробке.
Не всё ломается сразу
Часть действий срабатывает, часть нет. Поэтому проверяют весь путь, а не одно звено.
Ответственный за проверку
Если проверяет «кто-нибудь», её не делает никто. Нужен человек и короткий чек-лист.
05 / Первый шаг
Один путь сделки
Пройдём по сделке от заявки до письма клиенту и посмотрим, какие действия должны срабатывать и какие сработали в последний раз.
- Какие роботы критичны для работы.
- Когда последний раз проверяли их после изменений.
- Кто увидит поломку первым.
По итогу соберём короткий чек-лист проверки после обновлений.