Subscriber Intelligence: почему 360-профиль не приносит денег без operating model

Что обычно идёт не так

В одном телекоме региона потратили 14 месяцев и значительный бюджет на построение Subscriber 360. Собрали данные из биллинга, CRM, приложения, контакт-центра, dealer portal. Сделали golden record. Построили дашборд, в котором по каждому абоненту видны 84 атрибута — потребление, платежи, обращения, устройства, история тарифов, скорость деградации сигнала по соте.

Через три месяца после запуска никто не использовал дашборд регулярно. Бизнес говорил «у нас нет времени смотреть, дайте нам список клиентов которым нужно позвонить». Маркетинг просил «соберите сегмент по таким-то условиям и выгрузите». Контакт-центр вообще не получил доступа — IT беспокоился о персональных данных.

Дашборд закрыли. Проект записали как успешный — «инфраструктура готова, теперь команда должна научиться её использовать». Команда не научилась.

Эта история повторяется регулярно по одной причине. Subscriber 360 — это не продукт. Subscriber 360 — это инфраструктура для другого продукта, который называется operating model. Без второго первое не приносит денег.

Что такое operating model вокруг данных

Operating model — это не «кто отвечает за дашборд». Это набор связанных правил которые отвечают на пять вопросов.

Какое событие запускает реакцию? Не «есть данные о клиенте», а «когда меняется состояние клиента, что должно произойти». Истечение пакета. Снижение трафика на 50% за неделю. Жалоба третий раз за месяц. Поездка в роуминг. Смена устройства. Каждое из этих событий — потенциальный trigger.

Кто владеет реакцией? Не «маркетинг работает с данными» — это слишком общо. У каждого типа события должен быть конкретный owner с правом принимать решения по отклику. Если событие «истечение тарифа» — это retention manager. Если «жалоба третий раз» — head of customer care.

В каком канале происходит отклик? Push в приложении? SMS? Звонок? E-mail? Письмо в personal account? Сообщение через дилера? Каждый канал имеет свою стоимость, скорость и conversion. У отклика должно быть назначение канала по правилам, а не «сегодня попробуем push, завтра SMS».

С какой скоростью? Если событие произошло в 14:00, а отклик пришёл в 09:00 следующего дня — это другая операция, чем 14:15. Скорость влияет на conversion в разы.

Кто несёт P&L за результат? Это самый сложный вопрос. Если event triggers conversion, кому в коммерческой структуре прибавляется в KPI? Если retention сработал — кто получает credit? Если человек ничего не сделал — кто несёт ответственность за упущенный отклик?

Без ответов на эти пять вопросов Subscriber 360 — это объект созерцания, не инструмент бизнеса.

Почему это не делается само

Естественно возникает вопрос: если operating model настолько важна, почему она не возникает автоматически когда команда видит дашборд? Ответ в том что operating model — это управленческий проект, не технологический, и он требует другой команды и другого мышления.

Технологический проект может быть закрыт командой IT с подрядчиком. Operating model требует чтобы коммерческая дирекция, customer care, маркетинг, аналитика и финансы согласились на единый набор правил и единые KPI. Это переговорный процесс, а не deployment. Часто он откладывается потому что «сначала запустим, потом разберёмся как использовать».

Это всегда заканчивается тем что проект запускается, использования не возникает, и через год команда говорит «технология не сработала». На самом деле сработала технология, не сработало управление.

Что входит в реалистичный operating model

Минимальный набор компонентов выглядит так.

Catalog of events. Список 10-30 событий клиента которые имеют коммерческий смысл. Не «все события», а отобранные по двум критериям: они часто происходят и на них есть осмысленная реакция.

Decision rules per event. Для каждого события — таблица. При каких условиях клиента какой оффер показывается, в каком канале, с какой частотой, кто исключения. Эти правила должны быть документированы, а не жить в головах.

Owner per decision. Конкретный человек или роль которая отвечает за качество правил. Не «команда», а имя. Эта роль имеет право менять правила и видит экономические результаты своих решений.

Suppression rules. Правила что НЕ делать. Не показывать оффер если клиент уже жаловался в последние 7 дней. Не звонить ночью. Не делать второй контакт в течение 48 часов. Без suppression rules даже хорошие правила превращаются в спам.

Frequency caps. Сколько раз в день/неделю/месяц допустимо контактировать одного клиента. Без этих ограничений система быстро надоедает клиенту.

