Магазин дважды прислал сообщение «заказ готов», хотя покупатель уже отменил покупку. Текст короткий, отправка сработала, но человек получил ненужное уведомление. Проверять нужно всю цепочку: событие, актуальность заказа, получателя и результат.
Автоматическая отправка SMS начинается с описания сценария и проверки его допустимости. Разберем виды сообщений, расходы, статусы и типичные ошибки. Все примеры ниже учебные; реальные отправки для подготовки статьи не запускались.
Сначала разделить уведомление и рекламу
Сообщение о конкретной операции и предложение купить новый товар решают разные задачи. «Заказ 245 готов к выдаче» сообщает состояние заказа. Добавленная фраза о распродаже меняет содержание. Название шаблона «сервисный» само по себе не определяет правовую оценку.
Согласие не означает разрешение на любой способ автоматизации рекламы. Статья 18 закона о рекламе требует предварительного согласия и отдельно запрещает распространение рекламы с выбором или набором номера без участия человека. Поэтому нельзя свести подготовку к совету «получите согласие и включите автоматическую кампанию».
Статья 44.1 закона о связи устанавливает свои условия мобильной рассылки: подтверждаемое предварительное согласие, договорную схему с оператором и возможность отказа через оператора. Сервисное содержание не дает общего освобождения от этих требований.
До запуска конкретную техническую схему, текст и основания отправки стоит проверить с ответственным за правовую оценку и оператором. Руководство ФАС по приказу №410/24 рассматривает согласие и способ распространения отдельно. Дальше разберем операционную проверку нейтральных уведомлений без рекламных вставок.
Какое сообщение нужно человеку
Выбирайте сценарий по событию, которое действительно меняет действие клиента. Заказ подготовлен — можно приехать. Время записи перенесено — нужно подтвердить новые условия. Код подтверждения нужен для конкретного действия. Общий повод «напомнить о компании» не объясняет полезность сервисного уведомления.
Для каждого сценария важно назвать источник события. Сотрудник вручную отметил готовность, учетная система сменила статус или клиент подтвердил запись? Если источники расходятся, сообщение может уйти раньше, чем операция завершена.
Затем определите, когда отправка уже не нужна. Заказ отменен, время записи изменилось еще раз, человек выполнил действие другим способом. Условие остановки столь же важно, как условие запуска. Без него исправно работающая автоматизация начнет сообщать устаревшие сведения.
В учебном магазине уведомление о готовности формируют после подтвержденной сборки. Перед отправкой проверяют текущий статус. Если заказ отменен, сообщение о готовности не соответствует ситуации, даже когда событие сборки раньше было верным.
Карта сценария до настройки сервиса
Таблица помогает обсудить требования с командой и поставщиком. Основания и допустимость отправки проверяют отдельно до запуска каждого сценария.
Событие | Что должно быть известно | Когда остановить отправку | Что проверить |
|---|---|---|---|
Заказ готов | Нужный заказ, получатель, пункт и срок выдачи | Заказ отменен или готовность отозвана | Текст соответствует текущему состоянию |
Запись перенесена | Последнее согласованное время и адрес | Запись отменена или время снова изменилось | Уходит актуальная версия уведомления |
Действие требует подтверждения | Конкретный запрос и допустимый срок подтверждения | Запрос завершен или больше не действителен | Сообщение не повторяется бесконтрольно |
Возникла ошибка доставки | Статус, время и правило обработки ошибки | Повтор не нужен или сценарий завершен | Не создаются дубли и лишние расходы |
Если нет ответа на колонку «когда остановить», сценарий еще не готов. Начать полезнее с одного понятного уведомления, чем подключать все события и разбирать последствия уже по обращениям покупателей.
Как убрать повторы и устаревшие уведомления
Одна операция может передаваться несколько раз: система повторяет событие после сбоя или сотрудник повторно сохраняет запись. Повторная передача не обязательно означает новый заказ. Нужен способ отличать событие от его повторного получения.
На обсуждении с поставщиком спросите: по какому признаку система замечает дубль, где видна предыдущая отправка и что происходит после ошибки? Название функции «защита от повторов» полезно подтвердить на согласованном примере.
В учебной проверке отправляющая система дважды получает одно событие готовности заказа 245. Ожидаемый результат задают заранее: повтор не создает новое одинаковое уведомление. Затем проверяют другой заказ того же клиента, чтобы защита от дублей не заблокировала полезное новое сообщение.
Отдельный вопрос — очередь. Между событием и фактической отправкой может пройти время. Поэтому актуальность стоит проверять в точке, предусмотренной технической схемой. Нельзя считать, что сообщение остается правильным бесконечно, раз оно когда-то попало в очередь.
Правило повторной попытки тоже нужно ограничить. Если получатель не получил сообщение, бесконечная отправка не гарантирует доставку. Она может увеличить расходы и число поздних уведомлений. Условия повторов и завершения согласуйте с поставщиком под конкретный статус.
Что написать в коротком сообщении
Полезный текст отвечает на вопросы: кто пишет, что произошло и что человеку делать дальше. Для заказа можно указать номер и действие, а подробности оставить на понятной странице. Ссылка должна вести к нужному контексту, а не на главную, где клиент заново ищет свой заказ.
Учебный пример нейтрального уведомления:
Магазин: заказ 245 готов. Адрес и срок выдачи — в вашем заказе.
Это заготовка для обсуждения содержания, не готовое разрешение на отправку. Фактический отправитель, доступ к странице заказа и основания сообщения нужно проверить. В примере нет рекламного предложения другого товара.
Если подставляются имя, адрес или время, смотрите итоговый текст после подстановки. Длинное название пункта меняет длину, а пустое поле способно сделать фразу бессмысленной. Проверять только короткий шаблон без значений недостаточно.
Лучше убрать лишнее повторение, чем сокращать смысл до непонятных аббревиатур. Человек должен узнать операцию и следующий шаг. Если содержание не помещается в удобный объем, проверьте, какие подробности можно показать на доступной странице.
Сколько SMS получится из одного текста
Человек может видеть одно длинное сообщение, а расчет расходов идти по нескольким сегментам. Поэтому количество получателей и количество оплачиваемых частей — разные величины. Итог зависит от условий продукта и кодировки.
В справке МТС о расходах на рассылки по своей базе PRO описано правило: до 70 символов — один сегмент, при превышении текст делится на части по 67. Пример из 75 символов занимает 2 сегмента. Эти условия относятся к описанному продукту; для другого решения нужно проверить его правила.
В счетчике выбранного сервиса проверьте готовое сообщение со ссылкой и подстановками. Не переносите результат короткой заготовки на все варианты текста. Эмодзи и специальные символы тоже стоит включить в проверку, если они действительно нужны.
Учебный расчет: 100 получателей получают текст по 2 сегмента — это 200 сегментов. Для стоимости умножьте их на проверенный тариф и добавьте применимые платежи по договору. Актуальную ставку нельзя выводить из старого скриншота или тарифа другого продукта.
Перед выбором сравните одинаковый состав расходов: имя отправителя, шаблоны, операторы, сегменты и условия списания. Если в одном предложении указана цена части, а в другом пакета, сначала приведите расчет к одному сценарию.
Доставлено не означает прочитано
В отчете могут быть разные состояния: сервис принял запрос, сообщение отправлено, получен статус доставки, возникла ошибка. Значения нужно сверить с документацией поставщика. Статус приема не стоит автоматически переименовывать в доставку.
Учебный пример: из 100 уведомлений 90 получили статус доставки. Доля по этому статусу — 90 / 100 = 90%. Она не показывает, сколько людей прочитали текст, выполнили действие или купили товар. Для каждого следующего результата нужен отдельный способ наблюдения.
Для уведомления о выдаче полезный вопрос — дошла ли актуальная информация и не пришлось ли клиенту обращаться повторно. Для другого сценария результат будет иным. Необязательно оценивать каждое сообщение выручкой, если его задача состоит в сопровождении конкретной операции.
Если используете переходы по ссылке, заранее определите, как их считаете. Число переходов не равно числу уникальных получателей и не доказывает завершение заказа. Сверяйте события на странице с вопросом, ради которого отправляли сообщение.
Как проверить сценарий без массовой отправки
Начните с синтетических заказов и проверки логики в согласованной тестовой среде. Для первоначального разбора не нужны реальные номера клиентов, рабочие ключи и массовая загрузка контактов. Реальные тестовые отправки требуют отдельного согласованного порядка.
- Обычное событие формирует правильный текст для нужной операции.
- Отмена до отправки останавливает устаревшее уведомление.
- Повтор того же события обрабатывается по правилу защиты от дублей.
- Длинная подстановка не ломает смысл и учтена в расчете сегментов.
- Ошибка доставки видна ответственному и не запускает бесконечные повторы.
Сохраните ожидание и фактический результат по каждому пункту. Если один сценарий не проверен, так и запишите. Успешное формирование текста не подтверждает работу операторской доставки, а показ в тестовой среде не доказывает готовность всех рабочих подключений.
После исправления повторите исходный случай и соседний. Например, защита от дубля должна убрать второе одинаковое событие, но сохранить уведомление о новой операции. Проверка только первого результата может скрыть новую ошибку.
Какие ошибки искать после запуска
Неправильный момент. Система отправляет сообщение после промежуточного статуса, который сотрудник еще может отменить. Сверьте точку запуска с фактической готовностью и добавьте нужное подтверждение в процесс.
Расхождение текста и операции. Уведомление говорит о прежнем времени записи. Проверьте, откуда взялось значение и какая версия события ушла в отправку. Общий совет «обновить шаблон» может не затронуть источник устаревшего поля.
Непонятный маршрут вопроса. Клиент получил уведомление, но не знает, где уточнить адрес или сообщить о проблеме. Проверьте доступный канал помощи. Не обещайте, что ответ на любое буквенное имя отправителя попадет в поддержку.
Повторяющиеся жалобы можно искать и в обратной связи. В аналитике отзывов Спикс темы помогают заметить, что клиенты часто пишут о позднем или непонятном уведомлении. Причину отправки, статусы и расходы команда проверяет в своих системах: Спикс не стоит представлять SMS-платформой.
Что записывать для разбора спорного уведомления
Когда клиент сообщает о повторной или поздней SMS, нужен путь от операции до результата. Полезно сохранить идентификатор заказа, тип события, время его получения, версию шаблона и статус отправки. Состав и доступ к таким сведениям компания определяет под свой процесс и требования к данным.
Различайте время события и время обработки. Заказ могли подготовить утром, событие дошло позже, а сообщение попало в очередь еще через некоторое время. Если смотреть только на время отправки, трудно понять, где возникла задержка и было ли уведомление актуальным.
В учебном разборе покупатель отменил заказ в 12:00, а SMS о готовности ушла в 12:10. Это не доказывает, что событие отмены уже было известно отправляющей системе. Сначала проверьте, когда она получила отмену и какое правило применилось. После этого можно обсуждать исправление обмена или точки проверки статуса.
Не стоит собирать все содержимое клиентских записей ради одного случая. Для общей технической задачи часто нужен обезличенный пример и ссылка на операцию в разрешенном рабочем контуре. Номер телефона и другие сведения не следует переносить в публичное обсуждение жалобы.
Назначьте владельца следующего вопроса. Специалист по заказам подтверждает фактическое состояние, поставщик отправки объясняет значение статуса, ответственный за текст сверяет шаблон. Если написать всем только «SMS не работает», участники начнут проверять разные версии без общей последовательности.
В итоговой записи полезно разделить: подтверждено, осталось неизвестным, изменено и повторно проверено. Например: «Отмена пришла после помещения уведомления в очередь. Добавлена согласованная проверка актуальности. Обычный заказ и отмена до отправки прошли повторный тест». Это учебное описание формата, а не результат выполненной нами настройки.
Как менять шаблоны, сохраняя понятный процесс
Даже небольшая правка может изменить сценарий. Добавленная ссылка увеличит длину, новая подстановка иногда останется пустой, рекламная фраза потребует отдельной оценки содержания. Поэтому замена текста — повод повторить относящиеся к ней проверки, а не только сохранить шаблон.
Для каждого изменения запишите причину и дату. Сохраните прежнюю версию, чтобы разобрать уже отправленное сообщение. Иначе поддержка увидит новый текст в кабинете и не поймет, почему клиент жалуется на формулировку, которой там больше нет.
Проверяйте варианты с короткой, длинной и отсутствующей подстановкой. Если адрес не получен, нужно согласованное поведение: остановка, другой текст или передача на проверку. Не стоит отправлять человеку «заказ готов по адресу [адрес]» и надеяться, что он догадается сам.
После обновления сравните несколько новых операций с ожидаемым результатом. Контроль нужен и тогда, когда исправляли только стиль. Удаленное слово может сделать условие непонятным, а измененная ссылка — привести к странице без нужного заказа.
При смене исполнителя передайте карту сценария и открытые вопросы вместе с шаблонами. Новый сотрудник должен понимать, кто согласует содержание, кто разбирает статус доставки и где хранится история изменений. Тогда проверка не зависит от памяти человека, который настраивал уведомление первым.
Частые вопросы
Можно ли считать любую автоматическую SMS-рассылку допустимой после согласия?
Нет. Для рекламы закон отдельно регулирует согласие и способ распространения. Перед запуском нужна проверка конкретной технической схемы и содержания. Для мобильных рассылок также действуют требования закона о связи.
Один текст всегда оплачивается как одна SMS?
Нет. Он может состоять из нескольких сегментов. Проверяйте готовый вариант с подстановками и ссылкой по условиям своего продукта, а не только число символов в исходном шаблоне.
Статус доставки подтверждает, что человек прочитал уведомление?
Сам по себе не подтверждает. Он отражает определенное состояние в системе доставки. Понимание, переход и выполненное действие — отдельные результаты, для которых нужны свои проверки.
Что в итоге
- Автоматическая отправка SMS требует проверки цели, содержания, оснований и технической схемы.
- Для сценария нужны событие, получатель, актуальный текст и условие остановки.
- Повторы и отмены проверяйте вместе с обычной операцией.
- Считайте сегменты готового сообщения и полный состав расходов.
- Различайте прием, доставку и действие клиента, сохраняя определения в отчете.
Источники
- Закон38-ФЗ,статья18: реклама по сетям электросвязи. Прочитано 20.10.2026.
- Закон126-ФЗ,статья44.1: мобильная рассылка. Прочитано 20.10.2026.
- ФАС410/24: о рекламе по сетям электросвязи. Прочитано 20.10.2026.
- МТС: расходы на рассылки по своей базе PRO. Прочитано 20.10.2026.
Разбирайте обратную связь покупателей в Спикс
Темы отзывов помогают выбрать, что уточнить в товаре и объяснениях для покупателей. Посмотрите, как организовать эту работу в Спикс.
Попробовать Спикс