Клиент раз в месяц заказывает у вас корм для питомца, кофе или расходники для офиса. Каждый раз он заходит на сайт, ищет те же позиции, заново оформляет заказ и оплачивает. В какой-то момент ему проще подписаться на конкурента, который сам напоминает и привозит по расписанию. Разовые продажи требуют повторного «завоевания» клиента снова и снова, а подписка превращает его в источник предсказуемой выручки.
В этой статье разберём, как реализовать подписочную модель и регулярные заказы в магазине на 1С-Битрикс: чем подписка отличается от регулярного заказа, как устроены рекуррентные платежи, как автоматически создавать повторные заказы агентами, что дать клиенту в личном кабинете и как связать всё это с остатками и учётом в 1С. Выстроить автоматическую генерацию заказов и обмен помогает наша автоматизация продаж и склада на 1С.
Коротко
- Подписка — это модель отношений с автосписанием и продлением; регулярный заказ — повторяющаяся отгрузка по расписанию.
- Рекуррентные платежи требуют поддержки провайдера, согласий клиента и уведомлений о списаниях.
- Повторные заказы создаются агентами Битрикс по расписанию на основе шаблона подписки.
- Клиенту нужен простой контроль в кабинете: пауза, пропуск, смена состава и лёгкая отмена.
Зачем магазину подписка
Экономика подписки принципиально отличается от разовых продаж. В разовой модели вы каждый раз заново тратите маркетинговый бюджет, чтобы вернуть клиента. В подписочной — один раз привлекаете, а дальше получаете повторяющуюся выручку без затрат на повторное привлечение. Пожизненная ценность клиента растёт, а прогноз выручки становится предсказуемым.
Подписка подходит не всем товарам, но там, где потребление регулярное и предсказуемое, она работает отлично: расходники, продукты повседневного спроса, товары для животных, косметика, B2B-поставки материалов. Для покупателя это удобство и часто экономия, для магазина — удержание, стабильность и защита от ухода к конкурентам. Именно поэтому подписка — один из самых сильных инструментов удержания в e-commerce.
Подписка и регулярный заказ: разница
Термины часто путают, но за ними разные механики, и это влияет на реализацию.
| Аспект | Регулярный заказ | Подписка |
|---|---|---|
| Суть | Повтор отгрузки по расписанию | Модель отношений с продлением |
| Оплата | Может быть по каждому заказу | Часто рекуррентная, автосписание |
| Цена | Обычная | Часто льготная за регулярность |
| Управление | Расписание поставок | Тариф, продление, пауза, отмена |
На практике полноценная подписка включает в себя регулярные заказы плюс слой управления тарифом, оплатой и продлением. Можно начать с простого регулярного заказа (клиент выбирает периодичность повторной поставки) и постепенно нарастить его до подписки с автосписанием и льготными ценами. Такой поэтапный подход снижает риск и позволяет проверить спрос.
Модели подписки в e-commerce
Прежде чем строить механику, определитесь с моделью — от неё зависит и логика, и коммуникация с клиентом.
- Пополнение (replenishment). Клиент подписан на регулярную поставку одних и тех же товаров — корм, кофе, расходники. Самая частая модель для товарных магазинов.
- Курирование (curation). Каждый цикл клиент получает подобранный набор — коробка новинок, сезонный набор. Больше про впечатление, чем про повтор.
- Доступ (access). Подписка даёт привилегии: бесплатную доставку, спеццены, приоритет. Классический пример — премиум-членство.
- B2B-контракт. Регулярная поставка материалов или товаров по договору с согласованной периодичностью и ценами.
Для большинства товарных магазинов на старте разумна модель пополнения — она понятна клиенту и проще в реализации. Остальные модели можно добавлять, когда базовая механика подписки уже отлажена.
Рекуррентные платежи
Сердце автоматической подписки — рекуррентные платежи, то есть списание без участия клиента в каждом цикле. Один раз покупатель соглашается на регулярные списания и привязывает карту, дальше платежи проходят сами.
- Первичная привязка. При оформлении подписки клиент проходит платёж, в ходе которого карта привязывается для будущих списаний.
- Согласие. Явно фиксируется согласие на регулярные списания с указанием суммы и периодичности.
- Списание по расписанию. В нужный момент система инициирует платёж через провайдера по сохранённому токену карты.
- Уведомление. Клиента заранее и по факту информируют о предстоящем и прошедшем списании.
Ключевое ограничение: рекуррент должен поддерживаться платёжным провайдером, и работать нужно с токеном карты, а не хранить её данные у себя. Безопасную интеграцию с платёжным шлюзом и обработку колбэков о статусе платежа строят через защищённый слой — принципы такой работы мы описываем в статье про REST, вебхуки и безопасность в Битрикс.
Автосоздание заказов агентами
Регулярный заказ должен создаваться сам, без ручного участия менеджера. В 1С-Битрикс штатный механизм для таких фоновых задач — агенты и планировщик.
Логика такая: агент по расписанию перебирает активные подписки, находит те, у которых подошёл срок очередной поставки, и создаёт новый заказ на основе шаблона подписки (состав, адрес, способ оплаты и доставки). Важные принципы надёжной реализации:
- Запуск на cron. Агенты лучше запускать по расписанию сервера, а не на хитах посетителей — иначе на сайте без трафика заказы не создадутся вовремя.
- Идемпотентность. Повторный запуск агента не должен создавать дубли заказов за один цикл.
- Вынесенная логика. Создание заказа выносят в отдельный сервис, который можно тестировать и переиспользовать.
- Логирование. Каждый цикл фиксируется, чтобы было видно, какие заказы созданы и где возникли сбои.
Такую фоновую механику удобно проектировать на современном стеке Битрикс с ORM и сервисным слоем — как это устроено, мы разбираем в статье про D7 ORM в Битрикс.
Личный кабинет и управление
Подписка живёт или умирает в личном кабинете. Если управлять ею неудобно, клиент отменит подписку целиком вместо того, чтобы поставить на паузу. Дайте покупателю полный и простой контроль.
- Пауза и возобновление. Уехал в отпуск — приостановил, вернулся — продолжил, без потери подписки.
- Пропуск поставки. Ещё не закончился прошлый запас — пропустил один цикл.
- Изменение состава и периодичности. Добавить или убрать товар, сделать поставки чаще или реже.
- Смена адреса и оплаты. Обновить карту, адрес доставки, способ.
- Лёгкая отмена. Понятная отмена в пару кликов — да, даже если жаль терять клиента.
Парадокс, но простая отмена повышает лояльность: клиент подписывается охотнее, зная, что не окажется в ловушке. А тот, кто ушёл легко, чаще возвращается. Скрытая отмена, наоборот, оборачивается спорами по платежам и репутационными потерями.
Обработка неудачных списаний
Рекуррентные платежи иногда не проходят: не хватило средств, истёк срок карты, банк отклонил операцию. Как система реагирует на это — вопрос не технический, а денежный, потому что от него зависит, потеряете вы клиента или нет.
- Повторные попытки. Несколько списаний по расписанию (например, через день, три, семь) — часто проблема временная.
- Уведомления. Клиента извещают о неудаче и просят обновить карту, а не молча отменяют подписку.
- Статус ожидания. Заказ ставится в ожидание оплаты или подписка на паузу, но не удаляется.
- Мягкое завершение. Если оплата так и не прошла после всех попыток, подписку приостанавливают с понятным сообщением.
Такая работа с «отвалившимися» платежами (её называют dunning) спасает значительную долю подписок, которые иначе потерялись бы из-за банальной просроченной карты. Это одна из самых окупаемых деталей подписочной механики.
Связь с остатками и 1С
Автосозданный заказ — это обычный заказ, и он должен встраиваться в те же процессы, что и разовый: резерв товара, обмен с 1С, учёт продаж. Иначе подписка «нарисует» заказы, которых не может обеспечить склад.
Поэтому при генерации регулярного заказа система проверяет наличие. Если товара нет, клиента предупреждают заранее и предлагают замену или перенос поставки, а не отгружают воздух. Сам заказ уходит в 1С через штатный обмен CommerceML так же, как разовый, и учитывается в остатках и продажах. Как выстроить надёжный обмен без потерь и дублей — тема нашей автоматизации продаж и склада, а если магазин уже работает, но обмен сбоит, начинаем с аудита и оптимизации 1С.
Реализация на 1С-Битрикс пошагово
Соберём картину в последовательность внедрения на 1С-Битрикс. Названия сущностей зависят от архитектуры проекта, но логика общая:
- Заведите сущность подписки. Храните шаблон: клиент, состав, периодичность, адрес, способ оплаты, статус.
- Подключите рекуррент. Интеграция с платёжным провайдером, поддерживающим списания по токену карты, с фиксацией согласия.
- Настройте агента генерации. Фоновая задача на cron находит подписки к отгрузке и создаёт заказы идемпотентно.
- Свяжите с проверкой наличия. Перед созданием заказа — проверка остатков и логика замены/переноса.
- Соберите кабинет управления. Пауза, пропуск, смена состава и оплаты, отмена в пару кликов.
- Добавьте dunning. Повторные попытки списания и уведомления при неудаче.
- Настройте обмен с 1С. Регулярные заказы уходят в учёт наравне с разовыми.
- Протестируйте цикл. Пройдите полный оборот: подписка → списание → заказ → отгрузка → продление.
Поскольку это заметная доработка над стандартным магазином, её обычно ведут как проект автоматизации с отдельным сервисным слоем поверх штатного модуля «Интернет-магазин». Такой подход держит логику подписки изолированной и тестируемой, а не размазанной по шаблонам.
Удержание и метрики подписки
Подписка — это про удержание, поэтому и мерить её нужно метриками удержания, а не только разовыми продажами.
- Отток (churn). Доля клиентов, отменивших подписку за период, — главный индикатор здоровья модели.
- Пожизненная ценность (LTV). Сколько приносит клиент за всё время подписки.
- Доля паузы против отмены. Если люди чаще ставят на паузу, чем отменяют, — механика управления работает.
- Восстановленные платежи. Сколько подписок спас dunning после неудачных списаний.
Работайте с оттоком точечно: анализируйте причины отмен, предлагайте паузу вместо отмены, восстанавливайте просроченные карты. Небольшое снижение оттока даёт кратный рост LTV, потому что эффект накапливается по всей базе подписчиков.
Частые ошибки
- Агенты на хитах. Заказы не создаются вовремя на сайте без трафика; нужен запуск на cron.
- Дубли заказов. Неидемпотентный агент создаёт по несколько заказов за цикл.
- Скрытая отмена. Сложная отмена рождает споры по платежам и жалобы в банк.
- Нет обработки неудачных списаний. Подписку отменяют при первой же ошибке карты вместо повторных попыток.
- Игнор остатков. Регулярный заказ создаётся на товар, которого нет на складе.
- Хранение данных карт. Попытка хранить реквизиты вместо токена — риск и нарушение требований.
- Нет уведомлений о списаниях. Неожиданные платежи злят клиентов и ведут к возвратам.
Чек-лист внедрения
- Модель выбрана. Определён тип подписки: пополнение, курирование, доступ или B2B-контракт.
- Сущность подписки заведена. Хранит состав, периодичность, оплату, адрес и статус.
- Рекуррент подключён. Списания по токену карты с фиксацией согласия и уведомлениями.
- Агент генерации на cron. Заказы создаются вовремя, идемпотентно, с логированием.
- Проверка наличия. Перед созданием заказа — контроль остатков и логика замены.
- Кабинет управления. Пауза, пропуск, смена состава и оплаты, лёгкая отмена.
- Dunning работает. Повторные попытки и уведомления при неудачных списаниях.
- Обмен с 1С и метрики. Заказы уходят в учёт, отток и LTV измеряются.
Вывод
Подписка и регулярные заказы превращают разовые продажи в предсказуемую повторяющуюся выручку и резко усиливают удержание. Технически это сочетание нескольких механик: рекуррентных платежей по токену карты, автосоздания заказов агентами на cron, гибкого управления в личном кабинете и грамотной обработки неудачных списаний.
На 1С-Битрикс всё это реализуется как отдельный слой поверх штатного магазина, тесно связанный с проверкой остатков и обменом с 1С. Начните с простой модели пополнения и лёгкого управления подпиской, добавьте dunning для спасения просроченных карт — и подписка станет одним из самых устойчивых источников дохода вашего магазина.
