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

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

Найдите ограничение, которое клиент действительно испытывает

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

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

СигналЧто уточнитьВозможное предложение
Регулярно заканчивается лимитЭто устойчивая работа или разовая нагрузка?План с подходящим объёмом либо временное расширение
Нужна дополнительная рольЕсть ли подтверждённый участник и полномочия?Тариф с необходимым разграничением доступа
Запрашивается новая функцияОна решает текущую задачу и готова к использованию?Демонстрация на сценарии клиента
Много неиспользуемых ресурсовМожно ли сначала убрать лишнее?Настройка действующего плана без смены тарифа

Порог вроде «использовано 80% лимита» — рабочая гипотеза команды, а не универсальный момент для продажи. При стабильном объёме этих оставшихся 20% может хватать годами. Полезнее оценить скорость расходования и ожидаемую потребность до конца периода.

Определите, кто может принять решение

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

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

Покажите полную цену изменения

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

Условный пример. При строго 30-дневном месяце тариф стоит 1 000 рублей, новый — 1 600 рублей. Если ровно половина периода ещё впереди, прежний период полностью оплачен и применяется простой пропорциональный перерасчёт без налогов и скидок, доплата составит (1 600 − 1 000) × 15 / 30 = 300 рублей. Следующий полный период стоит 1 600 рублей. В реальном продукте оба значения берутся из расчёта его платёжной системы.

На экране подтверждения покажите сумму сейчас, стоимость следующего периода, дату изменения и условия обратного перехода. Фраза «Всего на 600 рублей дороже» не заменяет этих сведений. Бесплатная проба расширенных функций тоже требует ясного правила окончания.

Свяжите предложение с задачей

Удачное сообщение объясняет наблюдаемую ситуацию без категоричных догадок: «За последние два периода объём выгрузок достигал лимита. В плане X доступен такой-то объём». Затем показывает возможность проверить, нужен ли переход. Формулировка «Ваша команда выросла» неуместна, если единственное основание — несколько приглашений в продукт.

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

Оценивайте дополнительную пользу

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

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

Источники

Stripe. Prorations. Stripe Documentation. Проверено 23.09.2026.