Subscriber 360 v2: от профиля к действию, и почему первая версия редко работает

TL;DR

Subscriber 360 как платформа — это инфраструктура, не коммерческий продукт. Большинство операторов, запускающих проект Subscriber 360 v1, через 12-18 месяцев имеют красивый профиль клиента в одном экране и дашборд, который никто не открывает. ARPU не вырос, churn не упал, эффективность retention не улучшилась. Причина — Subscriber 360 v1 строится как «соберём данные», без operating model, превращающей данные в действия. Версия 2 начинается не с архитектуры данных, а с описания пяти-десяти конкретных решений, которые должны улучшиться, и обратного дизайна — что для этих решений нужно из данных, процессов, ownership и инструментов. Это меняет последовательность и сами критерии успеха.

Тест Subscriber 360 v1

Вопрос: пройдите 5 случайных клиентов из вашей базы через текущий Subscriber 360. Что вы можете сделать с этими профилями, чего не могли сделать без них?

Если ответ — «увидеть полную картину», «удобнее», — это сигнал, что v1 живёт. Subscriber 360 не для того, чтобы «удобнее видеть профиль». Он для того, чтобы конкретные коммерческие решения принимались лучше — с большей конверсией, с большей точностью, с большей скоростью.

Если ответ требует размышлений или сводится к «ну консультант контакт-центра видит больше истории», — это marginal. Большая часть ценности не captured.

Многие операторы оказываются в этой точке после 18-24-месячной сборки Subscriber 360 v1.

Где обычно теряется ценность

Несколько структурных причин, почему первая версия Subscriber 360 не даёт коммерческого эффекта.

Сборка начинается от данных, не от решений. Команда сначала строит модель данных, потом профиль UI, потом ищет use case. К моменту, когда use case формулируются, архитектура уже зацементирована и оптимизирована под profile view, не под решения.

Профиль есть, действия нет. Маркетинг видит профиль, но не имеет инструмента сразу действовать на его основе. Чтобы запустить кампанию, таргетированную на сегмент, видный в Subscriber 360, нужен ещё месяц работы с CRM, marketing automation, биллингом.

Owner отсутствует. Subscriber 360 после сборки переходит в IT operations. IT обеспечивает uptime и performance, но не отвечает за коммерческий результат. Когда retention rate не падает, никто не отвечает за этот провал.

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

Не тот сегмент. Subscriber 360 показывает то, что есть в данных. Но настоящие коммерческие решения требуют данных, которые могут не существовать в текущих source-системах, — активность конкурентов, более широкие поведенческие сигналы, сигналы намерения.

Глубокий разбор v2

Версия 2 строится по-другому. Сначала формулируются 5-10 конкретных коммерческих решений, которые должны улучшиться. Это могут быть:

Назначение retention-звонков. Кому в неделю надо позвонить и предложить retention-оффер. Сейчас этот список идёт через CRM-запрос с задержкой и ограниченной сегментацией.

NBA в приложении. Какое предложение показать клиенту в момент, когда он открывает приложение. Сейчас часто показывается generic-баннер.

Cross-sell в дилерской сети. Что предложить клиенту в офисе помимо того, с чем он пришёл. Сейчас дилер беспомощен — у него нет сигнала о клиенте.

Триггеры компенсации. Каким клиентам автоматически предлагать компенсацию после network-инцидента. Сейчас вручную и медленно.

Сегментация рисков для рассрочки. Какой клиент может получить рассрочку с какой уверенностью. Сейчас на упрощённой модели.

Каждое из этих решений — критерий успеха Subscriber 360 v2. Если решение принимается лучше — v2 работает. Если нет — что-то не так в сборке.

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

Профиль становится не «всё знание о клиенте», а композицией того, что нужно для каждого решения. Иногда профиль для разных решений выглядит по-разному.

FAQ

Если у нас уже работает Subscriber 360 v1, нужно ли всё перестраивать?

Не обязательно. Иногда v1 как фундамент подходит, но недостаточен. Сборка на уровнях v2 — operating model, owner, решения, action layer — добавляется поверх. Иногда некоторые элементы фундамента (задержка данных, источники данных) требуют работы, иногда нет.

Как избежать ошибок v1, если только начинаем?

Начинать не с RFP на платформу Subscriber 360. Начинать с воркшопа, где формулируются 5-10 решений, которые должны улучшиться. RFP формулируется только после этого и ставит требования, отвечающие на решения.

Как измерить, что v2 работает, а v1 — нет?

Простой тест — измерять конверсию на решениях, которые v2 должна улучшить. До v2 — baseline. После v2 — улучшение. Если улучшения нет, v2 не работает.

Subscriber 360 без data-quality-фундамента работает?

Нет. Если данные ненадёжны, любое решение на них ненадёжно. Data quality — это уровень, который должен быть до сборки v2.

Это очень дорого?

Зависит от scope. v2 не обязательно требует больше затрат, чем v1, — она требует другого подхода. Часто v2 дешевле, потому что фокусируется на 5-10 решениях, а не на «всё для всех». Lean и сфокусированно.

Когда v2 не приоритет

Если оператор только что закончил major-реструктуризацию и не имеет ресурса на ещё один трансформационный проект — wait.

Если v1 на минимуме функционирует и базовые операционные решения делаются (пусть и неоптимально), v2 — второй приоритет после стабилизации сети, биллинга или другого core.

Если data-quality-фундамент сломан, никакая v2 работать не будет. Сначала data quality.

Если retention уже на хорошем уровне и churn низкий, v2 даст маргинальный результат.

Если C-level не committed на изменение operating model, не только data platform, v2 окажется ещё одним IT-проектом без коммерческого эффекта.

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

Какие 5-10 коммерческих решений сегодня принимаются плохо или медленно? Если ответ затруднён — это первая работа.

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

Какова задержка данных в текущей Subscriber 360 v1 (если есть)? Часто это критический пробел.

Готова ли организация на изменение operating model, а не только tech change? Без этого commitment v2 — фейл.

Какой 12-15-месячный инвестиционный commit нужен и есть ли он?

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

Subscriber 360 v2 Design — выявление 5-10 коммерческих решений, которые должны улучшиться, обратный дизайн от решений к данным, процессам, ownership и инструментам, gap-анализ от текущего состояния, redesign operating model вокруг данных и пилот на 1-2 решениях в течение 90-120 дней до полного rollout.

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

• /insights/telecom-subscriber-intelligence-operating-model/ — operating model глубоко
• /insights/telecom-event-driven/ — событийный фундамент
• /insights/telecom-nba/ — NBA в составе действий
• /insights/telecom-micro-segments/ — микро-сегментация

Источники

• Министерство цифровых технологий — телеком инфраструктура УЗ
• Digital Government Portal — digital infrastructure UZ
• UzDaily — рынок телекома
• MNP.UZ — портабельность