Автоматизация и бизнес-процессы

Автоматизация в CRM нужна, чтобы повторяемая работа выполнялась одинаково и без ручного контроля: новая заявка сразу получает ответственного, при переходе на этап ставится нужная задача, клиент получает письмо по шаблону, а перед закрытием проверяются обязательные условия. Хорошая автоматизация ускоряет процесс и делает его предсказуемым; плохая — тихо меняет данные так, что команда перестает понимать, что произошло.

Автоматизацией управляют в разделе автоматизации CRM (/crm/automation). Это работа администратора процесса, а не повседневное действие менеджера.

примечание

CRM-автоматизация работает не только с продажами: выбранная воронка может обслуживать коммерческие сделки или сервисные обращения. В безопасных примерах используйте Delivery window — demo для сервисного запроса и Rebranding — demo для коммерческой сделки; не используйте реальные записи, идентификаторы или суммы и не выполняйте изменения данных.

Из чего состоит автоматизация

В CRM есть несколько инструментов, и важно не путать их назначение:

• Правила-роботы срабатывают после события (создана сделка, изменился этап, изменилось поле) и выполняют действия.
• Защитные проверки срабатывают до операции и не дают ее завершить, пока не выполнено условие.
• Бизнес-процессы описывают многошаговый сценарий с условиями, ожиданиями и заданиями для людей.
• Шаблоны писем хранят текст внешних сообщений, которые отправляют роботы и процессы.

Правила-роботы

Правило отвечает на вопрос «что система делает после события».

• Событие (триггер): создание сделки, вход в этап, изменение поля, ручной запуск, а также события обмена документами (см. ниже).
• Если список триггеров показывает коды вместо понятных названий, не включайте правило вслепую. Сверьте смысл события с владельцем процесса и дождитесь ясной локализованной подписи.
• Условия: при каких значениях правило срабатывает; условия можно объединять по «и»/«или».
• Действия: цепочка шагов — назначить ответственного, перевести на этап, изменить поле, поставить задачу, отправить уведомление, отправить письмо клиенту, запустить процесс и другие.
• Если действие использует сумму или валюту, проверьте валюту сделки и ожидаемый результат отдельно. Перед включением убедитесь, что правило работает с теми денежными данными и форматом, которые видит команда.
• Ветвление: «если — иначе» внутри правила для разных случаев.
• Расписание шага: сразу, с задержкой или в точное время.
• Политика ошибок: продолжать или останавливать цепочку при сбое шага.

У каждого правила есть область действия (вся компания, воронка или этап) и приоритет. Чем шире область, тем внимательнее нужно проверять правило перед включением. Доступ к CRM сам по себе не гарантирует доступа к автоматизации в выбранной воронке или на этапе. При закрытой делегированной области экран показывает причину отказа и не загружает список правил — это не пустой список. Проверьте выбранную воронку и этап и запросите scoped-доступ у владельца политики.

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

Триггеры обмена документами

Концептуальный поток триггеров обмена документами; это не UI-скриншот и не доказательство данных портала.

Если в портале подключён обмен документами, правилам доступны отдельные события этого потока:

• Контрагент связан (документооборот) — входящий документ сопоставлен с клиентом в CRM;
• Файлы документооборота импортированы — документы и подписанные копии загружены на сторону портала;
• Документ завершён (документооборот) — обмен по документу дошёл до финального состояния;
• Ошибка импорта документооборота — загрузка не удалась.

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

Защитные проверки

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

Защитная проверка — это не бюрократия, а защита результата: она не дает закрыть сделку без причины или перевести ее на этап без нужных данных.

Что важно знать при настройке:

• Блокировка показывает все причины сразу. Если операция нарушает несколько проверок, пользователь увидит их одним списком, каждую отдельной строкой. Пишите сообщения так, чтобы они читались в списке рядом друг с другом: коротко, по делу, без общих формулировок вроде «нельзя».
• Сообщение должно называть исправление, а не запрет: «заполните причину закрытия», а не «переход запрещён».
• Форма прокручивается к проблемному полю и подсвечивает его, когда проверка указывает на конкретное поле. Привязывайте проверку к полю, если это возможно, — так пользователь находит место исправления сразу.
• Известное исключение — причина закрытия: подсветка на неё не наводит. Если ваша проверка требует причину закрытия, напишите в сообщении, где её заполнить.

Шаблоны писем

Шаблоны писем хранят повторяющиеся внешние сообщения клиенту. Активный шаблон становится доступен для действия «Письмо клиенту» в правилах и процессах. В шаблон можно подставлять данные сделки и клиента, поэтому одно письмо работает для многих ситуаций.

Проверяйте подстановку на выбранном синтетическом CRM-обращении, а не на живой записи: предпросмотр требует ID выбранного синтетического CRM-объекта и его контекст. Используйте Delivery window — demo для сервисного запроса или Rebranding — demo для коммерческой сделки; не вносите изменения в данные:

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

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

Бизнес-процессы

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

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

Что важно для контроля

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

Как разобрать запуск правила

Когда правило сработало не так, как ожидали, не отключайте его сразу — сначала прочитайте историю запусков. Она показывает, что именно произошло, и экономит часы догадок.

В истории по каждому запуску видно:

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

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

Порядок разбора:

1. Найдите нужный запуск по сделке и времени.
2. Посмотрите, дошла ли цепочка до конца или остановилась на шаге.
3. Если шаг с ошибкой — прочитайте причину: чаще это недостающие данные, права или недоступный адресат.
4. Исправьте причину (данные, права, шаблон, область действия) и при необходимости запустите правило вручную повторно.
5. Если правило срабатывает слишком часто или не там — сузьте условие и область действия, а не отключайте автоматизацию целиком.

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

Состояния, которые можно увидеть

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

примечание

Часть экранов автоматизации и бизнес-процессов сейчас локализована не для всех языков интерфейса. Это известное ограничение продукта: перед демонстрацией проверьте, что названия действий и сообщений понятны вашей команде.

Хорошие практики

• Давайте правилам и процессам понятные названия и владельца.
• Проверяйте предполагаемый результат и тестируйте перед включением.
• Не позволяйте автоматизации скрыто менять ответственного, срок или статус.
• Делайте сообщения защитных проверок понятными: что исправить, а не просто «нельзя», и помните, что они могут показаться списком сразу с другими.
• Проверяйте подстановку в шаблоне через предпросмотр до включения правила.
• Регулярно пересматривайте правила и отключайте лишние.

Частые ошибки

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

Скрыто менять ответственного или срок автоматизацией. Команда теряет понимание, кто и за что отвечает.

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

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

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

Запустить процесс без тестового прогона. Он идет по неожиданному пути, и разбирать последствия дороже, чем проверить заранее.

Как проверить результат

• у правила понятны название, область, условие, действия и владелец;
• история запусков подтверждает, что правило сделало ожидаемое;
• защитная проверка блокирует только то, что должна, и объясняет исправление;
• предпросмотр шаблона показывает готовый текст без ошибок подстановки и пустых мест;
• бизнес-процесс прошел тестовый прогон и идет по ожидаемому пути.

Связанные сценарии

Концептуальная карта связанных сценариев; это не UI-скриншот и не доказательство данных портала.

• CRM: обзор
• Воронки и этапы
• Сделки и обращения
• Задачи
• Рабочие процессы
• Автоматизация