Битрикс24 для SaaS-компании: подписки, тарифы, продление и отток клиентов

Чем SaaS отличается от обычных продаж в CRM

Классическая CRM-воронка заканчивается победой в сделке. В SaaS закрытие продажи — это только начало: дальше активация, использование продукта, продление, апгрейд тарифа или отток. Стандартная воронка Битрикс24 под это не заточена, но её можно адаптировать.

Вот в чём принципиальная разница подписной модели — она и определяет логику настройки CRM:

Параметр	Разовые продажи	SaaS / подписка
Жизненный цикл клиента	Завершается оплатой	Продолжается ежемесячно/ежегодно
Главный риск	Не закрыть сделку	Потерять активного клиента
Ключевые события	Лид → Сделка	Активация → Продление → Апгрейд
Нужная автоматизация	Напоминания менеджеру	Авто-триггеры по датам и событиям

Именно поэтому воронки «Лиды» и «Сделки» сами по себе не справляются: нужна отдельная логика учёта подписок, тарифов и дат продления.

Как структурировать данные о подписках

Базовая единица учёта в Битрикс24 — карточка сделки или смарт-процесс. Для SaaS лучше сразу разделить два потока:

• Воронка первичных продаж — стандартные сделки CRM, от лида до первой оплаты.
• Реестр подписок — отдельный смарт-процесс, где каждая запись соответствует одному активному клиенту.

В карточке подписки через пользовательские поля фиксируют:

• Текущий тариф (список: Free / Starter / Pro / Enterprise)
• Дата начала подписки
• Дата следующего продления
• Сумма ежемесячного/ежегодного платежа
• Статус (активна / приостановлена / отменена)
• Количество пользователей в аккаунте клиента
• Канал привлечения — для когортного анализа

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

Воронка удержания: стадии и переходы

Параллельно с реестром подписок настраивают отдельную воронку удержания. Она включается в двух случаях: когда приближается дата продления и когда появляются первые сигналы оттока.

На схеме ниже — движение клиента по воронке: от автоматического триггера за 30 дней до финального статуса.

flowchart TD
    A[Дата продления через 30 дней] --> B[Авто-задача менеджеру]
    B --> C{Клиент ответил?}
    C -- Да --> D[Оформление продления / апгрейда]
    C -- Нет --> E[Повторное касание через 7 дней]
    E --> F{Ответ получен?}
    F -- Да --> D
    F -- Нет --> G[Передача в воронку риска оттока]
    G --> H{Удержали?}
    H -- Да --> D
    H -- Нет --> I[Статус: Отток. Смарт-процесс закрыт]
    D --> J[Подписка продлена. Дата обновлена]

Типовые стадии воронки удержания:

1. Ожидание продления — клиент за 30 дней до окончания подписки
2. В работе — менеджер вышел на контакт, идёт диалог
3. Риск оттока — нет ответа больше 14 дней или прямой отказ
4. Апгрейд — клиент переходит на более высокий тариф
5. Продлён — оплата прошла, дата в реестре обновлена
6. Отток — подписка не продлена, причина зафиксирована

Автоматизация напоминаний о продлении

Роботы в Битрикс24 запускают цепочки действий по дате поля — в нашем случае по полю «Дата следующего продления». По нашей практике, минимально рабочая цепочка для SaaS выглядит так:

• За 30 дней — автоматически создаётся задача ответственному менеджеру: связаться с клиентом, уточнить планы по продлению.
• За 14 дней — если задача не закрыта и изменений по сделке нет, ставится повторная задача и уведомление уходит руководителю.
• За 7 дней — клиенту автоматически отправляется письмо или сообщение через открытые линии (WhatsApp, Telegram, email).
• В день окончания — статус смарт-процесса меняется на «Риск оттока», если продление так и не зафиксировано.

О том, как настраивать триггеры и роботов для таких цепочек, подробно написано в статье про роботы и триггеры в воронке Битрикс24.

Учёт тарифов и сегментация базы

Тариф клиента — ключевое поле для сегментации. На его основе можно:

