Как настроить SMS о поступлении товара в интернет-магазин

Начните с правила: отправляйте SMS о поступлении товара, когда нужный вариант уже доступен для заказа. Свяжите кнопку «Сообщить о поступлении» с товаром, проверьте доступный остаток и передайте сообщение через SMS API. В тексте назовите товар, дайте ссылку на его карточку и уточните, есть ли резерв. Ниже разберём, как настроить такую цепочку для интернет-магазина в Беларуси, избежать повторных сообщений и проверить результат без обещаний, которые магазин не сможет выполнить.

Когда товар действительно готов к уведомлению?

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

Ориентируйтесь на доступный к продаже остаток с учётом резервов. Уведомление должно касаться именно того варианта, который выбрал покупатель: размера, цвета или комплектации. Поступление другой версии товара не закрывает его запрос.

• Проверьте, что товар доступен для заказа на сайте.
• Сопоставьте поступление с конкретным вариантом из заявки.
• Убедитесь, что карточка открывается и показывает актуальную доступность.
• Определите, создаёт ли магазин резерв после уведомления.

Если резервов нет, не связывайте каждую заявку с гарантированной покупкой. При небольшом остатке разумно уведомлять покупателей очередями: отправить сообщения первой группе, затем снова проверить доступность. Правило очереди задайте заранее, например по времени заявки. Само уведомление товар не закрепляет.

Отдельно проверьте, откуда сайт получает остатки. Если склад и витрина обновляются в разное время, отправку лучше привязать к подтверждённой доступности на сайте. Этот этап подробнее раскрывает материал о том, как настроить SMS о поступлении товара на склад.

Как связать кнопку «Сообщить о поступлении» с SMS API?

Опишите разработчику цепочку от заявки до результата отправки. API здесь — способ, которым магазин передаёт SMS-сервису команду отправить сообщение. Событие запускает цепочку, шаблон задаёт текст, а ответ сервиса помогает понять, что произошло с отправкой.

1. Свяжите заявку с вариантом товара. Кнопка должна передавать выбор покупателя, чтобы поступление другого размера не запускало сообщение.
2. Настройте событие доступности. Запускайте проверку заявок, когда нужный вариант переходит из состояния «нет в продаже» в состояние «можно заказать».
3. Добавьте проверку перед отправкой. Если товар снова закончился, остановите сообщение, даже если оно уже попало в очередь.
4. Передайте запрос в SMS API. Используйте шаблон с названием товара и ссылкой, затем зафиксируйте ответ сервиса.
5. Подключите статусы отправки. Отдельно отмечайте приём запроса сервисом, доставку и ошибку, если API предоставляет такие сведения.

Предусмотрите защиту от повторов. Для одной заявки и одного события поступления система должна выполнять одну отправку. Повторное обновление остатков или перезапуск задачи не должны создавать новое SMS.

Отдельный случай — магазин отправил запрос, но не получил ответ из-за сбоя связи. Немедленный повтор рискует привести к дублю. Разработчику стоит проверить, позволяет ли API найти результат по идентификатору запроса или безопасно повторить его с тем же идентификатором. Если такой возможности нет, нужен отдельный порядок проверки спорных отправок.

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

Что написать в SMS, чтобы не обещать лишнего?

Оставьте в сообщении сведения, которые помогают перейти к покупке: кто пишет, какой товар появился и где его заказать. Название варианта важнее общего обращения по имени. Человек мог ждать несколько товаров, поэтому фраза «Ваш товар поступил» без уточнения заставляет его вспоминать заявку.

Пример без резервирования: «Магазин: куртка, размер M, снова доступна для заказа. Проверить наличие: [ссылка]. Товар без резерва».

Фраза «снова доступна» описывает ситуацию на момент отправки. Она не гарантирует наличие к моменту перехода. Поэтому ссылка должна вести в карточку нужного варианта, где покупатель увидит текущий остаток и сможет оформить заказ.

Если магазин действительно создаёт резерв, текст может быть другим: «Магазин: товар по вашей заявке поступил. Резерв действует до [дата и время]. Оформить заказ: [ссылка]». Используйте такой шаблон только после подтверждения резерва в системе. При ошибке резервирования отправляйте текст без обещания закрепить товар.

Не добавляйте срочность без основания: «последний шанс» и «забирайте скорее» ничего не объясняют. Если срок резерва известен, укажите его. Если нет, ограничьтесь текущей доступностью. Перед запуском проверьте итоговый текст с длинным названием товара: переменные влияют на длину сообщения и его стоимость.

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

Как проверить отправку и понять, работает ли сценарий?

Пройдите путь покупателя на тестовом товаре: оставьте заявку на свой номер, сделайте нужный вариант доступным и дождитесь сообщения. Откройте ссылку с телефона. Затем повторите обновление остатков и проверьте, что система не отправляет дубль.

Проверьте и обратную ситуацию: товар успел закончиться до отправки SMS. Такая заявка должна остаться без сообщения о наличии. Если она уже попала в очередь, проверка перед обращением к API должна остановить отправку.

Для контроля достаточно отчёта, который связывает заявку с товаром, событием поступления и результатом SMS. По нему сотрудник должен понять, почему сообщение ушло, почему отправка остановилась или на каком этапе возникла ошибка. Общего счётчика отправок для этого недостаточно.

• Проверьте, сколько заявок соответствовало товару, который поступил.
• Отделите запросы, которые сервис принял, от ошибок API.
• Посмотрите статусы доставки и заявки без окончательного результата.
• Сопоставьте переходы и заказы с уведомлениями, если магазин умеет связывать эти события.

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

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

Типичные ошибки при уведомлении о поступлении

• Отправлять SMS при любом изменении остатка. Исправление: запускайте сценарий при переходе нужного варианта в доступное для заказа состояние.
• Вести покупателя в общий каталог. Исправление: открывайте карточку товара с тем вариантом, на который он оставил заявку.
• Писать «товар ждёт вас» без резерва. Исправление: сообщайте о наличии и прямо обозначайте отсутствие резерва, если это существенно для покупки.
• Повторять запрос после любой ошибки. Исправление: сначала проверяйте результат предыдущей попытки и доступность товара.
• Оценивать сценарий только по отправкам. Исправление: проверяйте доставку, работу ссылки и возможность оформить заказ.

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