Отток клиентов: ранние сигналы и проверка риска до потери клиента

Отток клиентов нельзя предсказывать, пока компания не договорилась, кого и с какого момента считает ушедшим. Сначала задайте событие ухода, начальную когорту и период расчёта. Затем ищите сигналы, которые были доступны до этого события, проверяйте сезонность и пропуски и только после этого назначайте действие сотруднику.

Результатом должен стать не список «плохих» клиентов, а проверяемый процесс: сигнал появился → сотрудник выяснил причину → исправил данные или предложил помощь → команда позже проверила исход. Риск означает основание для проверки, а не доказанное намерение клиента уйти.

Что считать оттоком и ранним сигналом

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

Рассмотрим синтетическую подписку. На 1 января у компании есть начальная когорта из 20 активных платящих клиентов. Окно наблюдения — с 1 января по 31 марта. Клиент считается ушедшим, если оплаченная подписка прекратилась до 31 марта и не возобновилась в этом окне.

Такое определение фиксирует четыре вещи:

1. Единицу учёта: клиент, а не подписка, договор или пользовательский аккаунт.
2. Начальную когорту: 20 клиентов, активных на 1 января.
3. Окно наблюдения: первый квартал.
4. Событие ухода: прекращение оплаченной подписки без возобновления до конца окна.

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

Важно разделять три состояния:

• снижение активности до события ухода — ранний сигнал;
• наступившее событие по принятому определению — фактический отток;
• возврат после состоявшегося ухода — реактивация.

Если клиент уже признан ушедшим, работа с ним относится к реактивации. В этой статье речь идёт о клиентах, которые ещё не ушли и у которых команда заметила проверяемое изменение.

Какие данные нужны для оценки риска

Признак полезен только тогда, когда известно, когда он возник и когда попал в рабочую систему. Иначе в расчёт может незаметно попасть будущее событие — например, отмена подписки, случившаяся после даты прогноза.

На дату оценки можно использовать только сведения, которые уже были доступны в эту дату. Если 15 февраля система получила запись задним числом за январь, нужно различать дату события и дату появления записи. Историческая проверка должна воспроизводить именно ту картину, которую сотрудник мог видеть 15 февраля.

Проверять нужно не только значения, но и пропуски. В синтетической когорте из 20 клиентов у двух нет событий использования. Доля пропусков равна:

2 / 20 × 100% = 10%.

Эти записи нельзя автоматически превращать в «нулевую активность». Сначала владелец данных выясняет, действительно ли событий не было или источник перестал их передавать. Полезно хранить отдельный признак пропуска, чтобы ноль и отсутствие данных не смешивались.

Данные следует собирать в допустимом для задачи объёме. Если для проверки достаточно числа действий за неделю, сотруднику не обязательно видеть содержание каждого действия. Состав полей, сроки хранения и доступы согласуют с владельцами процесса и данных.

Как выбрать простые правила или модель

Начните с правила, которое сотрудник способен объяснить и проверить. Например, создавать сигнал, если активность клиента снизилась относительно его собственного сопоставимого периода и одновременно появился второй признак: платёжная проблема, обращение или изменение договора.

Такое правило не доказывает уход. Оно задаёт очередь для проверки. Команда видит, почему сработал сигнал, может найти ошибку в источнике и изменить порог без попытки угадать логику сложной модели.

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

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

В официальной документации Microsoft Dynamics 365 Customer Insights описана модель риска прекращения использования подписочных продуктов и периодических услуг. Документация задаёт требования именно для этого продукта: среди них история подписок, события активности и ограничения по пропускам. Эти требования нельзя переносить на все сервисы и собственные модели. Они также не подтверждают совместимость с CRM конкретной компании: права, тариф, доступные операции и API проверяют отдельно.

Практический порядок выбора выглядит так:

1. Зафиксировать событие ухода и дату прогноза.
2. Собрать объяснимое правило из доступных до этой даты признаков.
3. Проверить правило на прошлых окнах.
4. Сравнить модель с правилом, если истории достаточно для честной проверки.

Как отличить риск от сезонности и ошибок

Снижение активности — наблюдаемый факт, но причина пока неизвестна. Формулировка «клиент потерял интерес» приписывает человеку намерение, которого данные не подтверждают.

Перед контактом выполните три проверки.

Сравните клиента с его собственным аналогичным периодом. Если активность каждый февраль снижается одинаково, изменение может быть сезонным. Сравнение с предыдущей неделей без учёта календаря даст лишнюю тревогу.

Сравните клиента с похожей группой. Одновременное снижение у клиентов одного региона, тарифа или типа бизнеса может указывать на сезон, общий сбой или изменение правил учёта. Группу нужно определить до анализа, а не подбирать после результата.

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

