Фраза «клиенту придет уведомление» описывает ожидание, пока система не получила подтверждение доставки сообщения. Даже подтверждённая доставка ещё не означает, что человек прочитал текст, подтвердил заказ или оплатил счёт. Для руководителя продаж рабочая система уведомлений — это цепочка: событие → отправка → проверяемый статус доставки → целевое действие, с отдельным маршрутом для каждого сбоя.
За сообщение заплатили, а заказ остался без подтверждения
В карточке заказа стоит отметка «уведомление отправлено». Менеджер перестаёт следить за ситуацией, а клиент не подтверждает доставку. Причина может находиться где угодно: задание осталось в очереди, адрес неверный, канал недоступен или сообщение пришло, но из него непонятно, что требуется сделать.
Деньги теряются по разным причинам. Попытка отправки может тарифицироваться независимо от результата. Менеджер вручную восстанавливает историю. Заказ ждёт действия, которое никто не проверяет. Если в сервисный текст добавили рекламное предложение, появляется ещё и правовой риск.
Поэтому вопрос «как отправить уведомление клиенту» нужно дополнить: какое событие его запускает, чем подтверждается доставка и кто продолжит работу, если подтверждения не будет.
98% доставки не означают, что клиент увидел сообщение
В отраслевом отчёте, опубликованном в 2025 году по обезличенной статистике семи крупных зарубежных поставщиков email-рассылок за 2024 год, доставляемость составила 98%, доля открытий — 35,9%, доля уникальных кликов — 2,3%. Это разные показатели, а не последовательные доказательства продажи. Выборка не является нормативом для российских транзакционных сообщений; абсолютное число писем на открытой странице отчёта не раскрыто. Отраслевой отчёт по email, 2025.
Качественное наблюдение из практики внедрения агентов искусственного интеллекта — ИИ-агентов — Excella: нужное событие обычно уже существует в системе управления взаимоотношениями с клиентами — CRM, от английского Customer Relationship Management. Пробел обнаруживается дальше: отправка предусмотрена, а действия при недоставке не описаны. Это наблюдение команды, без количественной оценки распространённости.
Для проверки такой системы полезно разделить два вопроса. Доставка показывает, прошла ли коммуникация технический маршрут. Контрольная группа показывает, добавила ли она бизнес-результат. Подменять один ответ другим нельзя.
Статус заказа, запрос действия и рекламное предложение
Транзакционные сообщения клиентам привязаны к конкретному событию: созданию заказа, поступлению оплаты, изменению времени доставки. Сервисные уведомления клиентам могут просто информировать или требовать ответа. Рекламное предложение решает другую задачу — продвигает товар или услугу.
Ниже — примеры формулировок для проектирования шаблонов, а не сообщения из клиентских кейсов.
| Назначение | Пример текста | Что фиксировать как результат | Где возникает риск |
|---|---|---|---|
| Сообщить статус | «Заказ {номер} передан в доставку. Актуальный статус: {ссылка}» | Доставку в пределах срока актуальности | Требовать оплату или ответ там, где клиенту достаточно информации |
| Получить действие по заказу | «Подтвердите предложенное время доставки заказа {номер}: {ссылка}» | Подтверждение времени в учётной системе | Принять открытие ссылки за завершённое подтверждение |
| Продвинуть дополнительный товар | «Добавьте аксессуар к заказу со скидкой» | Покупку и её дополнительный эффект | Отправить рекламу под видом обслуживания без необходимых оснований |
Сервисный статус определяется содержанием и обстоятельствами сообщения. Название шаблона «уведомление о заказе» не исключает рекламную квалификацию, если внутри продвигается дополнительный товар. Основа разграничения — признаки рекламы из закона и разъяснения Федеральной антимонопольной службы России — ФАС. Руководство регулятора о понятии рекламы.
Событие в CRM должно создавать проверяемое задание
Уведомления из CRM стоит запускать по зафиксированному изменению состояния. Например: заявка зарегистрирована, оплата подтверждена, заказ готов к выдаче, время встречи изменено. Сам факт открытия карточки менеджером ещё не означает, что клиенту есть что сообщить.
Для каждого сценария задайте:
- событие и систему, которая подтверждает его наступление;
- получателя и проверенный источник контакта;
- шаблон с разрешёнными переменными;
- основной и резервный каналы;
- срок актуальности сообщения;
- ожидаемое действие, если оно требуется;
- ответственного за незавершённую коммуникацию.
Из события создаётся задание с собственным идентификатором. Оно связывает заказ, попытки отправки, ответы канала и результат клиента. Повторная обработка того же события не должна автоматически создавать дубликат уведомления.
Практический критерий: по карточке заказа можно восстановить, почему сообщение понадобилось, какой текст ушёл и чем закончилась отправка. Отметки «автоматизация сработала» для этого недостаточно.
Если цепочка начинается с формы на сайте, подтверждение регистрации заявки также нужно связать с реальной записью в CRM. Это продолжение задачи как увеличить конверсию сайта: отправленная форма ещё должна превратиться в обработанное обращение.
Канал выбирают по доступности клиенту и сроку действия сообщения
Нет универсального канала, который гарантированно доставляет уведомления всем клиентам в России. Выбор нужно проверять на собственных контактах, условиях подключения и статусах, которые возвращает конкретная интеграция.
| Канал | Для какого сценария его рассмотреть | Что проверить до запуска |
|---|---|---|
| Электронная почта | Документы, подробный статус, инструкции | Корректность адреса, настройку домена отправителя, обработку отказов и значение статуса «доставлено» |
| Короткие текстовые сообщения — SMS, от английского Short Message Service | Краткий статус или действие с ограниченным сроком | Доступность номера, правила согласования отправителя и шаблона, отчёт о доставке, тарификацию неуспешных попыток |
| Сообщение в мессенджере | Продолжение диалога в доступном клиенту канале | Возможность начать коммуникацию, ограничения канала и наличие подтверждения доставки |
| Push-уведомление — всплывающее уведомление приложения или браузера | Напоминание пользователю собственного цифрового продукта | Разрешение на уведомления и возможность отличить принятие задания от доставки на устройство |
Статусы необходимо читать буквально. Документация государственной системы уведомлений различает передачу поставщику и доставку; для SMS доставка не подтверждает чтение. Для электронной почты также предусмотрены отдельные ошибки адреса, доступности ящика и передачи сообщения. Описание статусов SMS, описание статусов email.
Это пример устройства отчётности, а не обещание аналогичных возможностей у любого российского подрядчика. Если канал не возвращает подтверждение доставки, сохраняйте «доставка неизвестна».
Где обрывается цепочка от события до действия
Событие не зафиксировано. Сотрудник договорился с клиентом, но не изменил статус заказа. Задание не появилось. Проверка начинается с учётной системы, а не с отчёта рассылки.
Шаблон или отправитель не допущен к отправке. В каналах, где требуется согласование, сообщение может остановиться до попытки доставки. Такой отказ должен видеть сотрудник, отвечающий за интеграцию.
Контакт неверный. Несуществующий адрес требует исправления данных. Повтор того же сообщения на тот же адрес проблему не решает.
Канал недоступен. Телефон может быть выключен, почтовый ящик — переполнен; возможен технический сбой. Здесь нужно различать временную ошибку, постоянный отказ и отсутствие окончательного статуса. Такие причины описаны в документации по недоставке.
Доставлено, но чтение не подтверждено. Система достигла технической границы наблюдения. Нельзя автоматически записывать клиента в прочитавшие.
Сообщение прочитано, но действия нет. Проверьте, понятен ли следующий шаг, работает ли ссылка и не выполнил ли клиент действие другим способом. Переключение канала само по себе этот разрыв не объясняет.
Последние этапы — уже не обязательно сбой доставки. Их нужно учитывать отдельно, иначе техническая команда будет исправлять маршрут сообщения там, где требуется изменить процесс обслуживания.
Отправлено, доставлено, открыто: что подтверждает каждый сигнал
| Сигнал | Что можно утверждать | Чего он не доказывает |
|---|---|---|
| Отправлено | Система прошла этап, который интеграция называет отправкой | Что сообщение достигло клиента |
| Доставлено | Получено подтверждение доставки в значении конкретного канала | Что человек прочитал текст и понял его |
| Открыто | Зарегистрирован сигнал открытия, например загрузка отслеживающего изображения | Что письмо сознательно открыл человек и выполнил действие |
| Клик | Зарегистрирован переход по отслеживаемой ссылке | Что заказ подтверждён или оплата завершена |
| Действие завершено | Учётная система зафиксировала нужный результат | Что результат возник именно благодаря уведомлению |
Open rate — доля зарегистрированных открытий — полезен как вспомогательный показатель. Но автоматическая загрузка отслеживающих изображений может создавать сигнал без осознанного чтения. Отраслевой отчёт отдельно связывает изменение открываемости с механизмами защиты приватности почтовых клиентов. Отчёт по email за 2025 год.
Загрузка пикселя и клик по ссылке — разные события. Ни одно из них нельзя записывать в выручку. Оплату подтверждает платёжное событие, запись — завершённое бронирование, согласование времени — изменение статуса заказа.
Нажимая «Оставить заявку», вы соглашаетесь с политикой обработки персональных данных.
Прирост действий измеряют по контрольной группе
Инкрементальное действие — действие сверх того, что клиенты совершили бы без тестируемого уведомления. Чтобы оценить этот прирост, до отправки случайным образом распределите подходящих клиентов между группой уведомления и контрольной группой.
Рабочая формула:
Прирост доли целевых действий = доля завершённых действий среди всех назначенных в группу уведомления − доля завершённых действий в контрольной группе.
В группе уведомления остаются и адресаты с недоставкой. Иначе из оценки исчезнет часть реальных потерь системы.
Формула «доля действий среди получивших сообщение минус доля действий в контроле» выглядит убедительно, но сама по себе не доказывает эффект. Доступные контакты могут принадлежать более активным клиентам. Отбор только подтверждённых доставок после распределения нарушает исходную сопоставимость групп.
Долю действий после подтверждённой доставки всё равно нужно считать — для диагностики. Она помогает обнаружить ситуацию, когда сообщение технически доходит, но следующий шаг не выполняется. Причинный эффект оценивают по исходным группам, а доставку используют для объяснения результата.
Контрольная группа сохраняет обязательное обслуживание
Не отключайте сообщения, необходимые для исполнения обязательств, безопасности или своевременного информирования клиента. Для эксперимента выберите необязательное дополнительное напоминание: основное уведомление получают все, тестируемое — только экспериментальная группа.
Если отказаться от сообщения нельзя, сравнивайте допустимые варианты текста, времени или маршрута. Такой тест оценивает улучшение относительно текущего сценария, а не пользу уведомлений вообще.
До запуска зафиксируйте целевое действие, период наблюдения от общего события в CRM и правило завершения эксперимента. Условия обслуживания должны совпадать. При повторных заказах закрепляйте группу за клиентом, чтобы он не получал смешанные сценарии.
Оценивайте не только разницу, но и её неопределённость. Если данных недостаточно, результат следует признать неопределённым. Положительная разница в небольшой выборке ещё не основание масштабировать отправку. Другие подходы к проверке результата собраны в разделе статьи по аналитике.
Рекламная вставка меняет требования к сервисному сообщению
Сравните два учебных шаблона:
Заказ {номер} готов к выдаче. Адрес и время работы: {ссылка}.
Заказ {номер} готов к выдаче. Купите сопутствующий товар со скидкой.
Первый текст обслуживает конкретный заказ. Второй дополнительно продвигает товар и создаёт риск признания сообщения рекламным. Окончательная квалификация зависит от содержания и обстоятельств распространения. Наличие имени клиента и адресного списка само по себе не исключает рекламу. Критерии ФАС России.
По статье 18 Федерального закона — ФЗ — № 38-ФЗ «О рекламе» реклама по сетям электросвязи требует предварительного согласия адресата. Доказывает его получение рекламораспространитель; после требования адресата распространение рекламы нужно прекратить немедленно. Согласие не отменяет других ограничений статьи, включая запрет указанного в ней автоматического выбора или набора абонентского номера для рекламы. Статья 18 закона о рекламе.
Для прямых контактов в целях продвижения товаров также действует требование предварительного согласия на соответствующую обработку персональных данных. Статья 15 закона № 152-ФЗ.
У сервисного сообщения нужно отдельно определить основание обработки контакта. Например, обработка, необходимая для исполнения договора с клиентом, может опираться на это основание. Оно не даёт автоматического разрешения использовать контакт для рекламы. Если основанием служит согласие на обработку персональных данных, его оформляют отдельно от других подтверждаемых документов. Статья 6 и статья 9 закона № 152-ФЗ.
За нарушение требований к рекламе по сетям электросвязи часть 4.1 статьи 14.3 Кодекса Российской Федерации об административных правонарушениях — КоАП РФ — предусматривает штраф для организаций от 300 тыс. до 1 млн рублей. Это санкция за конкретное нарушение, а не автоматический штраф за любое сообщение о заказе. Статья 14.3 КоАП РФ.
Для мобильных рассылок учитывайте также требования статьи 44.1 закона «О связи». Абонент может отказаться от рассылки через оператора; по установленным правилам она прекращается на следующий календарный день, с предусмотренными исключениями. Поэтому флаг согласия в CRM не гарантирует техническую доступность канала. Статья 44.1 закона о связи, порядок отказа от рассылки.
Каскад должен завершаться действием или задачей ответственному
Каскадные уведомления — это последовательное использование разрешённых каналов по заранее заданным условиям. Одновременная отправка одинакового текста повсюду не заменяет правила обработки отказов.
Для каждого события настройте следующий регламент:
| Условие | Действие системы | Кому и когда передать проблему |
|---|---|---|
| Постоянная ошибка контакта | Остановить повторы на этот контакт, проверить допустимый резерв | Ответственному за заказ сразу после окончательного отказа |
| Временная недоступность | Повторить по установленному расписанию в пределах срока актуальности | Ответственному после исчерпания разрешённых попыток |
| Нет окончательного статуса | Уточнить статус; по таймауту запустить разрешённый резерв | Ответственному при исчерпании маршрута или приближении предельного срока |
| Доставка подтверждена, действия нет | Проверить состояние заказа и запустить отдельный сценарий напоминания | Менеджеру по истечении срока ожидаемого действия |
| Заказ отменён или действие выполнено | Остановить отложенные отправки | Сохранить причину завершения в журнале |
Таймаут канала и срок ожидаемого действия — разные настройки. Первый ограничивает ожидание доставки. Второй определяет, сколько клиенту отведено на ответ. Конкретные значения устанавливают по процессу: резерв должен включиться тогда, когда сообщение ещё полезно.
Отдельно обработайте позднее подтверждение доставки. Основное сообщение может дойти уже после запуска резервного. Повторные статусы не должны создавать новые задания, а кнопка подтверждения — повторно менять завершённый заказ.
Шаблон отправляет факт, ИИ-агент обрабатывает продолжение
Для сообщения «заказ готов» достаточно утверждённого шаблона и надёжного механизма отправки. ИИ-агент полезен там, где нужно разобрать ответ клиента, уточнить условия, обновить CRM или передать исключение сотруднику.
Источник фактов о заказе — учётная система. Агенту следует разрешать только предусмотренные действия и формулировки. Он не должен самостоятельно добавлять скидку в сервисное сообщение, объявлять доставку подтверждённой без статуса канала или обещать клиенту неподтверждённый срок.
Стоимость уведомлений считают вместе с повторами и ручной работой
Сначала выясните единицу тарификации: оплачивается попытка, принятое задание или доставленное сообщение. Недоставка не обязательно означает отсутствие списания. Например, в официальной документации государственной системы отдельно указаны оплачиваемые случаи недоставленных SMS. Это иллюстрация тарифной логики; условия своего договора нужно проверять отдельно. Тарификация неуспешных отправок в описании статусов.
Для расчёта используйте:
Стоимость доставленного уведомления = все затраты на цепочку / число уникальных уведомлений с подтверждённой доставкой.
В затраты входят тарифицируемые попытки, резервные каналы, инфраструктура и труд сотрудников. Если одно логическое уведомление дошло по нескольким каналам, в знаменателе оно учитывается однократно, а расходы включаются полностью.
Стоимость целевого действия = все затраты на цепочку / число завершённых целевых действий.
Это показатель затрат на наблюдаемый результат. Он ещё не показывает стоимость дополнительного действия: часть клиентов могла подтвердить заказ без сообщения.
Для сценария с денежным результатом:
Инкрементальная ценность = прирост доли действий по исходным экспериментальным группам × число адресатов сценария × маржинальный доход на дополнительное действие − дополнительные затраты сценария.
Формула применима, если действие связано с доходом, а выбранная маржинальная оценка соответствует заказам. Для информационного статуса уместнее оценивать своевременность доставки и изменение нагрузки на поддержку. Не нужно искусственно приписывать выручку каждому уведомлению.
Сопоставимого нейтрального ценового ориентира для российских SMS и push-уведомлений в рассматриваемых источниках нет. Поэтому бюджет следует считать по собственной тарификации. Срок внедрения также зависит от готовности событий, контактов, обратных статусов и резервного маршрута; подключение отправки само по себе не завершает работу.
Решения, из-за которых уведомления дорожают без результата
- Считать «передано поставщику» доставкой. Отчёт скрывает незавершённые отправки, и менеджер прекращает контроль раньше времени.
- Повторять любую ошибку одинаково. Неверный контакт получает новые попытки вместо задачи на исправление.
- Оценивать эффект только среди получивших сообщение. Из расчёта исключаются потери доставки, а группы перестают быть сопоставимыми.
- Проверять только клики. Неисправное подтверждение заказа остаётся незамеченным при хорошем отчёте по переходам.
- Дописывать рекламный блок в сервисный шаблон. Меняется правовая оценка сообщения, хотя технический маршрут остаётся прежним.
- Запускать резерв без проверки текущего состояния. Клиент получает напоминание после оплаты, отмены или уже данного ответа.
Порядок запуска уведомления о статусе заказа
Начните с одного события, для которого понятны получатель и ожидаемый результат.
- Зафиксируйте событие. Укажите, какое изменение в CRM создаёт задание и как исключается его повторное создание.
- Утвердите содержание. Оставьте сведения о конкретном заказе и нужном действии. Проверьте основания обработки контакта и требования выбранного канала.
- Опишите подтверждение доставки. Запишите, какой статус возвращает интеграция и что именно он означает.
- Настройте резерв и сроки. Задайте таймаут, разрешённые повторы, срок актуальности и сотрудника для эскалации.
- Свяжите действие с заказом. Подтверждение, оплата или запись должны попадать в учётную систему независимо от перехода по отслеживаемой ссылке.
- Проверьте отказные сценарии. В контролируемом тесте воспроизведите неверный контакт, задержку статуса, повтор события, позднюю доставку и отмену заказа.
- Запустите оценку результата. Для необязательного сообщения используйте контрольную группу; для обязательного — сравнение допустимых вариантов обслуживания.
Критерий готовности: у каждого задания есть проверяемый итог либо назначенный ответственный и срок следующего действия. Состояние «отправили и больше не знаем» не должно оставаться без обработки.
Нажимая «Оставить заявку», вы соглашаетесь с политикой обработки персональных данных.
Вывод
Обещание «клиенту придет уведомление» становится управляемым процессом, когда компания видит событие, содержание сообщения, статус доставки и следующий шаг при отказе. Для сценариев, требующих действия, результат нужно подтверждать в учётной системе, а дополнительный эффект — проверять сравнением с контрольной группой.
Если уведомления уже уходят, начните с одного события: опишите его в CRM, сохраните подтверждение доставки и определите, как проверить результат. Если событий много и отправку нужно связать с обработкой ответа клиента, посмотрите, как устроено внедрение ИИ-агентов в контуре компании.