Время отправки SMS: окно доставки для разных сценариев
Время отправки SMS определяется не одной «лучшей» цифрой для всей базы, а назначением события. Код входа нужен сразу, перенос завтрашней записи — после подтверждения изменения, обычный статус можно отложить до утра, а реклама должна учитывать локальное время и частотную политику.
Четыре параметра
Для сценария задайте время события, send_after, срок полезности expires_at и часовой пояс получателя. Очередь отправляет сообщение только внутри разрешённого интервала и пока оно актуально.
Срочные сервисные события
OTP и события безопасности обрабатываются сразу, но имеют короткий срок жизни. Просроченный код не доставляют позже. Изменение записи или аварийное закрытие также может обходить обычное дневное окно, если промедление причинит проблему.
Обычные сервисные сообщения
Подтверждение заказа ночью можно отправить сразу, если клиент только что совершил действие и ожидает ответ. Автоматический статус, созданный фоновым процессом, лучше перенести на утро. Контекст важнее формального типа.
Рекламное окно
Маркетинговая отправка планируется по локальному времени аудитории и проверяется на небольших сегментах. Не делайте вывод о лучшем часе только по кликам: учитывайте покупки, отказы и жалобы. Правовые ограничения и отраслевые правила проверяйте отдельно.
Часовые пояса
Не определяйте пояс только по телефонному коду. Человек мог переехать или использовать корпоративную SIM. Приоритет: подтверждённая настройка профиля, адрес услуги, затем осторожный fallback.
Серверное время храните в UTC, а решение об окне принимайте в локальном поясе. Учитывайте переход даты и изменения правил времени в странах работы.
Очередь и задержки
Сообщение, созданное вовремя, может задержаться. Worker перед фактической отправкой повторно проверяет expires_at и бизнес-статус. Если окно закончилось, задача переносится или закрывается в зависимости от сценария.
Не переносите рекламу автоматически на следующее утро без повторной проверки сегмента и стоп-листа.
Несколько сообщений рядом
На уровне клиента объединяйте или разносите близкие обычные события. Подтверждение оплаты и статус заказа могут следовать друг за другом, но акция в тот же момент неуместна. Общие ограничения описаны в статье про частоту SMS.
Настройка QUICKTEL
Приложение передаёт сообщение через HTTP API QUICKTEL после расчёта окна либо использует поддерживаемые параметры периода доставки. Результат связывается со статусом SMS.
Тестирование
Проверьте границу полуночи, два часовых пояса, летнее изменение времени, задержку очереди, истёкший OTP, перенос события и клиента без пояса. Сравните время создания, отправки и бизнес-действия.
Рабочие дни и календарь
Для B2B-сценариев учитывайте календарь получателя и доступность ответственного отдела. Напоминание о счёте в нерабочий день может быть технически доставлено, но действие всё равно отложится. Срочное изменение услуги, напротив, нельзя скрывать до понедельника.
Храните календарь как настройку сценария и региона. Не зашивайте список праздников в текст или код на годы вперёд. При изменении календаря уже запланированные задания пересчитываются по явному правилу.
Время события и время сообщения
Не всегда нужно отправлять в момент записи статуса. Пакетный процесс может ночью подтвердить сотни обычных операций — их уведомления лучше распределить по дневному окну. При этом в тексте называется фактическая дата события, чтобы клиент не решил, что оно произошло только утром.
Для изменения встречи время сообщения должно предшествовать самой встрече с запасом на реакцию. Если запас уже потерян, автоматическое SMS дополняется звонком или другим эскалационным процессом.
Ограничение пропускной способности
При большой кампании последние получатели могут получить текст заметно позже первых. Планируйте скорость так, чтобы вся аудитория оставалась внутри окна. Приоритетная очередь не должна ждать окончания рекламного пакета.
Если платформа или маршрут замедлились, система оценивает срок полезности и останавливает просроченные задания. Ускорять их бесконтрольными повторами нельзя.
Метрики
Измеряйте задержку, долю просроченных заданий, действия по часовым окнам, отказы и сообщения после закрытия события. Оптимальное время выбирается отдельно для каждого сценария и регулярно пересматривается.
