Покупатель нашёл нужный товар, открыл карточку — а там серое «Нет в наличии». В большинстве магазинов на этом история заканчивается: человек закрывает вкладку и идёт искать дальше. Но спрос-то был, живой и оплатоспособный, и вы его только что потеряли, ничего не получив взамен. Функция «Сообщить о поступлении» разворачивает этот сценарий: вместо тупика — форма, вместо ухода — контакт, вместо потерянной продажи — отложенный заказ.
В этом гайде разберём, как спроектировать подписку на поступление в интернет-магазине на 1С-Битрикс правильно: от формы в карточке до триггера по остаткам из 1С, от письма до антиспама и аналитики. Материал опирается на нашу практику автоматизации на 1С и обмена данными между учётной системой и сайтом.
Коротко
- Подписка на поступление превращает нулевой остаток в зафиксированный спрос и точку контакта.
- Ядро функции — триггер «остаток стал больше нуля», который ловят по данным обмена с 1С.
- Обязательны порог срабатывания и очередь, иначе уведомление уйдёт всем при поступлении одной штуки.
- Письма требуют корректных SPF/DKIM/DMARC и антиспам-логики, иначе не дойдут до подписчика.
Зачем магазину подписка на поступление
Отсутствие товара на складе — не редкость, а норма для любого живого ассортимента: сезонность, задержки поставок, распродажи. Вопрос не в том, как избежать нулевых остатков, а в том, что происходит с трафиком, который на эти остатки приходит. Без подписки этот трафик просто утекает: посетитель видит «нет в наличии» и уходит, а вы даже не узнаёте, сколько людей хотели купить.
Подписка на поступление решает три задачи сразу. Она удерживает спрос — вы получаете список тех, кто ждёт конкретный товар. Она даёт данные для закупок — по числу подписок видно, что и в каком объёме стоит заказать у поставщика. И она возвращает покупателя в нужный момент — когда товар появился и готов к продаже. Это одна из самых окупаемых функций магазина именно потому, что работает с уже существующим, но теряемым спросом.
Как это выглядит для покупателя
Со стороны пользователя сценарий должен быть предельно коротким. В карточке товара без остатка вместо кнопки «В корзину» показывается кнопка «Сообщить о поступлении». По клику открывается компактная форма — по сути одно поле e-mail (для авторизованного клиента почта подставляется автоматически). После отправки — понятное подтверждение: «Мы напишем вам, как только товар появится».
- Минимум полей. Один e-mail, максимум — выбор канала. Каждое лишнее поле снижает конверсию подписки.
- Ясное обещание. Покупатель должен понимать, что именно и когда произойдёт.
- Защита от повтора. Если человек уже подписан, форма сообщает об этом, а не создаёт дубль.
- Мгновенная реакция. Отправка через AJAX без перезагрузки страницы — покупатель остаётся в карточке.
Что происходит под капотом
За простой формой стоит цепочка из нескольких звеньев, и надёжность функции определяется самым слабым из них. Схематично поток такой: покупатель оставляет подписку, она сохраняется в хранилище со статусом «активна»; параллельно из 1С регулярно приходят остатки; когда остаток товара становится положительным, срабатывает триггер, который выбирает активные подписки по этому товару и ставит их в очередь на отправку; подписчик получает письмо, а подписка помечается как отработанная.
Ключевое проектное решение — где именно ловить момент появления остатка. Есть два подхода: реактивный (обработчик события на изменение цены/остатка) и периодический (агент, который раз в N минут сверяет активные подписки с текущими остатками). У каждого свои плюсы, и выбор зависит от того, как устроен ваш обмен с 1С. Разберём это ниже.
Модель данных подписки
Подписка — это запись, связывающая товар, контакт покупателя и статус. От того, как спроектирована эта модель, зависит и скорость выборок, и возможность масштабирования. На небольших магазинах подписки ведут в инфоблоке или highload-блоке; на крупных — в отдельной таблице через D7 ORM с индексами.
| Поле | Назначение | Пример |
|---|---|---|
| ID товара / SKU | На что подписка | ID элемента или торгового предложения |
| Контакт | Куда слать | e-mail, Telegram chat_id |
| Канал | Способ доставки | email / telegram / sms |
| Статус | Стадия обработки | активна / отправлена / отписан |
| Дата создания | Очередь и аналитика | timestamp |
| Дата отправки | Факт уведомления | timestamp |
Для крупного каталога и высоких объёмов подписок собственная ORM-таблица предпочтительнее: индекс по паре «товар + статус» позволяет мгновенно выбирать активные подписки при появлении остатка. Как грамотно проектировать такие сущности штатными средствами платформы, мы разбираем в статье про D7 ORM в Битрикс.
Триггер: как ловить появление остатка
Сердце функции — момент, когда «было 0, стало больше 0». Поймать его можно двумя способами, и выбор влияет на надёжность и нагрузку.
- Реактивный триггер. Вешаем обработчик на событие изменения остатка/доступности элемента. Как только количество товара обновилось и стало положительным — сразу проверяем, есть ли по нему активные подписки, и ставим их в очередь. Быстрая реакция, но обработчик должен корректно ловить именно переход через ноль.
- Периодический агент. Агент раз в несколько минут выбирает товары с активными подписками, сверяет их текущие остатки и по перешедшим в наличие запускает рассылку. Проще и устойчивее к особенностям обмена, но уведомление приходит с задержкой в интервал агента.
На практике часто выбирают агент: обмен с 1С обновляет остатки пакетно, и ловить каждое отдельное изменение обработчиком сложнее, чем раз в 5–10 минут пройтись по списку ожидаемых товаров. Работу агентов в Битрикс важно настроить на cron, а не на «хиты», иначе рассылка будет зависеть от посещаемости. Тонкости фоновых процессов и деплоя таких механизмов мы описывали в материале про CI/CD и деплой на Битрикс.
Остатки из 1С и обмен CommerceML
Вся функция стоит на данных об остатках, а они приходят на сайт из учётной системы. В типовой связке 1С выгружает остатки по складам через обмен CommerceML, и Битрикс обновляет количества у товаров и торговых предложений. Значит, точность и своевременность уведомлений напрямую зависят от качества этого обмена: если остатки выгружаются раз в сутки, то и «товар появился» магазин узнает не раньше следующей выгрузки.
Несколько принципов, чтобы триггер работал предсказуемо:
- Учитывайте нужный склад. Товар может появиться на складе, с которого вы не отгружаете розницу, — триггер должен смотреть на остаток релевантного склада.
- Различайте «доступно» и «просто есть». Резервы, брак, товар в пути — не всё, что лежит на складе, доступно к продаже.
- Частота выгрузки. Чем чаще обмен приносит остатки, тем свежее уведомления. Для ходовых товаров это критично.
Настройка стабильного и достаточно частого обмена остатками — задача уровня учётной системы, и мы решаем её в рамках автоматизации продаж и склада на 1С. Без корректных остатков любая логика уведомлений теряет смысл.
Порог срабатывания и очередь рассылки
Самая частая ошибка проектирования — разослать уведомление всем подписчикам мгновенно, как только остаток стал положительным. Представьте: на товар подписалось 200 человек, а поставка пришла в количестве 3 штук. Уведомление уходит всем 200, из них 197 откроют карточку и снова увидят «нет в наличии» — и это раздражает сильнее, чем изначальное отсутствие.
Защита от этого — два механизма:
- Порог срабатывания. Уведомлять только когда остаток превысил заданное число (например, не меньше числа подписок или фиксированного минимума), а не при первой же единице.
- Очередь и волны. Рассылать не всем сразу, а порциями — первой волне, затем при подтверждении остатка следующей. Опционально — резервировать товар за перешедшими по ссылке на короткое время.
Логика резерва и приоритетов упирается в учётную систему: чтобы «придержать» товар за подписчиком, резерв должен корректно отражаться в 1С. Такие сквозные сценарии мы проектируем в связке сайта и учёта в рамках автоматизации бизнес-процессов на 1С.
Письмо: содержание и доставляемость
Уведомление сработает только если письмо дойдёт и его откроют. Содержание должно быть коротким и по делу: товар снова в наличии, его фото и название, актуальная цена и одна заметная кнопка «Купить». Никаких длинных подборок «а ещё вам понравится» — человек ждал конкретную позицию.
Техническая доставляемость не менее важна, чем текст:
- SPF, DKIM, DMARC. Без корректных записей на домене отправителя письма массово уходят в спам.
- Отдельный транспорт. Транзакционные уведомления лучше слать через надёжный SMTP или сервис доставки, а не через локальный sendmail сервера.
- Заметная цена и наличие на момент письма. Если цена изменилась, покажите актуальную — расхождение с карточкой бьёт по доверию.
- Явная отписка. Ссылка «больше не уведомлять» в каждом письме — это и вежливость, и требование закона.
Каналы: e-mail, Telegram, SMS
E-mail — базовый канал, но не единственный. Часть аудитории охотнее подпишется на уведомление в мессенджер, и открываемость там заметно выше. Архитектурно это решается через понятие «канал» у подписки: сама подписка на товар одна, а способов доставки уведомления может быть несколько.
| Канал | Плюсы | Ограничения |
|---|---|---|
| Универсален, дёшев, есть у всех | Ниже открываемость, риск спама | |
| Telegram | Высокая открываемость, мгновенно | Нужен бот и подписка на него |
| SMS | Доходит почти всегда | Платно за сообщение, нужен согласие |
Отправка в мессенджеры и внешние сервисы обычно идёт через их API. Если каналов много, логику отправки удобно вынести в отдельный сервис, который принимает событие «товар поступил» и рассылает по нужным транспортам. Как безопасно организовать такие внешние вызовы, мы разбираем в статье про REST, вебхуки и безопасность в Битрикс.
Согласия, антиспам и 152-ФЗ
Подписка на товар — это сбор персональных данных (как минимум e-mail), поэтому она попадает под требования законодательства о персональных данных. Правила простые, но их нельзя игнорировать: у формы должно быть согласие на обработку данных и ссылка на политику конфиденциальности, а использовать собранные адреса можно только по назначению — уведомить о поступлении, а не добавить в общую рассылку.
- Согласие при подписке. Явный чекбокс или текст согласия рядом с кнопкой отправки.
- Только по назначению. Адрес собран ради уведомления о товаре — не шлите на него акции без отдельного согласия.
- Отписка и удаление. Возможность отписаться в один клик и удалить данные по запросу.
- Частотный контроль. Одно письмо на факт поступления, без серий «напоминалок».
Аналитика и метрики эффективности
Функция должна приносить измеримый результат, иначе непонятно, работает ли она. Заведите учёт ключевых метрик и смотрите на них регулярно. Число подписок по товарам — это ещё и подсказка отделу закупок: если на позицию подписались десятки человек, её стоит заказать в большем объёме.
- Подписок создано. Сколько людей ждут товары — общий объём отложенного спроса.
- Уведомлений отправлено. Сколько подписок сработало при поступлении.
- Возвратов и заказов. Сколько подписчиков вернулись по письму и купили — главная метрика окупаемости.
- Топ ожидаемых товаров. Что чаще всего ждут — сигнал для закупок и планирования.
Связка этих данных с учётной системой позволяет закупать точнее и не морозить деньги в товаре, который никто не ждёт. Настройку такой сквозной аналитики и её интеграцию с 1С мы закладываем при аудите и оптимизации 1С.
Частые ошибки
- Уведомление всем сразу. При поступлении одной штуки письмо уходит сотне подписчиков — большинство снова видит «нет в наличии».
- Триггер на хитах. Агент рассылки завязан на трафик, ночью без посетителей уведомления не уходят.
- Игнор нужного склада. Товар появился на неотгружаемом складе, а покупателя уже позвали.
- Плохая доставляемость. Нет SPF/DKIM — письма улетают в спам, функция «работает», но результата нет.
- Дубли подписок. Один человек подписался пять раз и получает пять одинаковых писем.
- Нет отписки и согласия. Нарушение 152-ФЗ и раздражение пользователей.
- Устаревшая цена в письме. В письме одна цена, в карточке другая — падает доверие.
Чек-лист внедрения
- Форма в карточке. Кнопка «Сообщить о поступлении» вместо «В корзину» для товаров без остатка, отправка через AJAX.
- Хранилище подписок. Модель с полями товар, контакт, канал, статус, даты; индекс по «товар + статус».
- Триггер настроен. Агент на cron или обработчик события ловит переход остатка через ноль.
- Остатки из 1С. Обмен приносит актуальные остатки нужного склада с достаточной частотой.
- Порог и очередь. Уведомление уходит при достаточном остатке и порциями, а не всем сразу.
- Доставляемость. SPF, DKIM, DMARC настроены; письма идут через надёжный транспорт.
- Согласия. Чекбокс согласия, ссылка на политику, отписка в один клик.
- Аналитика. Считаются подписки, отправки и заказы; топ ожидаемых товаров уходит в закупки.
Вывод
«Сообщить о поступлении» — это не второстепенная кнопка, а инструмент возврата спроса, который иначе просто теряется. Правильно спроектированная подписка превращает нулевой остаток в зафиксированный интерес, даёт данные для закупок и возвращает покупателя ровно в тот момент, когда товар готов к продаже.
Ключ к надёжности — в двух местах: в триггере, который точно ловит появление остатка по данным из 1С, и в дисциплине рассылки, где порог и очередь спасают от массового «снова нет в наличии». Настройте эти два узла аккуратно, свяжите функцию с корректным обменом остатками — и одна из самых окупаемых механик магазина начнёт работать на вас, а не против вас.
