Начните с двух цифр: сколько CRM тратит на SMS за время, пока вы пополняете счёт, и какой остаток доступен у провайдера сейчас. По ним можно установить порог предупреждения, чтобы сотрудник успел оплатить отправку до остановки уведомлений. Затем настройте проверку баланса и отдельный сигнал на случай, если проверка перестанет работать. Ниже — порядок действий для малого бизнеса в Беларуси: какие сведения запросить у провайдера, как связать лимит с расходами и что проверить перед запуском.
Какие расходы на SMS показывает CRM, а какие — провайдер?
CRM знает, какие уведомления она создала: например, подтверждение заказа или напоминание о записи. Но число заказов не равно числу оплаченных SMS. Один заказ вызывает несколько сообщений, а длинный текст провайдер тарифицирует как несколько частей. Поэтому начните с выгрузки списаний в кабинете провайдера и сопоставьте её с отправками из CRM.
Отметьте дни, когда сообщения уходят плотнее обычного: перед массовыми напоминаниями, после распродажи или при изменении графика работы. Так вы увидите расход, который нужен для выбора порога. Если в CRM уже есть отчёт по отправкам, полезно показывать рядом стоимость по данным провайдера: расхождение подскажет, где искать лишние сообщения или ошибку в оценке бюджета.
Отдельно решите, что делать с массовой рассылкой. Порог, рассчитанный на обычные уведомления, не учитывает разовую отправку по всей базе. Перед запуском сравните её ожидаемую стоимость с доступным остатком и оставьте деньги на текущие сообщения клиентам.
Как узнать доступный баланс и выбрать порог предупреждения?
Попросите провайдера показать в документации метод API, который возвращает остаток счёта. Возможность отправлять SMS через API ещё не означает, что тот же доступ позволяет читать баланс. Уточните, что означает число в ответе: деньги на счёте, доступный лимит или остаток пакета. Для контроля нужно значение, которое ограничивает дальнейшую отправку.
Проверьте валюту ответа. Если компания планирует расходы в белорусских рублях, а счёт провайдера ведётся в другой валюте, согласуйте с бухгалтером правило пересчёта. Спросите также, когда API отражает списания и пополнения. При задержке число на экране может отличаться от суммы, которой уже можно воспользоваться.
Для порога возьмите расход за весь путь пополнения: сотрудник увидит сигнал, подготовит платёж, получит согласование, а провайдер зачислит деньги. Добавьте запас на ожидаемый рост отправок в этот период. Ориентир берите из собственных списаний, особенно за дни с высокой нагрузкой. Отдельный критический порог нужен на случай, когда доступного остатка уже не хватит до зачисления платежа.
Если нужен подробный разбор ответа API и проверки остатка, он есть в статье на smpp.by. В задачу разработчику передайте определение доступного баланса, валюту счёта и время, за которое пополнение появляется в ответе.
Кому и когда сообщать о низком балансе?
Назначьте человека, который готовит платёж, и того, кто подменит его во время отсутствия. Предупреждение отправляйте обоим по независимому каналу, например по электронной почте. Если счёт SMS-провайдера опустеет, сообщение через него же рискует не дойти. В письме нужны сумма, валюта, время последней успешной проверки и причина сигнала.
Разработчик может запускать проверку баланса по расписанию отдельно от отправки SMS. Частоту выбирают по скорости расхода и ограничениям API: после предупреждения должно оставаться время на оплату. Для каждой проверки сохраняйте результат и время ответа. Пустой ответ или тайм-аут означают, что текущий остаток неизвестен; показывать их как нулевой баланс нельзя.
Если API недоступен, система показывает последний успешный остаток вместе со временем его получения и отправляет отдельное сообщение об ошибке. Повторяющиеся письма об одной и той же проблеме лучше объединять в один инцидент. После пополнения система снимает предупреждение только тогда, когда новая проверка подтверждает достаточный остаток.
Контроль расходов полезно связать с очередью отправки: так видно, сколько сообщений ждёт обработки и хватит ли на них счёта. Если CRM повторяет запрос после сбоя, проверьте и защиту от повторной отправки. Для этого пригодится материал о том, как отправлять уведомления из CRM через очередь без дублей. Показатели очереди и баланса можно вывести в рабочую панель облачной инфраструктуры, чтобы ответственный видел их без запроса к разработчику.
Как проверить настройку, не обнуляя счёт?
Попросите разработчика подставить тестовый ответ API в отдельной среде. Сначала проверьте остаток ниже порога: письмо должно прийти нужному человеку с суммой и валютой. Затем повторите такой же ответ и убедитесь, что сотрудника не засыпает одинаковыми письмами.
После этого воспроизведите тайм-аут. Система должна сообщить, что проверка не удалась, и показать время последнего успешного ответа. Наконец, подставьте достаточный баланс: предупреждение должно закрыться. Технический тест завершится, когда ответственный откроет пробное письмо, найдёт данные для оплаты и подтвердит, кто заменит его при отсутствии.
Какие ошибки чаще мешают контролировать SMS-бюджет?
- Порог ставят наугад. Посчитайте списания за время пополнения и добавьте запас под ближайшую нагрузку.
- Ориентируются только на число заказов в CRM. Сверьте его с расходом у провайдера и проверьте длину текстов.
- Ошибку API принимают за нулевой остаток. Выводите отдельный статус «Баланс неизвестен» и время последней проверки.
- Письмо получает человек без доступа к оплате. Назначьте получателя, который может запустить платёж, и резервного сотрудника.
- Предупреждение снимают сразу после оплаты. Дождитесь, пока API покажет доступный остаток выше порога.
Начните с одного короткого запроса поддержке провайдера: «Где описан метод API для получения доступного баланса, в какой валюте он отвечает и когда показывает списания и пополнения?»
