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

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

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

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

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

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

Базовая единица учёта в Битрикс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 обычно нужны следующие:

Часть отчётов строится штатными средствами, часть требует доработки через 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 часов в зависимости от объёма передаваемых событий.

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