<b>Churn не лечится саппортом: его надо разложить на 3 разных риска</b>

<b>Churn не лечится саппортом: его надо разложить на 3 разных риска</b>

Если смотреть на churn как на одну цифру, команда почти всегда ошибается в причинах. На практике это три разных слоя:
— продуктовый: клиент не получает ценность и не внедряется
— операционный: в аккаунте нет владельца, ритм контактов рваный
— экономический: контракт не оправдывает себя для покупателя

Для каждого слоя нужен свой сигнал. Продуктовый churn лучше ловить по падению использования ключевой функции, а не по общему login rate. Операционный — по пропущенным QBR, росту числа эскалаций и зависшим задачам. Экономический — по снижению expansion, просьбам о скидке и сокращению seats.

Если все риски свалены в один health score, CS начинает тушить шум вместо причины. Тогда «красный» аккаунт может быть просто плохо онборжен, а «зелёный» — уже на пути к не продлению. Хорошая модель churn всегда отвечает на вопрос: что именно изменилось в поведении клиента и кто должен на это реагировать.

Минимальный набор для зрелой команды: 1) один leading indicator по продукту, 2) один по процессу взаимодействия, 3) один по экономике аккаунта. Всё остальное — вторично.

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