Expansion revenue не появляется “сам”. Его надо встроить в CS-механику
Если вы смотрите только на churn, вы видите половину картины. Рост выручки внутри базы обычно рождается не из «допродаж», а из структуры аккаунта и момента использования продукта.
Рабочая схема почти всегда одна:
— сначала у клиента должен появиться повторяемый результат;
— потом — понятный триггер для расширения: больше мест, больше объёма, новый модуль, более высокий план;
— и только затем CS может поднимать expansion без ощущения, что его «продают».
Типовая ошибка в small SaaS — пытаться продавать expansion слишком рано. Пока customer success занят тушением пожаров, любой апселл выглядит как давление. В enterprise ошибка другая: expansion не привязан к health score и попадает в pipeline случайно, поэтому выручка есть, а прогнозируемости нет.
Удобно делить expansion на три источника:
— usage-based: клиент растёт в потреблении;
— seat-based: расширяется команда;
— value-based: подключается следующий уровень задач.
Если в вашей модели нет отдельного триггера на каждый источник, expansion будет зависеть от удачи и активности аккаунт-менеджера. Это плохая конструкция для NRR.
Лучший сигнал для команды — не «клиент доволен», а «в аккаунте уже есть причина для следующего чека». Тогда expansion revenue становится не отдельной акцией, а побочным эффектом хорошо выстроенного retention.
Retention Lab — CS и NRR
@retention_lab_aff
Expansion revenue не появляется “сам”. Его надо встроить в CS-механику
Этот пост опубликован в Telegram-канале Retention Lab — CS и NRR. Подписаться можно по ссылке: @retention_lab_aff.