Retention economics: когда удержать клиента дороже, чем отпустить
Не каждого клиента надо удерживать. Это утверждение звучит провокационно, но математика часто простая. У retention есть верхняя граница, выше которой удержание идёт в минус оператору.
Обсудить задачуПростой расчёт
Возьмём абстрактного клиента. Ежемесячный ARPU 50 тыс. сум, маржинальность сервиса 30 процентов — то есть 15 тыс. сум margin в месяц. Клиент заявляет о намерении уйти, retention-команда предлагает удержание: скидка 25 процентов на 6 месяцев плюс бонусный пакет данных стоимостью 30 тыс. сум по cost.
Считаем economics удержания. Скидка съедает 12,5 тыс. сум margin в месяц на 6 месяцев — итого 75 тыс. сум недополученной маржи. Плюс бонусный пакет 30 тыс. сум cost. Итого retention investment — 105 тыс. сум.
Что мы получаем взамен. Если клиент остаётся 12 месяцев после retention offer, среднемесячный margin за этот период — 15 тыс. сум минус 12,5 тыс. сум первые полгода — то есть 2,5 тыс. сум первые 6 месяцев и 15 тыс. сум следующие. Total margin за 12 месяцев — 105 тыс. сум.
Net effect — ноль. Мы потратили 105 тыс. сум и за 12 месяцев получили обратно 105 тыс. сум. Никакой прибыли, никакого ROI на retention investment.
Это не теоретический пример — это типичная картина при retention оffers без discipline. Большая часть удержаний делается с такой структурой и не приносит value сверх breakeven. Хуже — часть из них не доходят до breakeven, потому что клиент уходит до конца retention discount или потому что фактическая маржинальность ниже модельной.
Теперь возьмём другого клиента. ARPU 20 тыс., margin 6 тыс. в месяц. Тот же retention оффер с 25 процентами скидки и бонусом — это 99 тыс. сум investment против 18 тыс. сум margin × 6 месяцев — итого 108 тыс. сум маржи за полгода (12 за остающиеся 6). На этом сегменте retention уходит в минус.
Что отсюда следует
Retention не должен делаться automatically для каждого клиента который собирается уйти. У retention есть граница, и эта граница зависит от сегмента, ARPU, фактической маржи, retention rate, expected lifetime после retention.
Многие операторы это знают теоретически, но в практике retention-команда работает по простому правилу: «звонит клиент с намерением уйти — даём всё что у нас есть в скрипте, лишь бы остался». Метрика команды — retained subscriber count, не retained margin.
Это создаёт ситуацию когда оператор тратит миллионы сум на удержание клиентов с unit economics в минус, и не имеет visibility на это в P&L отдельной строкой.
Четыре сценария чтобы было понятнее
Хорошо построенная retention economics обычно выделяет четыре зоны.
Зона 1. High-value клиент. ARPU значительно выше среднего, low service cost, длинный tenure. Удерживать стоит почти любыми средствами в разумных пределах — LTV высокая, retention investment окупается многократно. Фокус retention-команды.
Зона 2. Mid-value регулярный клиент. ARPU средний, стабильный. Retention имеет смысл если стоит не больше 2-3 месячных margin — есть возврат, но нет premium. Аккуратные оffers, не «дать всё».
Зона 3. Low-value но активный клиент. ARPU низкий, но клиент пользуется сервисом. Retention имеет смысл только если cost минимален — простое сообщение или небольшой бонус. Заметное вложение в удержание не окупается.
Зона 4. Loss-making segment. Клиент с отрицательной margin (использует subsidized услуги, частые жалобы, abuse pattern). Retention здесь идёт в минус оператору. Уход такого клиента улучшает economics.
Граница между зонами не должна быть на ощущениях — нужна реальная LTV-модель которая обновляется регулярно. Без этого retention-команда работает на инстинкте, и инстинкт почти всегда — «удержать любой ценой».
Что часто делается некорректно
Retention metric — number, не margin. KPI команды — «удержали X клиентов в месяц». Это создаёт perverse incentive — лучше удержать 100 low-value чем не удержать 50 high-value.
One-size offer без сегментации. Один скрипт, одинаковая скидка для всех. Это самый распространённый и самый нерезультативный способ. На high-value сегменте оffers недостаточные, на low-value — избыточные.
Разрешение «добавлять» к retention оfferу без учёта economics. Консультант видит что клиент сомневается, добавляет ещё бонус, ещё снижение цены, без проверки выходит ли это в итоге за лимит. Нет hard cap на retention investment по сегменту.
Отсутствие measurement реального исхода. Клиент остался — победа. Что произошло через 6 или 12 месяцев — не отслеживается в команде retention. Это означает обучение команды затруднено — нет обратной связи какие тактики работают, какие нет.
Retention при ситуациях когда отток обусловлен сетью или сервисом. Если клиент уходит из-за плохого качества в его районе или из-за неудобного сервиса — retention оффер не решает проблему. Ему дали скидку, он остался на 3 месяца, потом ушёл всё равно. Это надо отличать.
Что должно быть чтобы retention работал
LTV-модель по сегментам. Не одна цифра — распределение по микро-сегментам, обновляемое.
Hard cap на retention investment. По каждому сегменту определён максимальный размер оffera который имеет ROI. Консультант не может этот лимит превысить.
Сегментный playbook. Разные оffers для разных сегментов. У high-value команда имеет дополнительные tools (premium support upgrade, ранний доступ к новым услугам). У low-value — минимальный список простых оffers.
Reason code для оттока. Каждый случай retention помечается причиной. Если причина — сеть, retention переадресуется в network ops для исправления, а не «закрывается» дополнительной скидкой. Если причина — конкурентное предложение, это retention case. Если причина — финансовая — отдельный playbook.
Measurement через 6 и 12 месяцев. Что произошло с retained клиентом. Какие тактики дали реальный возврат, какие нет. Это feedback loop для improvement.
Когда не запускать retention reform
Если organisation не имеет данных по фактической маржинальности в разрезе клиента, LTV-модель построить нельзя. Нужно сначала data foundation.
Если retention-команда — outsource с жёсткими KPI на retained count, реформа упирается в контракт. Без обновления контракта реформа не запустится.
Если sales и retention metrics не разделены — продажа удержанного клиента засчитывается как новая sale — incentive искажён. Нужно отделить.
Если CFO не готов на реальную видимость retention investment в P&L (что покажет потери которых раньше не было видно), реформа политически блокируется.
Если бренд позиционирован как «мы удерживаем любой ценой», публичный ребрендинг будет нужен. Без этого сегментная retention воспринимается как ухудшение для одних в пользу других.
Что обсудить на committee
Какова текущая retention investment в P&L отдельной строкой? Если данные неизвестны или включены в общий маркетинговый бюджет — это первый gap.
Какова LTV-распределение по сегментам? И как часто эта модель обновляется?
Какие KPI у retention-команды сегодня? Если только count — нужна перестройка на margin.
Какие 5 reason codes для оттока самые частые? Это direction для proactive решения корневых причин, а не reactive retention.
Готов ли совет директоров на временное снижение retention rate в обмен на улучшение retention margin? Без этого commit реформа не пройдёт.
Что может сделать SamaraliSoft
Retention Economics Diagnostic — это анализ фактических unit economics retention investment по сегментам, построение sиmple LTV-модели для оператора, сегментный playbook с hard caps на оffers, design measurement framework через 6/12 месяцев, и pilot реформы на одном сегменте в течение 90 дней.
Внутренние ссылки
- /use-cases/telecom-churn-war-room-mnp/ — retention в эпоху MNP
- /insights/telecom-subscriber-intelligence-operating-model/ — operating model
- /insights/telecom-arpu-bundles-devices/ — где растёт ARPU
- /insights/telecom-nba/ — NBA как контекст
Источники
Что ещё стоит изучить
Темы из этой же области, которые часто разбираем вместе с этой
CRM
Не коробочный CRM, а правильно выстроенный контур управления клиентами — от первого контакта до лояльности.
→РешениеBI
Аналитика — не красивые графики на стене. Это ответ на вопрос 'почему?' до того, как проблема станет убытком.
→РешениеКонтакт-центр
Контакт-центр — не телефонная станция, а точка, где клиент решает: остаться с вами или уйти. Вопрос в том, как он устроен внутри.
→РешениеИнтеграции
Интеграции — невидимый, но критический слой. Когда он работает — системы общаются. Когда нет — данные теряются, а люди копируют из окна в…
→Об этом не просто пишу — могу прийти, разобрать вашу ситуацию и спроектировать решение под ваш контур.
Обсудить применение →Готовы обсудить вашу задачу?
Расскажите, что не работает или что нужно построить. Первый разговор — без обязательств.
Обычно отвечаю в течение нескольких часов