Для малого бизнеса в Беларуси достаточно связать учётную систему или сайт с SMS-сервисом и задать два события: счёт просрочен и платёж подтверждён. Клиент получит короткое сервисное сообщение, а сотрудники увидят статус отправки. В статье разберём сценарий от выставления счёта до оплаты, структуру текстов, API-интеграцию, повторные попытки и мониторинг доставки. Такой подход помогает убрать ручные напоминания и не путать неоплаченные счета с уже закрытыми.
Какие SMS отправлять клиенту по счёту?
Сначала разделите уведомления по событию. Сообщение о задолженности информирует клиента о том, что счёт ещё не закрыт. Подтверждение оплаты сообщает, что платёж принят и следующий шаг уже запущен. У этих сообщений разные условия отправки, поэтому их лучше не объединять в один шаблон.
| Событие | Когда отправлять | Что указать в SMS |
|---|---|---|
| Счёт выставлен | После создания счёта | Номер счёта, сумма в BYN, срок оплаты, способ связаться с компанией |
| Срок оплаты прошёл | После проверки статуса счёта | Номер счёта, сумма, новая дата оплаты или просьба связаться с менеджером |
| Платёж получен | После подтверждения платежа | Сумма, номер счёта, статус заказа или следующий этап |
| Платёж не сопоставлен | Если деньги пришли без понятного назначения | Просьба уточнить данные платежа, контакт ответственного сотрудника |
В первом сообщении лучше назвать конкретное действие: «проверьте счёт», «оплатите до даты» или «свяжитесь с бухгалтерией». После оплаты не отправляйте напоминание о задолженности, пока система не обновила статус. Именно задержка между платёжной системой и учётом часто создаёт путаницу.
Пример уведомления о задолженности: «Счёт №184 на 245 BYN ещё не оплачен. Срок оплаты — 28 августа. По вопросам: [контакт компании]». Пример подтверждения: «Оплата счёта №184 на 245 BYN получена. Заказ передан в работу». Текст должен объяснять ситуацию без длинного описания условий.
Как построить сценарий от выставления счёта до оплаты?
Надёжная схема начинается с единого идентификатора счёта. Сайт, бухгалтерская программа или CRM передают в SMS-сервис номер счёта, телефон клиента, сумму, тип события и технический идентификатор операции. Сервис формирует сообщение и возвращает результат отправки. Для автоматизации используются API-интеграция и статусы доставки.
- После создания счёта система фиксирует событие «счёт выставлен».
- Если дата оплаты прошла, планировщик проверяет статус и создаёт событие «счёт просрочен».
- После подтверждения платежа платёжная система или сотрудник меняет статус на «оплачен».
- Система отправляет подтверждение оплаты и прекращает дальнейшие напоминания.
- Если SMS не доставлено, ответственный сотрудник видит это в журнале и выбирает следующий канал связи.
Для напоминаний задайте ограничение по частоте. Например, одно сообщение после наступления срока оплаты, а повтор отправляйте только при изменении суммы, даты или статуса. Так уведомления остаются связанными с реальным событием, а клиент не получает одинаковый текст несколько раз.
Для платежей полезен отдельный статус «платёж получен, счёт не сопоставлен». Он остановит напоминания только после проверки бухгалтером. Такой промежуточный этап особенно нужен, если оплату иногда проводят с другого счёта или с неполным назначением.
Как подключить сервисные SMS через API?
Перед подключением опишите события и поля, которые система должна передавать. Минимальный набор выглядит так: номер телефона, тип уведомления, номер счёта, сумма, дата, идентификатор операции и текстовый шаблон. Не передавайте в SMS лишние сведения: клиенту достаточно понять, какой счёт нужно проверить и что произошло с платежом.
Затем разработчик создаёт отдельные API-запросы для выставления счёта, просрочки и оплаты. Каждый запрос должен иметь уникальный идентификатор. Если сайт повторит запрос из-за сбоя связи, сервис сможет распознать дубль и не отправить одно и то же уведомление повторно. Для контроля подобных ситуаций полезен материал почему SMS отправляется дважды.
Ответ API нужно сохранять вместе с номером счёта. В нём обычно важны идентификатор сообщения, время отправки и текущий статус. Не ограничивайтесь отметкой «запрос принят»: она показывает, что система получила команду, но ещё не подтверждает доставку на телефон.
Если собственного разработчика нет, начните с простой интеграции через вебхук или готовый модуль учётной системы. Для сайта с небольшим числом счетов можно сначала подключить один сценарий, например подтверждение оплаты, проверить статусы и только потом добавлять напоминания о просрочке.
Как контролировать доставку и разбирать сбои?
Мониторинг нужен для двух задач: увидеть техническую проблему и понять, какие уведомления требуют ручной проверки. В журнале удобно фильтровать сообщения по номеру счёта, типу события, времени и статусу доставки. Если несколько сообщений подряд не проходят, проверьте соединение с API, формат номера и корректность отправителя.
Сделайте отдельный список исключений. В него попадают дублирующиеся запросы, неизвестный номер счёта, несоответствие суммы и платежа, а также недоставленные SMS. Менеджер или бухгалтер получает только те задачи, которые нельзя закрыть автоматически.
Когда уведомление связано с оплатой, не меняйте статус счёта только по факту отправки SMS. Статус «оплачен» должен появляться после подтверждения платежа в вашей системе. SMS сообщает клиенту результат, но не заменяет бухгалтерскую проверку.
Для системных сбоев заранее определите повторную попытку. Она должна запускаться по техническому статусу, а не по любому отсутствию ответа клиента. Настройка очереди, приоритетов и повторных отправок разобрана в материале как построить очередь SMS в API.
Какие ошибки чаще всего создают путаницу?
- Отправка напоминания без повторной проверки статуса счёта.
- Один шаблон для задолженности и подтверждения оплаты.
- Передача в SMS слишком большого количества деталей, которые трудно прочитать на телефоне.
- Повторная отправка при каждом запуске обмена с учётной системой.
- Отсутствие журнала, где видно, когда сообщение отправили и чем закончилась доставка.
- Изменение суммы в тексте вручную, когда она уже изменилась в счёте.
Проверьте сценарий на тестовом счёте: создайте его, дождитесь напоминания, зарегистрируйте пробный платёж и убедитесь, что последующее уведомление о задолженности не отправляется. Затем имитируйте недоступность API и посмотрите, как система повторяет запрос. После этого можно подключать рабочие счета и постепенно добавлять новые события.
Для малого бизнеса рабочая схема выглядит так: система создаёт счёт, проверяет его статус, отправляет напоминание при просрочке и прекращает цепочку после подтверждения оплаты. API убирает ручную отправку, а мониторинг помогает заметить недоставленные сообщения и ошибки сопоставления платежей. На сайте smsgo.by такая задача естественно решается через интеграцию по API, сервисные SMS и контроль статусов доставки.
