Клиент оплатил следующий месяц, менеджер закрыл сделку, но объявление на площадке всё равно исчезло. Либо услуга продолжает работать, хотя срок закончился и оплата не пришла. В обоих случаях CRM помнит продажу, но не управляет переходом между периодами обслуживания.
Продление подписки — это цепочка из нескольких разных событий: наступает срок переговоров, согласуются условия, поступает оплата, активируется новый период. Если свести всё к одному напоминанию, система вовремя сообщит о проблеме, но не поможет проверить, что она решена.
Сначала определяют объект услуги. У одного клиента могут быть несколько объектов размещения, лицензий, договоров или точек обслуживания с разными датами. Продлевать контакт целиком нельзя: оплата одной подписки не должна менять срок остальных.
Для объекта хранят текущий оплаченный период, планируемый следующий, тариф и правила изменения срока. Условия могут зависеть от календарного месяца, фиксированного числа дней или даты активации. Их нельзя смешивать: прибавление тридцати дней не всегда означает следующий календарный месяц.
В Битрикс24 есть роботы для повторных продаж и копирования сделок. Их настройки описаны в документации . Но копирование полей ещё не обеспечивает правильную модель подписки: в новую карточку могут перейти старый срок, разовая скидка или уже выполненное действие.
Практически полезно создавать запись следующего периода по устойчивому ключу «объект услуги + период». Тогда повторный запуск не создаст вторую работу на то же продление. Если клиент отказывается, сохраняют причину и закрывают именно этот период, а не удаляют сведения о прошлой услуге.
Отдельная сделка удобна для переговоров и аналитики продаж. Реестр периодов нужен для понимания действующей услуги. Иногда он реализуется смарт-процессом, иногда остаётся во внешнем сервисе, а CRM показывает его состояние. Выбор зависит от продукта и доступных инструментов, а не от универсального требования создать ещё одну воронку.
За сколько дней начинать продление, определяют по реальному циклу согласования. Корпоративный договор может требовать проверки закупочной службы, а простая подписка — короткого подтверждения. Всем клиентам не подходит одинаковая цепочка писем в одинаковые дни.
У менеджера должна появиться конкретная задача: проверить состав услуги, подтвердить контакт для документов, согласовать условия или выяснить причину отказа. Если письмо ушло, но ответа нет, запись остаётся в работе. Отправка уведомления не является подтверждением согласия клиента.
Передача клиента другому сотруднику не должна заново запускать всю цепочку сообщений. Сохраняют историю доставленных уведомлений и дату следующего действия. При нескольких каналах связи учитывают предпочтения клиента и принятые правила коммуникации, а не дублируют одно требование во всех доступных мессенджерах.
Новый период включается на основании согласованного правила: подтверждённой оплаты, постоплатного договора или отдельного разрешения ответственного. Недостаточно поставить «успешно» в воронке. Если услуга работает на сайте или внешней платформе, нужен результат операции активации именно там.
Это условный пример внутренней модели, не готовый формат API. Он показывает важную ситуацию: деньги уже подтверждены, но включение ещё не удалось. Повторная попытка должна завершить активацию того же периода, а не списать деньги снова или создать новую подписку.
При интеграции фиксируют внешний идентификатор операции и её результат. Если ответ потерялся, сначала проверяют фактический срок в целевой системе. Слепое повторное «добавить месяц» может продлить услугу дважды. Лучше передавать конкретный желаемый период или использовать согласованный механизм защиты от повторов.
Следующий период может отличаться от текущего: изменились число объектов, тариф, набор опций или сторона договора. Эти условия сохраняют явно. Иначе автоматическое копирование восстановит старую стоимость, хотя менеджер уже договорился о другой комплектации.
При ранней оплате нужно определить, новый срок начинается сразу или после текущего. При приостановке — переносится ли окончание и кто подтверждает возобновление. При отказе — что происходит с доступом и данными. Это правила конкретной услуги; CRM должна исполнять согласованную политику, а не изобретать её по стадии сделки.
Полезно разделить отказ от продления, неоплату и технический сбой включения. Они требуют разных действий: выяснить причину ухода, обсудить расчёты или восстановить работу. В одной общей стадии «не продлено» руководитель не увидит, почему услуга прекратилась.
— По одному объекту и периоду существует одна актуальная работа на продление.
— Досрочная оплата не обрезает уже оплаченный срок.
— Отказ по следующему месяцу не меняет историю предыдущего.
— Потерянный ответ платформы не приводит к двойному продлению.
— Изменение тарифа попадает в согласованный период, а не в старые документы.
— Оплаченная, но неактивированная услуга видна отдельным списком.
Пилот проверяют на нескольких объектах одного клиента, на переходе месяцев разной длины и на неудачной активации. Отчёт по повторной выручке сверяют с реестром действующих периодов. Закрытая сделка без включённой услуги не должна выглядеть завершённым продлением.
Можно просто копировать успешную сделку раз в месяц? #
Для простого напоминания этого иногда достаточно. Для управления услугой нужно дополнительно определить период, обработку повторов, оплату и подтверждение активации. Иначе появится отчёт о продажах, который расходится с фактическим обслуживанием.
Сравнить объекты с заканчивающимся периодом, открытые работы на продление и подтверждённые следующие периоды. Один список просроченных задач недостаточен: задача могла быть закрыта, хотя продление так и не состоялось.
Если сроки живут в таблицах, а оплата и включение проверяются вручную, NetLab поможет настроить бизнес-процесс в Битрикс24 : периоды, повторные сделки, контроль оплаты и результат активации. Обсудить вашу подписочную модель — укажите, что продлевается и в какой системе фактически включается услуга.
