Как проверить, какие автоматизации запускаются при смене статуса сделки?

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

На что смотреть при проверке автоматики сделки

• Какой именно переход статуса запускает правило.
• Какие фильтры и исключения ограничивают его действие.
• Какие операции выполняются и в каком порядке.
• Совпадают ли настройки с записями в журнале и истории сделки.
• Не вызовет ли тест повторный запуск или внешнее действие.

Уточните, какой переход статуса запускает автоматизацию

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

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

Найдите правила и сценарии, привязанные к сделке

Названия разделов зависят от CRM: настройки могут находиться в карточке воронки, правилах этапа, разделе автоматизаций или сценариях. При проверке автоматизации продаж в CRM ищите не только название робота, но и условие запуска, связанное с изменением этапа сделки.

• Получите доступ к настройкам нужной воронки и правил автоматизации; для просмотра журнала может потребоваться отдельное разрешение.
• Подготовьте идентификатор сделки, название воронки и точное время предполагаемого срабатывания.
• Уточните, есть ли тестовая среда или тестовая сделка с данными, не связанными с реальным клиентом.
• Если планируете тест, выясните, можно ли отключить внешние действия или использовать безопасный получатель уведомлений.

При настройке автоматизации в CRM права на просмотр могут отличаться от прав на редактирование. Для первичной диагностики достаточно чтения настроек и истории; не меняйте правила, пока не выясните причину поведения.

Проверьте условия запуска, фильтры и исключения

До теста оцените возможные последствия. Автоматизация сделок в CRM может менять поля, назначать ответственного, создавать задачи или отправлять сообщения — конкретный набор зависит от конфигурации.

• Переход может запустить несколько правил одновременно.
• Действие может повлиять на клиента или сотрудника вне CRM, например через почту или интеграцию.
• Повторное изменение статуса способно повторно запустить сценарий, если в правиле нет ограничения от дублей.
• Изменение условий ради теста может затронуть другие сделки в той же воронке.

1. Откройте настройки нужной воронки. Найдите список правил, связанных с этапами, и выберите правило, совпадающее с предполагаемым переходом. Если названия этапов похожи, сверьте идентификатор или описание воронки.
2. Сверьте исходный и целевой статусы. Уточните, запускается ли сценарий при входе на этап, выходе с него или при любом изменении статуса. Это помогает отличить нужное событие от соседнего перехода.
3. Прочитайте все условия и фильтры. Проверьте значения полей, ответственного, источник сделки и другие ограничения, если они указаны. Отдельно найдите исключения: например, запрет повторного выполнения или условие, которое должно оставаться истинным в момент запуска.
4. Просмотрите каждое действие правила. Запишите операции в порядке выполнения: изменение поля, создание задачи, назначение сотрудника, уведомление или вызов интеграции. Учитывайте и действия, которые запускают следующий сценарий.
5. Проверьте активность и область действия. Убедитесь, что правило включено и относится к нужной воронке, группе сделок или этапу. Если правило отключено или его область уже, чем ожидается, оно может не сработать для проверяемой записи.
6. Найдите связанные сценарии. Проверьте, не запускает ли результат первого действия другое правило. Так можно восстановить цепочку автоматизации воронки продаж, а не только действия одного робота.

При проверке триггеров и роботов в CRM различайте условие запуска и действие: первое определяет, когда сценарий срабатывает, второе — что происходит после срабатывания.

Проследите цепочку действий после смены статуса

Сопоставьте ожидаемую последовательность из настроек с фактическим состоянием сделки после события. Отмечайте выполненные действия и те, для которых пока нет подтверждения.

• Статус сделки изменился на ожидаемый.
• Проверяемая запись соответствует фильтрам правила.
• В карточке появились ожидаемые изменения полей или ответственного.
• Создались задачи или другие внутренние записи, если они предусмотрены сценарием.
• Уведомления и сообщения направлены по заданному маршруту.
• Связанные сценарии запустились в ожидаемом порядке.
• Повторные действия не создали дубли.

Сверьте срабатывания с журналом событий и историей сделки

Настройки показывают, что должно произойти, а журнал и история — что CRM зафиксировала фактически. Если время или названия событий отображаются по-разному, ориентируйтесь на детали записи и сведения о выполненном действии.

• Ищите событие по сделке и времени перехода, а не только по названию правила.
• Учитывайте задержку между сменой статуса и выполнением действия, если она задана в сценарии.
• Сверьте пользователя или источник изменения статуса: переход мог произойти через интеграцию или импорт.
• Проверьте, не отменило ли условие запуск изменение поля или ответственного.
• Убедитесь, что в журнале отображается именно нужная воронка и запись.
• Не считайте отсутствие события доказательством сбоя, пока не проверили фильтры, права доступа и доступность журнала.

Проведите безопасный тест и исключите повторные запуски

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

1. Тестовая сделка. Используйте запись без реального клиента и проверьте, что она попадает под те же условия. Этот вариант подходит, если тестовые записи не запускают внешние сообщения.
2. Тестовая среда или копия воронки. Проверьте цепочку отдельно от рабочих сделок. Выбирайте этот подход, если правила зависят от полей и связанных сценариев.
3. Проверка по журналу без повторного перехода. Найдите уже произошедшее событие и сопоставьте его с настройками. Это уместно, если повторный запуск может создать задачу, сообщение или дублирующую запись.
4. Согласованный контролируемый тест. Если другие варианты недоступны, заранее согласуйте запись, время и последствия с ответственным за CRM. До теста проверьте возможность отключить внешние действия и зафиксируйте исходные значения статуса и полей.

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

Что может помешать обнаружить запуск автоматизации

Почему правило не видно в настройках сделки?

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

Почему статус изменился, но действие не выполнилось?

Сделка могла не соответствовать фильтрам или исключениям, либо правило было выключено. Проверьте условие запуска и область действия правила.

Почему в журнале нет записи о событии?

Журнал может быть недоступен для вашей роли, показывать только часть событий или не содержать нужный временной диапазон. Сверьте историю сделки и запросите проверку у администратора.

Может ли действие выполниться с задержкой?

Да, если в сценарии настроено отложенное выполнение. Проверьте параметры правила и сопоставьте время события с временем выполнения действия.

Как проверить сценарий, который отправляет сообщение клиенту?

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

Что делать, если после проверки появились дубли?

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