Audit log. Запись кто какое решение принял и почему. Для регуляторики это обязательно по закону о персональных данных, для качества — для разбора почему конкретный клиент получил конкретный оффер.

Performance dashboard. Не «общий дашборд про всех клиентов». Управленческий экран, в котором видно: какое событие сколько раз случилось, какой % получил отклик, какой % conversion, какая экономика per event. Этот дашборд читает каждый понедельник committee.

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

Конкретный пример: событие «истечение пакета на 80%»

Возьмём одно событие и посмотрим что значит operating model на практике.

Событие: клиент использовал 80% пакета мобильных данных, до конца тарифного периода 2-3 дня.

Без operating model: данные собираются. Маркетинг иногда отправляет SMS «у вас закончился пакет». Иногда не отправляет. Иногда отправляет всем вместо одного сегмента. Conversion в покупку дополнительного пакета на уровне 2-4%.

С operating model. Decision rule: если клиент в категории A (active digital, постоянный трафик), показать в приложении предложение «продлить пакет» с ценой X в момент превышения 80%. Если в категории B (прерывистый трафик), отправить SMS с другим оффером. Если в категории C (low spender), не делать ничего — стоимость контакта выше ценности.

Suppression: если клиент в последние 7 дней получил оффер на пакет, не показывать снова. Если жаловался — не показывать.

Frequency cap: не более одного push на эту тему в месяц.

Owner: head of digital monetization. Именно он несёт KPI по conversion данного события.

Performance: на дашборде событие отслеживается отдельно. Видно сколько раз сработало в неделю, какая средняя сумма дополнительной покупки, какой ROI на стоимость контакта.

Conversion с такой operating model на практике — 12-18% против 2-4% без неё. Разница не в данных. Данные те же. Разница в дисциплине.

Когда не строить Subscriber 360

Не каждый оператор готов к этой инвестиции, и это нормально.

Если master data о клиенте, номере, договоре и устройстве существенно расходится между биллингом, CRM и приложением, и сверка делается вручную или раз в неделю, Subscriber 360 будет строиться на песке. Сначала data quality — минимум 6-9 месяцев работы.

Если в коммерческой структуре нет роли которая может принять P&L за результат decisions по событиям, проект будет жить в IT и медленно умирать. Operating model требует commercial owner с правом менять правила и видеть результат в P&L.

Если есть только один большой канал коммуникации с клиентом (например, только SMS), Subscriber 360 даёт ограниченный эффект — потому что нет вариативности per channel. Сначала развитие каналов (push, app inbox, dealer touch), потом 360.

Если в правилах работы с персональными данными нет явных согласий на маркетинговую обработку и на персонализацию, Subscriber 360 строится в регуляторном риске. Сначала consent management.

Если бюджет рассчитан только на построение 360 без 18-24 месяцев продолжающейся настройки правил и команды, проект закроется до того как покажет результат.

Что значит «дашборд готовый, но никто не использует»

Это не неудача проекта. Это диагноз: проект построил инфраструктуру и не построил operating model. Лечится не повторным проектом, а формированием управленческой routine.

Реалистичный путь восстановления — взять одно конкретное событие (например, истечение пакета), построить вокруг него полный цикл operating model на 90 дней (rules, owner, channel, audit, dashboard, weekly review), измерить результат, потом масштабировать на следующее событие. Это не звучит масштабно, но именно такой путь приводит к работающей системе.

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

Subscriber Intelligence & Churn War Room — это не «построим вам ещё один Subscriber 360». Это работа над operating model: выбор пилотного события, построение полного цикла rules-owner-channel-audit-review, измерение результата за 90 дней, потом масштабирование. Если у оператора уже есть Subscriber 360 — диагностика почему он не работает и план восстановления. Если нет — план построения с самого начала с правильным разделением между инфраструктурой и operating model.

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

• /cases/telecom-subscriber-360/ — реальный кейс Subscriber 360 в операторе региона
• /insights/telecom-bss-oss-growth-layer/ — почему around-core слой важнее замены биллинга
• /architecture/telecom-event-driven-architecture/ — события как фундамент operating model
• /insights/telecom-after-connectivity/ — где деньги в телекоме после connectivity

Источники

• Digital Government Portal — состояние digital infrastructure UZ
• UzDaily — рынок телекома 24,873 млрд сум, +18,3%
• ЦБ РУ — статистика payment systems
• UzTelecom — пользовательский интерфейс