Поэтому в рабочей карточке лучше писать «число событий снизилось с 10 до 4» или «данные не поступали два дня». Гипотезу о причине сотрудник подтверждает по договору, журналу, обращению или разговору с клиентом.

Учебный разбор трёх сигналов риска

Ниже — полностью синтетический пример, а не клиенты, файл или результат Switch On AI. Дата оценки для всех строк — 15 февраля, горизонт проверки — до 31 марта. Компания использует определение ухода из первого раздела.

К концу условного окна клиент A не продлил подписку и считается ушедшим. Клиенты B и C продолжили подписку; у B снижение совпало с сезонностью, у C ноль возник из-за ошибки учёта.

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

Разные причины требуют разных действий. Клиенту A можно предложить помощь после проверки договора и доступности услуги. По клиенту B достаточно продолжить наблюдение. По клиенту C сначала исправляют данные — обращение к клиенту из-за внутренней ошибки только создаст лишний вопрос.

Как считать фактический отток до построения прогноза

Сначала посчитайте состоявшийся отток по принятому определению. Для клиентов формула выглядит так:

Доля оттока клиентов = число клиентов из начальной когорты, у которых событие ухода произошло в окне / число клиентов в начальной когорте × 100%.

В синтетическом примере из начальной когорты 20 клиентов до 31 марта ушли трое:

3 / 20 × 100% = 15%.

Клиентов, которые присоединились после 1 января, в знаменатель этой когорты не добавляют. Для них нужна другая когорта.

Отток выручки считают отдельно:

Доля оттока выручки = потерянная регулярная выручка клиентов начальной когорты / регулярная выручка этой когорты на начало периода × 100%.

Если начальная регулярная выручка условной когорты равна 200 000 ₽, а ушедшие клиенты приносили 25 000 ₽, расчёт будет таким:

25 000 / 200 000 × 100% = 12,5%.

Нельзя усреднять 15% и 12,5%. Первая величина описывает число клиентов, вторая — выручку. Обе относятся только к этому синтетическому примеру и не являются нормой для другого бизнеса.

Если в начальной когорте нет клиентов, долю не считают и указывают «нет базы для расчёта», а не 0%. То же правило действует при нулевой начальной выручке. Ноль процентов означает, что база была, но событие ухода не произошло; нулевой знаменатель означает отсутствие основы для вычисления.

Как проверить предупреждения и внедрить процесс

Историческая проверка должна ответить на два разных вопроса: насколько хорошо сигнал находит будущий отток и помогает ли выбранное действие. Один вопрос нельзя подменять другим.

Для проверки предупреждений возьмите несколько завершённых прошлых периодов. На дату каждого прогноза восстановите только доступные тогда данные, примените правило и затем сопоставьте предупреждение с фактическим исходом.

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

Даже точное предупреждение не доказывает эффект звонка, письма или предложения. Для проверки действия нужна отдельная процедура: среди сопоставимых клиентов с одинаковым правилом риска заранее выделить группу контакта и контрольную группу, не получающую именно это дополнительное воздействие. Затем сравнить исходы в одном окне. Размер выборки, допустимые различия и этические ограничения определяют до запуска; на малой выборке вывод может остаться неопределённым.

Рабочий процесс можно построить так:

1. Источники передают датированные события.
2. Правило или модель создаёт сигнал с объяснением.
3. CRM назначает сотруднику задачу проверки.
4. Сотрудник фиксирует причину, действие и последующий исход.

Switch On AI может разработать для такой операции ИИ-помощника, бота или обычную интеграцию после проверки данных и API. Например, интеграция может связать согласованные сигналы, CRM и задачи сопровождения, а ИИ-помощник — подготовить сотруднику краткий контекст из разрешённых источников. Решение о контакте, условиях предложения и спорных случаях остаётся у команды.

Это не обещание совместимости с любой CRM и не подтверждение внедрения Microsoft Dynamics 365. До разработки нужно проверить доступные API, права, тариф, качество истории и правила обработки данных. Если задачу закрывают штатные возможности CRM, отдельная разработка может не понадобиться.

На странице ИИ-помощника для продаж описан подход к передаче контекста менеджеру и проверке CRM-маршрута. Чтобы оценить применимость к оттоку, подготовьте описание одной операции: цикл подписки или повторной покупки, определение ухода, источники сигналов и действие сотрудника. Затем можно разобрать процесс со Switch On AI и согласовать границы прототипа. Прототип проверяет ключевой сценарий, но не равен полноценному внедрению и не гарантирует снижение оттока.