Next Best Action вместо массовых рассылок: что меняется

Стоимость массовой рассылки

«Массовая SMS-рассылка ничего не стоит» — фраза, которую принимают как факт. На самом деле она стоит больше, чем кажется.

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

Косвенная стоимость значительнее. Каждая нерелевантная коммуникация снижает открываемость и конверсию будущих сообщений. Если клиент получил пять рассылок не по делу, он перестаёт читать SMS от оператора в принципе. Когда оператор отправит важное сообщение — например, о замене SIM или о критичной операции — оно может быть проигнорировано. Это реальная стоимость, которая не появляется в P&L отдельной строкой, но влияет на эффективность всех будущих коммуникаций.

Ещё одна косвенная стоимость — восприятие бренда. Оператор, который шлёт нерелевантные оффер-SMS, воспринимается как «продающий», а не как «помогающий». Это влияет на NPS, retention и косвенно на готовность клиента покупать новые продукты.

NBA — Next Best Action — это альтернатива. Вместо массовой рассылки система выбирает для конкретного клиента в конкретный момент конкретное действие. И это действие может вообще не быть оффером — это может быть проактивное уведомление, помощь, информация.

Что входит в NBA

NBA — не модель ML. NBA — это операционный контур из шести компонентов.

Каталог действий. Список конкретных действий, которые система может предлагать. Каждое действие имеет: целевая аудитория, канал, содержание, бизнес-цель, метрика успеха. Не «общие маркетинговые кампании», а конкретные действия с описанием.

Правила допуска (eligibility). Для каждого действия — кто может его получить. Не «все», а конкретно. Эти правила могут быть простыми (если ARPU выше X и трафик-паттерн Y) или сложными (multi-criteria scoring).

Правила исключения (suppression). Кто действие получить НЕ должен. Клиент, который недавно жаловался. Клиент в blackout-периоде после предыдущего действия. Клиент с opt-out. Клиент в высокорисковом сегменте по fraud.

Ранжирование. Когда несколько действий применимы, как выбрать одно. Ранжирование может быть простым (по приоритету) или сложным (модель, предсказывающая конверсию каждого).

Лимиты частоты. Не более X действий в день, Y в неделю, Z в месяц. Эти ограничения предотвращают спам.

Аудит и обучение. Что произошло после каждого действия. Конверсия. Реакция клиента. Используется для улучшения модели и правил.

Без любого из этих шести компонентов NBA не работает. Большинство проектов NBA фокусируются на модели (ранжировании) и забывают остальные пять. Это объясняет почему 70% проектов NBA остаются на стадии пилота.

Что отличает работающий NBA от модели

Работающий NBA имеет несколько характеристик, которых часто нет в пилоте.

Каталог действий конечный. Не «модель решит что делать», а «модель выбирает из 30 определённых действий». Каталог требует поддержки — добавлять новые действия, удалять не работающие, корректировать содержание. Это дисциплина, которой часто нет.

Eligibility — это не просто фильтр по данным. Допуск включает бизнес-суждение. «Этот клиент технически подходит для оффера, но он сейчас в споре по биллингу — не делать». Это требует человеческого участия в правилах.

Suppression — отдельная договорённость с командой клиентского опыта. Клиент не должен получать конфликтующие коммуникации (например, retention-звонок из контакт-центра одновременно с маркетинговым push). Это требует кросс-функциональной координации.

Лимит частоты — не просто «не более X в день». Лимит должен быть сегментированным. Премиум-клиент может получать чаще, low-value — раз в две недели. Без сегментации лимит либо избыточно жёсткий (теряются возможности), либо избыточно мягкий (создаётся усталость).

Что чаще всего ломает NBA

Доминирование маркетинга над клиентским сервисом. Когда NBA принадлежит маркетингу, каталог действий смещается в сторону продаж и промо. Действия customer care (проактивные уведомления, помощь, retention-контакт) недопредставлены. Клиент чувствует что NBA — это спам в другой обёртке.

Отсутствие владельца действий. Действие добавлено в каталог, но никто не отвечает за его эффективность. Через 6 месяцев в каталоге 50 действий, из них 20 не работают, никто их не чистит. Каталог превращается в мусор.

