Что автоматика делает и чего не делает
Автоматизация выполняет уже существующее действие быстрее, чаще и без участия человека. Она не придумывает повод для обращения, не улучшает текст и не исправляет неверно выбранный сегмент. Всё, что было сломано до запуска, после запуска ломается на всей базе одновременно.
Отсюда следует порядок работ, обратный привычному. Сначала действие выполняется руками несколько десятков раз, чтобы стало ясно, какое условие его запускает, какие бывают исключения и что отвечает клиент. Только потом это описывается правилом. Обратный порядок — сначала настроить сценарий, потом посмотреть — даёт схемы, где половина ветвей не срабатывала ни разу, а вторая половина срабатывает не тогда.
Второе, чего автоматика не делает, — не создаёт данных. Сценарий, реагирующий на событие, существует ровно настолько, насколько надёжно это событие фиксируется. Если факт покупки попадает в систему через день после оплаты и не всегда, любой триггер по нему будет опаздывать и пропускать. Это делает CRM-систему не инструментом автоматизации, а её предпосылкой. Порог, за которым таблица перестаёт давать надёжные события, разобран в сравнении учёта в таблице и в системе: проходит он по числу людей, ведущих сделки одновременно, а не по числу строк.
Третье ограничение организационное. У каждого сценария есть срок годности: меняются цены, ассортимент, названия тарифов, состав команды. Работающая автоматика требует постоянного расхода на сопровождение, и этот расход не уменьшается. Поэтому вопрос «что автоматизировать первым» на практике означает «что мы готовы содержать годами».
Как считать очередь
Приоритет сценария определяется тремя величинами: как часто действие происходит, сколько стоит выполнить его руками и насколько устойчиво правило. Первые две перемножаются, третья работает делителем.
Пример с условными числами. Действие занимает четыре минуты и происходит триста раз в месяц — это двадцать часов ручной работы ежемесячно. Настройка сценария требует восьми часов и часа сопровождения в месяц. Выигрыш появляется в первый же месяц и дальше повторяется.
Второй случай: то же четырёхминутное действие, но десять раз в месяц — сорок минут. Настройка те же восемь часов. Формально окупаемость наступит примерно через год, фактически не наступит никогда: за год правило изменится, и восемь часов настройки потратятся снова.
Третья величина — устойчивость — часто перевешивает обе первые. Правило «отправить подтверждение после оплаты» не менялось с момента появления интернет-торговли. Правило «предложить товар из категории, которая сейчас в приоритете» меняется каждый сезон, и его автоматизация превращается в постоянную переделку. Формально частота у второго выше, отдача — ниже.
Практический вывод: очередь начинается не с самого заметного сценария, а с самого скучного и неизменного. Уведомления о статусе заказа выглядят менее интересно, чем персональные рекомендации, и приносят больше, потому что срабатывают всегда и не требуют переделки.
Очередь по убыванию отдачи
| Что автоматизируется | Что запускает | Что требуется от данных | Признак преждевременности |
|---|---|---|---|
| Фиксация событий и полей | Действие клиента или сделки | Единый идентификатор человека во всех источниках | Один клиент существует в системе трижды |
| Уведомления по сделке | Смена статуса заказа | Надёжный статус в реальном времени | Статус проставляется вручную и с задержкой |
| Реакция на первый результат | Событие первой ценности | Событие, отличимое от регистрации | Точка ценности не сформулирована |
| Возврат после паузы | Отсутствие покупок дольше своего интервала | История покупок за срок, больший интервала | Интервал взят из календаря, а не из данных |
| Сегментные рассылки | Расписание плюс признак сегмента | Заполненные признаки у большинства базы | Больше половины базы в категории «прочие» |
| Приоритет обращений | Набор признаков заявки | Связь заявки со сделкой и её исходом | Нет данных о том, чем закончились прошлые заявки |
| Персональные рекомендации | Состав прошлых покупок | Достаточная история и сгруппированные категории | Истории меньше, чем нужно для различения случайности |
Верхние три строки не относятся к маркетингу и потому регулярно пропускаются. Они же дают наибольшую отдачу: снимают нагрузку с людей, не требуют согласований и не вызывают отписок, потому что клиент ждёт этих сообщений.
Четвёртая строка — первая маркетинговая и первая, где легко ошибиться. Пауза считается от собственного интервала между покупками, а не от круглого числа дней; как его получить, разобрано в материале о повторных продажах, а сценарии реакции — в разборе удержания клиентов.
Пятая строка требует готовых признаков, и это условие проваливают чаще прочих. Автоматизация рассылки по сегментам, половина из которых пуста, отправляет письма в пустоту и создаёт ощущение работы; порядок построения признаков — в материале о сегментации.
Шестая и седьмая строки — работа с вероятностями, и обе требуют накопленной истории исходов. Механика приоритизации разобрана в материале о скоринге; без данных о том, чем закончились прошлые обращения, любая формула приоритета — это просто мнение, записанное числами.
Что должно быть готово до включения
Перед запуском любого сценария имеет смысл проверить четыре вещи, и все они про данные, а не про сервис рассылок.
Первое — идентификация. Один человек должен быть одной записью независимо от того, купил он через сайт, по телефону или в переписке. Пока это не так, сценарии дублируются: клиент получает приветственное письмо через месяц после третьей покупки.
Второе — события с временными метками. Сценарий срабатывает не по состоянию, а по факту перехода: покупка произошла, статус сменился, оплата не прошла. Состояние без метки времени не позволяет отличить «купил сегодня» от «купил год назад».
Третье — согласие на связь и канал по умолчанию. Автоматика масштабирует не только пользу, но и раздражение: письмо, отправленное вручную не тому человеку, — эпизод, а сценарий, отправляющий его всем, — репутационная проблема. Технические требования к отправке разобраны в материале о рассылках.
Четвёртое — источник обращения, доживший до сделки. Без сквозной разметки не получится ни оценить сценарий, ни отличить его результат от фонового; механика — в материалах о UTM-метках и сквозной аналитике.
Отдельно стоит завести правило приоритета между сценариями до того, как их станет больше трёх. Правило простое: транзакционное сообщение отменяет маркетинговое, редкий повод отменяет регулярный, общий лимит сообщений на человека за неделю ограничивает всё остальное. Вводить такое правило после того, как сценарии написаны, тяжело — придётся переделывать каждый.
Как автоматика ломается
Клиент получает три письма подряд от разных сценариев. Правило приоритета не задано, сценарии не знают друг о друге. Введите общий лимит сообщений на человека за период и порядок старшинства; проверять порядок нужно на реальных случаях из базы, а не на схеме.
Сценарий отправляет письмо о товаре, который клиент уже купил. Событие покупки попадает в систему позже, чем срабатывает триггер, либо покупка записана на другую запись того же человека. Проверьте задержку записи события и склейку дублей; до устранения задержки отложите срабатывание на срок, заведомо больший этой задержки.
Отклик на автоматические письма падает месяц за месяцем, тексты не менялись. Именно потому и падают: содержание устарело вместе с ассортиментом и ценами, а база успела получить его многократно. Назначьте каждому сценарию дату ревизии при запуске и проверяйте изменения параллельным сравнением версий, а не последовательным — механика в материале об A/B-тестах.
Никто не может сказать, сколько сценариев сейчас работает. Автоматика накапливалась без владельца и реестра. Составьте список всех активных сценариев с условием срабатывания, автором и датой последней проверки; всё, что не удалось объяснить за минуту, выключайте — работающий сценарий без объяснения опаснее выключенного.
Пятый способ сломать автоматику не даёт симптомов в отчётах: сценарии продолжают работать после ухода человека, который их настраивал. Формально всё в порядке, фактически изменения в них никто не вносит, потому что не знает, как устроены условия. Защита одна — описание сценариев хранится там же, где дашборд, и в том же виде, что и остальные регламенты.
Границы: что автоматизировать не нужно
Разбор нестандартных случаев. Автоматика хорошо обрабатывает большинство и плохо — хвост. Разумная схема: сценарий ведёт основную массу, а исключения падают человеку списком. Попытка описать правилами все ветви заканчивается схемой, которую нельзя ни проверить, ни изменить.
Решения с высокой ценой ошибки. Скидка, отказ, компенсация, повышение приоритета — там, где ошибка стоит дороже, чем сэкономленные минуты, автоматика должна готовить решение, а не принимать его. В переписке с клиентом граница проходит так же: пока минута оператора дороже вероятной потери от худшего ответа, отвечает автоматика, а вопросы о деньгах и перед покупкой уходят к людям, — когда бот уместнее оператора, разобрано отдельно.
Правила, меняющиеся чаще, чем раз в квартал. Сопровождение съедает выигрыш. Такое действие остаётся ручным сознательно, и это не признак отсталости, а расчёт.
Общение, требующее понимания контекста. Ответ на жалобу, разбор низкой оценки, возврат ушедшего крупного клиента — здесь автоматический текст читается как невнимание и ухудшает ситуацию по сравнению с молчанием. Что можно передать роботу в диалоге, а что нет, разобрано в материале о чат-ботах; какие вопросы после эпизода имеет смысл задавать автоматически, а какие лично, — в материале об оценке удовлетворённости.
Процесс, которого нет. Автоматизировать несуществующий порядок работы невозможно: сценарий вынужден изобрести его сам, и изобретает плохо. Сначала процесс выполняется руками и описывается, потом переводится в правило.
Спорное место
Правило «сначала скучное и неизменное» я считаю верным и вижу у него неприятное следствие.
Оно почти гарантирует, что компания застрянет на уведомлениях. Транзакционные сценарии окупаются быстро, работают надёжно и никогда не заканчиваются: всегда найдётся ещё одно статусное сообщение, которое стоит добавить. Пока команда обслуживает эту очередь, сценарии, требующие данных и терпения, не начинаются никогда — их отдача менее очевидна и наступает позже. Через год автоматизация выглядит образцово и не делает ничего, кроме подтверждений заказа.
Второе возражение против себя касается расчёта окупаемости. Я предлагаю считать выигрыш в сэкономленных часах, но сэкономленные часы редко превращаются во что-то измеримое — люди заполняют освободившееся время другой работой, и разницу в отчёте не видно. Честнее считать не экономию, а то, что стало возможно: обращение, которое раньше не отправлялось вовсе, потому что руки не доходили. Эта величина считается хуже, зато она реальна.
И третья слабость, самая практическая. Порядок «сначала данные, потом сценарии» логичен и почти неисполним в компании, где данные никогда не были в порядке: подготовка занимает месяцы, за которые не появляется ни одного видимого результата, и работу останавливают. Компромисс, который я готов защищать: запускать один простой сценарий с плохими данными сознательно, зафиксировав, что он даст неточный результат, — и использовать его сбои как список того, что чинить в данных. Это дороже правильного порядка и надёжнее, чем никогда не начать.
Частые вопросы
С какого сценария начинать, если ничего не автоматизировано?
Нужен ли отдельный сервис автоматизации или хватит CRM?
Как понять, что сценарий пора выключить?
Что делать, если клиент попадает сразу в несколько сценариев?
Сколько стоит поддержка автоматизации после запуска?