Автоматизация в CRM — это сценарии вида «событие — условие — действие»: система сама ставит задачу, меняет статус сделки, собирает документ по шаблону или отправляет уведомление, когда в работе что-то произошло. Начинают не со списка возможностей, а с одного процесса, потери в котором видны по отчёту. У Syntra Systems настройка сценариев в работающей CRM стоит от 2 000 $.
Коротко
Любой сценарий раскладывается на три части: событие, условие и действие. Пока эти три части не написаны словами, настраивать в интерфейсе нечего.
В готовых CRM эти части называются по-своему. В Bitrix24 робот срабатывает, когда элемент попадает на стадию, а триггер отслеживает действия клиентов и изменения в элементах; работают они не только в CRM, но и в задачах, подписи документов и цифровых рабочих местах — так это описано в документации вендора.
Четвёртая часть, о которой забывают, — что делать, если действие не удалось: письмо не ушло, обмен с 1С не прошёл, ответственный в отпуске. Без неё автоматизация ломается тихо, и узнают об этом в конце месяца.
Первыми автоматизируют действия, которые повторяются каждый день и чаще всего забываются: ответ на новую заявку, возврат к зависшей сделке, документы и напоминания. Зачем бизнесу автоматизация вообще и с чего начинать в масштабах компании — в статье об автоматизации бизнес-процессов.
| Событие | Что делает CRM | Кто получает | Что меняется в работе |
|---|---|---|---|
| Заявка с сайта или из Telegram | Создаёт сделку, фиксирует источник, назначает ответственного | Менеджер | Ни одно обращение не остаётся без владельца |
| Пропущенный звонок | Ставит задачу перезвонить со сроком | Менеджер | Возврат к клиенту не зависит от чужой памяти |
| Сделка не двигалась дольше норматива | Ставит задачу и уведомляет руководителя отдела | Менеджер и руководитель | Зависшие сделки видно до того, как клиент ушёл |
| Переход на этап подготовки предложения | Собирает коммерческое предложение по шаблону из полей карточки | Менеджер | Документ не собирают копированием из прошлого файла |
| Счёт выставлен | Напоминает об оплате по согласованному графику | Клиент | Меньше ручных напоминаний и неловких звонков |
| Оплата поступила | Меняет статус и передаёт заказ следующему подразделению | Производство или сервис | Исполнение начинается в день оплаты |
| Договор загружен в карточку | Запускает согласование по маршруту со сроками | Юрист, руководитель | Видно, у кого документ и сколько он там лежит |
| Работа завершена | Отправляет акт и просит оценить качество | Клиент | Обратную связь собирают сразу, а не через месяц |
| Прошло согласованное время после сделки | Ставит задачу на повторную продажу | Менеджер | Повторные продажи перестают зависеть от настроения |
Порядок важнее количества: три работающих сценария полезнее двадцати, про которые никто не помнит. Автоматизация переходов внутри самой сделки — отдельная тема, она разобрана в статье о воронке продаж в CRM.
Один сценарий редко работает в одиночку — обычно они выстраиваются в цепочку. Вот как это выглядит на обычной заявке.
Внутри цепочки нет ни одного действия, которое требовало бы от сотрудника помнить регламент. Люди принимают решения, а переносом данных и напоминаниями занимается система.
Автоматические сообщения ограничены правилами каналов и законом, и это проверяют до настройки, а не после первой жалобы.
| Канал | Когда система может написать сама | Что учесть |
|---|---|---|
| Telegram-бот | После того как клиент сам написал боту или добавил его в группу | Бот не может начать разговор первым — правило Telegram |
| WhatsApp Business | В течение 24 часов после сообщения или звонка клиента | После закрытия окна — только заранее утверждённые шаблоны, по документации платформы |
| SMS и звонки с рекламой | Только при предварительном согласии абонента | Статья 30 закона «О рекламе» ЗРУ-776 от 07.06.2022, текст на lex.uz |
Отсюда два практических правила. Согласие на сообщения собирают там же, где клиент оставляет контакты, и сохраняют в карточке вместе с датой. А сервисные уведомления — статус заказа, напоминание о визите, счёт — отделяют от рекламных рассылок: это разные сценарии с разными основаниями.
Ошибка Настроить рассылку по всей базе «потому что данные уже есть». База собиралась под сделки, а не под рекламу, и согласие на рекламные сообщения в ней обычно не зафиксировано. Проверьте основание до запуска сценария, а не после обращения абонента.
Большинство перечисленных сценариев собирается в готовой CRM без программирования — в конструкторе роботов и триггеров. Bitrix24 прямо предупреждает, что роботы и триггеры доступны не на всех тарифах, поэтому возможности сверяют с тем тарифом, который у вас оплачен.
Дорабатывать приходится в четырёх случаях:
Первые два случая закрываются интеграциями: что и как связывают с CRM, разобрано в статье об интеграциях CRM с другими системами. Два последних — признак того, что процессы переросли платформу; когда собственная разработка окупается, разобрано в статье о кастомной CRM.
Сценарии чаще отключают не из-за техники, а из-за того, что они мешают работать. Вот что ломает автоматизацию быстрее всего.
Результат автоматизации измеряют по тем же показателям, что и раньше, но снятым до запуска сценариев. Выберите три-четыре, которые отражают ваши потери.
Достаточно одного замера за две недели до запуска и такого же через месяц после. Если показатель не сдвинулся, сценарий либо не запускается, либо автоматизирует не то место.
Совет Начните с одного процесса и трёх сценариев, дайте им поработать месяц и только потом расширяйте список. Так проще понять, какое именно правило дало эффект, и проще откатить то, что мешает.
Если CRM уже работает, сценарии настраивают в ней: у Syntra Systems эта работа стоит от 2 000 $ и включает аудит настроек, порядок в воронке и полях, недостающие интеграции и отчёты — состав описан на странице CRM-систем.
Когда рутина выходит за пределы CRM — распознавание документов, перенос данных из писем и счетов, разбор звонков, сборка регулярных отчётов, — это уже отдельная задача: от 2 500 $. Если непонятно, с чего начинать, есть разбор процессов со схемой автоматизации и планом внедрения за 400 $; обе услуги описаны на странице ИИ и автоматизации.
Syntra Systems начинает с разбора: какие действия сотрудники повторяют каждый день, где обрывается процесс и какие данные переносят руками. Сценарии пишем словами и согласовываем до настройки — событие, условие, действие и поведение при сбое.
Дальше собираем их в вашей CRM, подключаем источники заявок и системы, которые участвуют в процессе, проверяем на реальных сделках и передаём команде правила ведения системы. Через месяц сверяем показатели, которые снимали до запуска, и убираем сценарии, которые мешают.
Обсудим вашу задачу
Расскажите, что нужно сделать, — оценим сроки и стоимость и предложим решение.
Робот срабатывает, когда сделка попадает на стадию: ставит задачу, отправляет сообщение, создаёт документ. Триггер следит за действиями клиента и изменениями в элементе — ответом, оплатой, полем — и сам переводит сделку на нужную стадию. Доступны они не на всех тарифах Bitrix24, поэтому возможности сверяют со своим.
Три на один процесс: например, распределение новых заявок, задача по зависшей сделке и коммерческое предложение по шаблону. Через месяц сверяют показатели, снятые до запуска, и только потом добавляют новые — так видно, какое правило дало эффект.
Она забирает действия, где решение человека не нужно: перенос данных, напоминания, смену статусов, документы по шаблону. Разговор с клиентом, работа с возражениями и нестандартные случаи остаются за менеджерами — у них просто освобождается на это время.
Сервисные сообщения — статус заказа, напоминание о визите, счёт — отправляют по контактным данным клиента. Для рекламных сообщений по сетям телекоммуникаций нужно предварительное согласие абонента, поэтому его собирают в форме заявки и хранят в карточке.
Разобрать, какой шаг мешает: обычно это лишнее обязательное поле, уведомление не тому человеку или правило, которое в компании уже изменилось, а в CRM осталось прежним. У каждого сценария должен быть ответственный, который его обновляет.
По задачам, которых не стало, и по сообщениям, которые не ушли. Поэтому в сценарий закладывают поведение при сбое: ошибка обмена или недоставленное сообщение попадают конкретному сотруднику в задачи, а не в журнал системы.
