Настройте уведомление по цепочке: запрос клиента на конкретный товар, появление доступного остатка, проверка покупки, отправка сообщения в Viber. После покупки исключайте клиента из очереди по этому товару, чтобы он не получал предложение заказать то, что уже приобрёл. Ниже — порядок настройки для малого бизнеса Беларуси: какое событие считать поступлением, когда отключать уведомления и что проверять перед отправкой. Начать можно с одного товара, на который покупатели уже оставляют заявки.
Как определить, о каком товаре уведомлять клиента?
Предложите покупателю подписаться на появление конкретного товара. В тексте рядом с кнопкой или в разговоре с продавцом уточните условие: «Сообщим в Viber, когда эта модель появится в наличии». Так человек понимает, какое сообщение получит. Согласие на такое уведомление не стоит трактовать как запрос на любые предложения магазина.
Сразу определите точность подписки. Если клиент ищет определённый размер или цвет, поступление другой версии товара не должно запускать сообщение. Для магазина обуви условием будет наличие нужного размера, для магазина техники — конкретная модель. Если покупателю подходят замены, предложите выбрать их отдельно.
Для первого запуска опишите сценарий коротким списком:
- Какой товар или вариант товара ждёт покупатель.
- Какое событие означает, что товар уже можно заказать.
- По какому действию клиента прекращаются уведомления.
- Как покупатель отказывается от ожидания.
Такой подход развивает сегментацию по поведению: сообщение получает человек, который проявил интерес к товару. В статье iSMS.by о Viber-рассылках в 2026 году именно поведение клиента рассматривают как основу для выбора аудитории (iSMS.by). Общую схему запуска дополняет материал о Viber-уведомлениях о поступлении товара для малого магазина.
Как связать поступление товара с отправкой в Viber?
Выберите событие, после которого магазин готов принять заказ. Приход поставки ещё не всегда означает доступность товара: сотруднику может потребоваться проверить комплектность или отложить часть партии под заказы. Запускайте уведомление после того, как товар стал доступен для продажи.
Разделите задачи между источником остатков и сервисом отправки. Источник сообщает, что нужный товар появился. Сценарий рассылки проверяет актуальность заявки и готовит сообщение. API, то есть интерфейс для обмена командами между системами, позволяет связать эти действия без ручного переноса каждой заявки.
- Определите событие «товар доступен для заказа» в системе, где магазин ведёт остатки.
- Настройте отбор активных заявок именно на этот вариант товара.
- Добавьте проверку покупки перед отправкой.
- Передайте сообщение в сервис Viber-рассылок.
- Проверьте результат отправки в отчёте.
На iSMS.by есть интеграция через API, официальный статус отправителя и аналитическая отчётность. Правила отбора заявок и исключения покупателей нужно отдельно согласовать при настройке интеграции. Наличие API само по себе не означает, что сервис уже знает о покупке в магазине.
Если уведомления о заказах уже работают, проверьте, какие события система умеет передавать наружу. Возможно, для нового сценария потребуется добавить событие покупки и проверку остатка. Связанный пример обмена событиями разобран в статье о настройке Viber-уведомлений о доставке через интеграции.
Когда отключать уведомление после покупки?
Заранее выберите момент, который магазин считает покупкой: оплату, подтверждение заказа или выдачу товара. Это рабочее правило зависит от процесса продаж. Если заказ ещё могут отменить, отдельно решите, возвращается ли клиент в ожидание и при каких условиях.
Исключайте из очереди заявку на конкретный товар. Покупка чайника не отменяет ожидание фильтра, если клиент подписался на оба товара. При этом покупка через другой канал тоже должна закрывать соответствующее ожидание, если магазин умеет связать её с заявкой клиента.
Добавьте повторную проверку непосредственно перед передачей сообщения на отправку. Между формированием очереди и рассылкой покупатель может успеть оформить заказ. Без этой проверки в очереди останется уже неактуальное предложение.
Обсудите с исполнителем интеграции следующие ситуации:
- Клиент купил товар после подписки, но до поступления новой партии: заявку исключают из будущей отправки.
- Клиент купил товар, пока сообщение ждало отправки: проверка перед отправкой должна остановить сообщение.
- Сообщение уже ушло, затем клиент оформил покупку: прекращаются дальнейшие уведомления по этой заявке.
- Заказ отменили: заявку возвращают в ожидание только по заранее выбранному правилу.
Отдельно различайте разовый запрос и постоянную подписку. Если покупатель попросил сообщить о ближайшем поступлении, после уведомления закройте этот запрос. Повторное появление товара не должно автоматически запускать новую рассылку тому же человеку. Уже доставленное сообщение считайте завершённым действием; отключение относится к будущим отправкам.
Что написать в сообщении и как проверить сценарий?
Напомните, почему человек получил сообщение, назовите товар и дайте понятный следующий шаг. Не обещайте резерв, если магазин его не оформил. При небольшом остатке уточните, что наличие нужно проверить в момент заказа.
Пример текста: «Вы просили сообщить о поступлении этой модели. Она снова доступна для заказа. Проверьте наличие нужного варианта в карточке товара. Если товар больше не нужен, отключите уведомления о нём».
Последняя фраза подходит только тогда, когда у клиента есть рабочий способ отключения. Это может быть действие в интерфейсе подписки или обращение к сотруднику по доступному каналу. Не предлагайте ответить на Viber-сообщение, пока не проверите, что выбранный формат отправки поддерживает ответы и сотрудник их получает.
В описании Viber-рассылок i-dgtl к сообщениям в ответ на действия клиента относят подтверждения и уведомления о статусе заказа или доставки. Для уведомления о поступлении используйте тот же принцип связи с запросом: человек должен узнать товар, который сам ждал (i-dgtl).
До запуска проверьте сценарий на тестовой заявке. Сначала убедитесь, что нужный остаток запускает сообщение. Затем повторите проверку с покупкой до отправки: сообщение должно остановиться. Ещё одна проверка — повторное поступление после закрытия разового запроса. Оно не должно возобновлять уведомления.
После запуска разделяйте результаты отправки и покупки. Отчёт о доставке показывает судьбу сообщения, но сам по себе не подтверждает заказ. Сопоставляйте его с результатами проверок в интеграции: какие заявки исключили после покупки, какие закрыли после уведомления и какие ещё ждут товар. Выгрузку отчёта по доставке как основу следующей проверки рекомендует и Vakas (Vakas).
Типичные ошибки при уведомлениях о поступлении
- Запускать сообщение при любом изменении остатка. Исправление: привязать отправку к переходу товара в состояние «доступен для заказа».
- Учитывать только модель без размера или другого варианта. Исправление: проверять именно тот вариант, который выбрал покупатель.
- Проверять покупку только при создании очереди. Исправление: повторять проверку перед передачей сообщения на отправку.
- Возобновлять разовую подписку при каждом поступлении. Исправление: закрывать запрос после уведомления и отдельно предлагать постоянное ожидание.
- Считать доставку сообщения покупкой. Исправление: получать событие покупки из процесса оформления заказа, а отчёт использовать для проверки отправки.
За ближайшую минуту выберите один товар и запишите условие остановки: «После покупки этого варианта товара уведомление по нему больше не отправляем».