• Назначать разных ответственных: корпоративных клиентов на Enterprise ведёт выделенный аккаунт-менеджер, остальные — в общей очереди.
• Настраивать разные цепочки автоматизации. Клиентам на Free уходит серия писем с предложением апгрейда, платным — персональный звонок.
• Строить отчёты по MRR в разрезе тарифов через дашборды Битрикс24.

Для сегментации достаточно настроить фильтры в списке смарт-процесса и сохранить их как именованные представления. Руководитель видит актуальный срез по каждому тарифу в реальном времени — без выгрузок и сводных таблиц.

Контроль оттока: сигналы и реакция

Отток редко случается внезапно — обычно ему предшествуют слабые сигналы. В Битрикс24 их выявление можно автоматизировать.

Поведенческие триггеры (через вебхуки):

• Клиент не заходил в продукт более N дней → вебхук передаёт событие в Битрикс24 → создаётся задача менеджеру.
• Количество активных пользователей в аккаунте снизилось → обновляется поле в карточке → запускается робот.

Коммуникационные сигналы:

• Открытое обращение в поддержку с жалобой — оно связывается с карточкой клиента, ответственный получает уведомление.
• Нет ответа на два последних касания → автоматический перевод в стадию «Риск оттока».

Для передачи событий из вашего SaaS-продукта в Битрикс24 используют вебхуки смарт-процессов: поля карточки обновляются и автоматизации запускаются без ручного ввода.

Аналитика подписной базы в Битрикс24

Стандартные отчёты CRM дополняются пользовательскими срезами. Для SaaS обычно нужны следующие:

Отчёт	Что показывает	Как реализовать
Продления на ближайшие 30 дней	Список клиентов с датой продления в периоде	Фильтр по полю «Дата продления»
Отток за период	Количество и сумма закрытых отменой подписок	Смарт-процесс, стадия «Отток»
Тарифный срез	Распределение базы по тарифам	Группировка по полю «Тариф»
Апгрейды	Клиенты, сменившие тариф на более высокий	История изменений поля «Тариф»
NRR / расширение выручки	Суммарный прирост за счёт апгрейдов	Кастомный отчёт по сумме сделок

Часть отчётов строится штатными средствами, часть требует доработки через API или приложения из маркетплейса Битрикс24.

С чего начать внедрение

Мы видим примерно одну и ту же последовательность в большинстве подобных проектов:

1. Описание бизнес-процессов — фиксируем логику жизненного цикла клиента, стадии подписки, правила эскалации.
2. Проектирование структуры данных — определяем поля карточек, списки тарифов, правила именования.
3. Настройка воронок и смарт-процессов — первичные продажи и реестр подписок настраиваются отдельно, они не должны мешать друг другу.
4. Автоматизация — роботы по датам, триггеры по изменению полей, цепочки уведомлений.
5. Интеграция с продуктом — передача событий активности через вебхуки или REST API.
6. Обучение команды — менеджеры по продлениям и аккаунт-менеджеры работают с разными представлениями, это нужно проговорить отдельно.

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

Частые вопросы

Можно ли вести подписки прямо в сделках CRM, без смарт-процессов? Технически — да, но неудобно. Сделка в Битрикс24 привязана к одному переходу по воронке. Для подписок нужна запись, которая живёт долго, меняет статус и обновляет даты — для этого смарт-процесс подходит лучше.

Как передавать данные об активности пользователей из нашего продукта в Битрикс24? Через вебхуки или REST API. Ваш продукт отправляет событие (например, «пользователь не заходил 14 дней») — Битрикс24 принимает его, обновляет поле в карточке и при необходимости запускает робота.

Можно ли считать MRR и churn rate прямо в Битрикс24? MRR — да, через кастомные отчёты по полю «Сумма подписки» в смарт-процессе. Churn rate в классическом виде потребует либо доработки через API, либо выгрузки в BI-систему: в Битрикс24 нет встроенного расчёта этой метрики.

Сколько времени занимает настройка такой системы? Зависит от сложности процессов и количества интеграций. Базовая конфигурация — реестр подписок, воронка удержания и цепочки роботов — занимает от 20 до 40 часов. Интеграция с продуктом через API добавляет ещё 15–30 часов в зависимости от объёма передаваемых событий.