# Матрица триггерных коммуникаций: как разработать документ, который наводит порядок в сценариях

> Клиент получает три триггера за вечер, а промокоды съедают маржу? Разбираем, как собрать матрицу событий, приоритетов и каналов, чтобы сценарии не мешали друг другу.

**Рубрика:** Статьи  
**Автор:** Валерия Старостина, CRM-маркетолог, ClientCore  
**Дата:** 2026-10-28

Обычная картина в компании, где CRM работает пару лет: в Mindbox 40–60 активных сценариев. Одни запускал прошлый маркетолог, другие — подрядчик, третьи появились к распродаже и так и остались. Никто точно не знает, сколько сообщений получает клиент за неделю. Зато все знают, что отписок стало больше, триггерная выручка не растет, а промокод из реактивации получил человек, который купил вчера.

Каждый отдельный сценарий при этом выглядит нормально: письмо красивое, условие запуска логичное, конверсия в отчете есть. Ломается стык между сценариями — там, где они встречаются на одном клиенте. Этот стык и закрывает матрица триггерных коммуникаций. Как ее собирать, на чем обычно спотыкаются и что должно быть в документе, рассказывает Валерия Старостина, CRM-маркетолог ClientCore. Она разбирала такие системы на десятках проектов.

> **Читайте также:** [Разработка карты коммуникаций: как выглядит рабочий план CRM-коммуникаций](https://clientcore.ru/blog/articles/razrabotka-karty-kommunikaciy-kak-vyglyadit-rabochiy-plan-crm-kommunikaciy)

## Как сценарии начинают воевать за одного клиента

Конфликт почти никогда не закладывают специально, он накапливается постепенно. Сначала запускают welcome-цепочку. Через полгода добавляют брошенную корзину. Потом — брошенный просмотр, день рождения, реактивацию через 60 дней, напоминание о бонусах, которые скоро сгорят. Каждый сценарий тестировали в одиночку, поэтому на тесте все работало.

В жизни новый клиент регистрируется, кладет товар в корзину и уходит. Вечером ему приходят второе письмо welcome-цепочки, напоминание о корзине с промокодом на 10% и пуш о брошенном просмотре. Через неделю он покупает без скидки, а на следующий день получает реактивацию с промокодом на 15%: сегмент «неактивные» собрали по дате последнего открытия письма, и на покупки никто не смотрел.

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

> На одном аудите мы выгрузили историю коммуникаций по случайной сотне клиентов. У 17 человек в какой-то из дней было пять и больше сообщений из разных сценариев. Двое за одну неделю получили промокоды из трех цепочек, и все три были разного номинала. Команда об этом не знала: в интерфейсе каждый сценарий показывал приличную конверсию».
>
> — Валерия Старостина, CRM-маркетолог, ClientCore

## Что лежит внутри рабочей матрицы

Матрица — это таблица, где каждая строка описывает один сценарий, а столбцы задают правила его поведения в общей системе. Формат может быть любым: Google Sheets, Notion, Miro. Главное, чтобы документ был один и все, кто трогает CRM, сверялись с ним до запуска нового сценария.

Минимальный набор столбцов выглядит так:

| Поле | Что фиксируем |
|---|---|
| Событие-триггер | Что запускает сценарий: регистрация, корзина, просмотр, покупка, дата |
| Условия входа | Кто попадает: сегмент, статус лояльности, наличие согласий |
| Условия выхода | Что останавливает цепочку: покупка, отписка, вход в сценарий выше по приоритету |
| Приоритет | Место в иерархии от 1 до N |
| Взаимоисключения | С какими сценариями не может идти одновременно |
| Каналы и каскад | Email, push, SMS, мессенджер, порядок фолбэков |
| Тайминги | Задержки между шагами, допустимые часы отправки |
| Оффер | Есть ли скидка, ее размер, срок действия |
| KPI и контроль | Целевая метрика, наличие контрольной группы |
| Владелец | Кто отвечает за сценарий и вносит правки |

Чаще всего забывают столбец «Условия выхода». Входы прописывают тщательно, а про выход думают в последнюю очередь, хотя именно незакрытый выход дает те самые письма о корзине через два дня после покупки.

Еще один полезный столбец — «Оффер». Когда скидки всех сценариев собраны в одну колонку, сразу видно, что брошенная корзина дает 10%, реактивация 15%, а день рождения 20%. Внимательный клиент быстро поймет, что выгоднее всего пропасть на два месяца и дождаться реактивации.

## Приоритеты: кто выходит в эфир, когда событий несколько

Без приоритетов любой конфликт решается случайно: побеждает сценарий, который сработал первым или просто стоит выше в списке системы. Иерархия в матрице убирает эту случайность. Шкала, которой мы обычно пользуемся на старте:

1. Транзакционные и сервисные сообщения: подтверждение заказа, статус доставки, сброс пароля. Они идут всегда и не учитываются в лимите частоты. 2. Сценарии с высоким намерением: брошенная корзина, брошенный чекаут, товар снова в наличии. 3. Событийные сценарии вокруг покупки: допродажа, просьба об отзыве, напоминание о повторной покупке расходника. 4. Жизненный цикл: welcome, день рождения, повышение уровня лояльности. 5. Промо и реактивация.

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

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

**Норма**

- у каждого сценария есть номер приоритета, и он записан в матрице
- транзакционные письма вынесены за рамки лимита частоты
- лимит считается по всем каналам вместе, без раздельных квот на email и push
- при конфликте сценарий с меньшим приоритетом ставится на паузу или пропускает шаг

**Red flag**

- приоритеты «и так понятны», но нигде не записаны
- лимит частоты стоит только на email, а пуши и SMS уходят без ограничений
- массовая промо-рассылка вытесняет брошенную корзину, потому что ее отправили раньше
- в спорных случаях решение принимает тот, кто настраивал сценарий

## Взаимоисключения и карантины

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

Удобнее всего рисовать это отдельной квадратной матрицей «сценарий × сценарий». На пересечении ставится одна из пометок: «совместимы», «исключают друг друга» или «Б ждет завершения А». Для 30 сценариев это 900 ячеек, но заполняются они быстро, потому что большая часть пар совместима. Спорных обычно набирается 40–60, и обсуждать с командой нужно именно их.

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

> В Mindbox взаимоисключения технически собираются через сегменты-исключения и ограничения частоты. Беда в том, что без матрицы их настраивают точечно, на глаз. Мы как-то нашли сценарий, исключавший клиентов „из реактивации“, только сегмент реактивации к тому времени уже пересобрали под другим названием. Правило полгода ничего не исключало, а в интерфейсе выглядело рабочим. Если правило записано в матрице, при переименовании сегмента такую ссылку видно сразу.
>
> — Валерия Старостина, CRM-маркетолог, ClientCore

## Каналы и каскады: куда отправлять и что делать, если не дошло

Каналы в матрице описываются для каждого шага сценария. Кроме выбора канала нужен порядок фолбэков: что происходит, если основной канал недоступен или сообщение не открыли. Классический каскад — push, через несколько часов email, если пуш не открыт, и SMS только для высокоценных событий, потому что SMS стоит денег за каждую отправку.

Каскад сильно влияет на экономику. Брошенная корзина на крупную сумму оправдывает SMS-фолбэк. Напоминание о бонусах на 50 рублей — нет. Поэтому в матрице рядом с каналами полезно держать примерную стоимость контакта и средний чек события, тогда решение о фолбэке принимается по цифрам.

Мы это проверяли на практике. В «Браво-Оптике» до проекта коммуникации шли нерегулярно и по разным каналам: SMS, WhatsApp, редкие массовые письма. Мы внедрили Mindbox, запустили email и выстроили каскадные цепочки — в итоге выручка CRM-направления выросла на 14,62% за 10 месяцев ([кейс](https://clientcore.ru/blog/articles/keis-bravo-optika-rost-vyruchki-crm)). По нашей оценке, заметная часть результата связана с тем, что каналы перестали работать каждый сам по себе и начали подхватывать друг друга по заранее описанным правилам.

**Норма**

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

**Red flag**

- одно и то же сообщение уходит параллельно во все каналы «для надежности»
- SMS стоит фолбэком во всех сценариях подряд
- пуши приходят в три часа ночи клиентам из Владивостока
- никто не знает, во сколько обходится один сценарий в месяц

## Как идет разработка матрицы: шаги и сроки

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

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

Потом идут приоритеты, взаимоисключения, каналы и офферы, а после согласования с командой — перенос правил в настройки CRM и запуск контрольных групп. На проекте среднего размера (30–50 сценариев) аудит и черновик занимают две-три недели, согласование — еще неделю, внедрение правил зависит от того, сколько сценариев нужно пересобрать.

> Сложнее всего дается согласование, техническая настройка идет быстрее. Когда на одной странице видно, что промо-отдел, продуктовая команда и поддержка шлют клиенту что-то свое, начинается разговор про приоритеты, который раньше откладывали годами. Хорошо, если матрица его запускает: в итоге она превращается в план работ по CRM-маркетингу на квартал, где понятно, что выключаем, что чиним и что запускаем».
>
> — Валерия Старостина, CRM-маркетолог, ClientCore

Похожую задачу мы решали для «Галереи»: собрали разрозненные CRM-коммуникации в единую систему и перевели их в Mindbox ([отзыв клиента](https://clientcore.ru/blog/articles/otzyv-galereya-o-clientcore-crm-kommunikacii)). Без общей матрицы такой переезд превращается в перенос хаоса на новую платформу.

## Как сделать, чтобы матрица не устарела через месяц

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

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

**Норма**

- у матрицы есть владелец и история версий
- новые сценарии проходят через документ до запуска
- у ключевых сценариев есть контрольная группа на 5–10% аудитории
- ревизия раз в квартал с решениями: оставить, переделать, выключить

**Red flag**

- последняя правка в документе была год назад
- сценарии к акциям запускаются «на две недели» и живут годами
- эффективность оценивается только по last click без контрольных групп
- в команде несколько версий матрицы, и непонятно, какая актуальна

> **Читайте также:** [CRM Roadmap: как спланировать развитие CRM-маркетинга на 6–12 месяцев](https://clientcore.ru/blog/articles/crm-roadmap-kak-splanirovat-razvitie-crm-marketinga-na-6-12-mesyacev)

---

[Открыть статью на сайте](https://clientcore.ru/blog/articles/matrica-triggernyh-kommunikaciy-kak-razrabotat-dokument-kotoryy-navodit-poryadok-v-scenariyah)