Единые SMS о заказах с сайта и маркетплейсов: как настроить

Селлер в Беларуси часто продаёт сразу в нескольких местах: свой сайт, Instagram, Telegram, маркетплейс. Заказы приходят в разные кабинеты, статусы живут отдельно, и покупатель либо получает три одинаковых SMS про одну покупку, либо не получает ни одной. Дальше — рабочая схема: как свести все каналы в одну точку, отправлять по одному сообщению на каждое событие и отсекать повторы до отправки. Собрать это можно и с CRM, и без неё.

Почему один заказ превращается в три SMS или ни в одну

Всё упирается в разные логики статусов. На сайте заказ идёт по цепочке «новый → оплачен → собран → доставлен». Та же покупка на маркетплейсе живёт в личном кабинете продавца, где статусы называются иначе и обновляются в своём ритме. В Instagram и Telegram заказ часто рождается прямо в переписке: менеджер вручную уточняет адрес и вручную же жмёт «отправить SMS».

Пока каналов два, путаница терпима. С четырьмя каналами и сезонным наплывом заказов менеджер начинает дублировать подтверждения и забывать про доставку. В разборе практики SMS-уведомлений через Битрикс24 (AutoBIT24) описан случай, когда выстроенная цепочка сообщений снизила долю брошенных корзин с 30% до 12%. Логика простая: клиент получает сообщение вовремя и по делу, а не три раза одно и то же.

Как устроена единая точка отправки?

Это место, куда стекаются события из всех каналов и откуда уходит SMS. Роль такого места может играть CRM, а может — таблица в базе данных. Для магазина на 30–100 заказов в месяц второй вариант часто проще и дешевле.

Схема: сайт, маркетплейс и мессенджер передают событие в общее хранилище. Хранилище держит три поля — номер заказа во внешней системе, телефон покупателя и текущий статус. Дальше правило: пришло событие, сравнили статус с предыдущим, изменился — ушло одно SMS через шлюз. Не изменился — ничего не ушло.

Технически это связка «вебхук канала → запись в таблицу → вызов SMS API». Если канал не умеет вебхуки, событие попадает в таблицу из выгрузки или руками менеджера, а правило «один статус — одно сообщение» остаётся.

Что проверить в SMS-шлюзе до подключения

• API с документацией и тестовым режимом — чтобы прогнать сценарий на своём номере до запуска.
• Статусы доставки, а не только факт приёма сообщения. Разница между «принято» и «доставлено» решает, узнаете вы о проблеме или нет.
• Шаблоны с подстановкой переменных: номер заказа, сумма, трек, адрес пункта выдачи.
• Логи и отчёты с выгрузкой — по ним видно, сколько сообщений ушло по каждому статусу.
• Ограничения на длину текста и поддержку кириллицы.

Если в шлюзе нет статусов доставки и отчётов, единая схема превращается в чёрный ящик: сообщение вроде бы отправлено, а дошло ли оно — непонятно.

Как сопоставить статусы разных каналов?

Приводить статусы к идеальному виду не нужно. Достаточно свести их к пяти-шести событиям, которые понятны покупателю. Остальное можно не сообщать.

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

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

Три приёма закрывают почти все повторы.

1. Уникальный ключ события: канал, номер заказа, код статуса. Перед отправкой проверяем ключ в логе. Ключ уже есть — выходим, ничего не отправляем.
2. Сравнение с предыдущим статусом. Вебхуки нередко приходят повторно с тем же значением. Отправка только при реальном изменении снимает большую часть дублей.
3. Лог отправок: дата, ключ, текст, статус доставки. Без него вы не отличите «не ушло» от «ушло дважды».

Заодно ограничьте частоту. Если по одному заказу планируется больше двух-трёх сообщений, события лучше объединять: короткое «заказ собран и передан в доставку, трек такой-то» читается легче, чем два SMS с интервалом в десять минут.

Задержки и очередь

Событие сначала попадает в очередь, потом уходит в шлюз. Так вечерний наплыв заказов не превращается в сотню параллельных запросов. Если API вернул ошибку, попытка повторяется по расписанию — обычно хватает двух-трёх повторов с паузой.

Доставляемость тоже зависит не от удачи: по разбору факторов доставляемости SMS (SMSBlog) на неё влияют качество базы, корректная маршрутизация и содержание текста. Номера, которые месяцами не принимают сообщения, лучше вычищать из базы перед сезонными рассылками.

Можно ли обойтись без CRM и что делать в сезон?

Для микробизнеса с 20–50 заказами в месяц связка «таблица + скрипт + SMS API» закрывает задачу целиком. Если магазин работает на WooCommerce, уведомления подключаются модулем без правок в коде — пошаговый порядок есть в статье про SMS-уведомления о заказах в WooCommerce без программиста.

Перед распродажей проверьте три вещи: лимиты на стороне шлюза, тексты шаблонов и корректность подстановки переменных. Когда число заказов за день растёт вдвое-втрое, ручные отправки перестают успевать за потоком, и выручает заранее собранный сценарий — автоматические SMS при сезонном всплеске заказов.

Типичные ошибки

• Отправлять уведомления из каждого канала отдельно: покупатель получает два-три одинаковых SMS и блокирует номер.
• Писать во внутренних статусах («комплектация», «ожидает отгрузки»). Человеку понятнее «заказ собран и передан в доставку».
• Не вести лог отправок — потом невозможно понять, куда делось сообщение и было ли оно вообще.
• Слать SMS по статусу, который не менялся. Это типичный результат повторного вебхука.
• Проверять цепочку только в интерфейсе. Тестовый заказ на живом номере показывает, где именно появляются дубли и как приходит текст.
• Ставить один шаблон на все случаи: напоминание забрать посылку и просьба об отзыве требуют разных формулировок и разного времени отправки.