Роботы в CRM работают против вас: 5 ошибок автоматизации продаж

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

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

Условный сценарий: после выставления счёта система запланировала напоминание. За время ожидания клиент оплатил, менеджер сменился или заказ отменили. Если перед отправкой проверяется только первоначальный этап, клиент получает неуместное сообщение.

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

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

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

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

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

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

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

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

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