Моделирование без операционной интеграции. ML-команда построила модель ранжирования, но интеграция с decision engine не сделана, или события не приходят в реальном времени. Модель предсказывает в воздух.

Один канал. NBA отправляет всё через один канал (обычно push или SMS). Не учитывает что у разных сегментов предпочтения разные. Премиум-клиент может ожидать звонок или письмо, не push.

Отсутствие культуры экспериментов. NBA эффективен, когда непрерывно тестируется — A/B-тесты на содержание, время, ранжирование. Если каждое изменение требует одобрения через комитет, итерация замедляется до точки, когда NBA не лучше rule-based кампании.

Реалистичный NBA в первый год

NBA не строится за квартал. Реалистичный план — год.

Первые 90 дней. Фундамент. Каталог из 10-15 базовых действий с полным описанием. Правила допуска для каждого действия. Правила исключения — глобальные и для каждого действия. Лимиты частоты по сегментам. Инфраструктура аудита.

Следующие 90 дней. Пилот. NBA активирован на одном сегменте (например, премиум-постпейд). Ежедневное ранжирование. 5-7 каналов с оркестрацией. Ежедневный обзор между маркетингом, customer care и финансами. Рамка измерения.

Следующие 90 дней. Итерация. Удаление неработающих действий. Добавление 5-10 новых на основании выявленных пробелов. Уточнение правил. Обновление модели если реально нужно. Расширение на второй сегмент.

Последние 90 дней. Масштабирование. Покрытие расширено на 50%+ активной базы. Мульти-канальная оркестрация. Непрерывное экспериментирование. Связка с процессами network experience и retention.

После года правильный NBA даёт прирост конверсии 30-100% относительно baseline-кампаний. Это не «один проект» — это перестройка коммерческой работы.

Когда NBA преждевременен

Если в каталоге действий меньше 8-10 продуманных вариантов, строить NBA нет смысла. Сначала собрать каталог через rule-based систему, потом добавлять модель.

Если master data между биллингом, CRM и приложением не сходится, допуск будет неточным, NBA будет ошибаться, доверие команды к системе подорвётся.

Если контакт-центр и retention действуют независимо от маркетинга и нет общего дашборда, NBA создаёт конфликтующие коммуникации с одним клиентом.

Если в управлении согласиями нет градации (один общий opt-in или ничего), нельзя корректно учитывать предпочтения клиента.

Если регулярная операционная встреча не сложится (нет еженедельного обзора между маркетингом, продажами, customer care), NBA быстро деградирует — действия без владельцев, лимиты частоты без контроля, правила исключения забыты.

Что обсудить на committee

Сколько кампаний оператор провёл за последний квартал и какая их экономика? Если ответ затруднён — базы нет, NBA строить рано.

Какие 5 действий работают лучше всего и какие 5 хуже всего? Если этого знания нет, NBA будет не улучшением, а перестройкой процессов.

Какой текущий NBA-стек или существующая система оркестрации? Если ничего нет — начинать с малого. Если есть legacy campaign system — рефакторинг.

Кто будет владельцем NBA как продукта? Не «маркетинг» — конкретный человек с правом менять каталог.

Что может сделать SamaraliSoft

Next Best Action / Offer Engine Blueprint — разработка каталога действий для конкретного оператора, дизайн правил допуска, исключения и лимитов частоты на основе реальной клиентской базы, выбор архитектуры NBA (свой / внешний / гибрид), пилот на одном сегменте с рамкой измерения и план масштабирования на 12 месяцев.

Внутренние ссылки

• /insights/telecom-subscriber-intelligence-operating-model/ — operating model вокруг данных
• /use-cases/telecom-churn-war-room-mnp/ — retention в эпоху MNP
• /insights/telecom-ai-native/ — где AI окупается
• /architecture/telecom-around-core-architecture/ — слой роста

Источники

• Digital Government Portal — digital infrastructure UZ
• UzTelecom — пример пользовательского интерфейса
• ЦБ РУ — биометрическая верификация digital banking
• UzDaily — рынок телекома