Как проверить автоматизацию CRM перед запуском: чек-лист заказчика

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

Название «тестовая сделка» не отменяет действий роботов. Отладчик выполняет настроенные действия и сохраняет сведения об их ходе в журнал; если в карточке указан настоящий адрес клиента, название само по себе не превратит письмо в безопасный черновик.

Ниже — чек-лист приёмки для облачного Битрикс24: после обращения менеджер получает дело, адресату отправляется письмо, а при отсутствии следующего шага приходит внутреннее напоминание. Это выбранная конфигурация. Робот выполняет действие на стадии, а триггер отслеживает событие и перемещает карточку на нужную стадию — различие описано в справке платформы. Эти инструменты доступны не на всех тарифах. Заказчик принимает весь маршрут: кому пришло сообщение, какие сведения сохранились в карточке, что увидел сотрудник и когда ему предстоит продолжить работу, если клиент пока не ответил.

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

1. Тестовые данные и получатели подготовлены

Для нашего сценария понадобятся собственный почтовый адрес участника приёмки, тестовый контакт, назначенный сотрудник и понятный признак тестовой сделки, чтобы сообщения и дела можно было отличить от настоящей работы отдела. Получателей выбирают заранее. Если автоматизация обращается к внешнему сервису, исполнитель объясняет, куда уйдут данные и какие действия будут выполнены там. Одной отметки в названии карточки для этого мало. Участник, отвечающий за подключение, подтверждает тестовый режим или другой способ ограничить отправку, прежде чем специалист запускает цепочку в CRM.

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

• Получатели под контролем. В полях стоят адреса и контакты участников проверки. Настоящие клиентские данные не копируют без необходимости; для писем используется специально выбранный адрес.
• Зависимости перечислены. Видно, отправляет ли робот сообщение, создаёт документ, вызывает внешнее подключение или планирует дело другому сотруднику. Каждый получатель знает о тесте.
• Права проверяющего понятны. Штатный отладчик тестовой сделки запускается сотрудником с правом изменять настройки CRM. Это условие проверяет администратор, а заказчик участвует в оценке результата.
• Есть способ остановки. Исполнитель до начала показывает, как прервать ожидающие действия и что уже выполненное потребуется исправлять отдельно.

2. Для каждого робота записан ожидаемый результат

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

Я рекомендую таблицу «условие — действие — получатель — результат» вместо перечня включённых роботов. По такой таблице руководитель принимает настройку, даже если не умеет открывать её внутренние параметры.

• Условие запуска. Названа стадия и значения полей, при которых действие требуется. Если робот относится только к определённому направлению, это ограничение видно в описании.
• Состав результата. Для дела названы ответственный, содержание и срок; для письма — адресат, смысл сообщения и поля, которые подставляются из карточки.
• Ожидаемое бездействие. Описан случай, когда робот ничего не делает: направление другое, действие уже выполнено или обращение закрыто. Такой исход тоже принимается.
• Источник данных. Понятно, из какого поля берётся контакт, кто заполняет его и что произойдёт, если сведения отсутствуют.

3. Обычный путь проходит последовательно

В режиме отладки на тестовой сделке Битрикс24 создаёт карточку на первой стадии; затем её заполняют данными и последовательно перемещают по нужным стадиям, наблюдая действия и значения выбранных полей. Такой порядок описан в инструкции отладчика. Для нашего письма нужен адрес. Адрес и остальные нужные поля включают в тестовый набор до запуска, чтобы действие получило подготовленные для него данные.

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

• Переход на стадию. Карточка находится именно там, где запускается проверяемое действие. В отчёте сохраняются начальные условия, чтобы повторить этот же путь после исправления.
• Поля после выполнения. Значения не затёрты соседним роботом, ответственный соответствует правилу, содержание дела связано с текущим обращением.
• Сообщение у получателя. Проверено само письмо: адресат, текст, ссылка и подставленные сведения. Отметка об отправке и пригодность письма для читателя оцениваются отдельно.
• Завершение цепочки. Понятно, какое действие идёт следующим и не осталось ли неожиданного дела или сообщения в ожидании.

4. Пустые поля и неподходящие условия обработаны

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

Я бы принимал эти исключения вместе с основным маршрутом, а не откладывал их на первые настоящие обращения. Исправлять неверное письмо после отправки клиенту труднее, чем уточнить правило на тестовой записи.

• Нет адреса для письма. Робот не отправляет сообщение постороннему получателю. Сотрудник понимает, что требуется уточнить контакт или использовать другой принятый канал.
• Другое направление. Действие, предназначенное для одной группы обращений, не запускается на неподходящей карточке. Сопоставлены подходящий и неподходящий наборы данных.
• Изменился ответственный. Создаваемое дело и уведомление адресованы по выбранному правилу: текущему менеджеру либо назначенной роли. Исполнитель объясняет момент выбора получателя.
• Карточка закрыта. Для ожидающего напоминания заранее определено поведение после завершения работы. Заказчик видит, как избежать сообщения о действии, которое уже потеряло смысл.

5. Пауза, повторный вход и триггер проверены отдельно

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

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

• Ожидание без ускорения. Каждый используемый вариант отложенного действия испытан с реальным ожиданием. Эти результаты отделены от запусков с пропуском паузы.
• Изменение во время паузы. Перед выполнением изменено значимое поле тестовой карточки. Видно, какие данные использует действие и соответствует ли это принятому правилу.
• Повторный вход. Карточка возвращена на стадию. Проверены число созданных дел и отправленных писем, а также смысл повторения.
• Событие триггера. Выполнено нужное тестовое действие: изменение поля, переход по ссылке или другой выбранный сигнал. Проверяющий видит переход на ожидаемую стадию.

6. Остановка и исправление не скрывают прежние действия

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

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

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

Что оценить за пятнадцать минут

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

Пятнадцать минут — время предварительного разбора. Если реальная пауза в сценарии длится дольше, её результат появится позже, а незавершённый пункт останется открытым. До рабочего запуска команда получает перечень принятого, ограничения и имя ответственного за первые обращения; по этому списку руководитель видит, с чем сотрудники уже могут работать. Такой комплект можно включить в регламент CRM и обсудить со специалистом по автоматизации Битрикс24.