Уведомления с сайта: как проверить, что письма и сообщения дошли до клиента

Сайт отвечает за путь сообщения, а не за нажатие кнопки

Приёмку уведомлений с сайта заканчивают на результате доставки: создание письма сообщает только о начале его пути к покупателю. Разберём магазин, который отправляет подтверждение заказа через API обычного Unisender командой sendEmail. API — способ обмена данными между сайтом и сервисом, а sendEmail отправляет отдельное письмо. По критериям ниже маркетолог сможет принять эту связь и разобраться, почему клиент не получил подтверждение заказа.

Письмо сопровождает заказ. Сам заказ хранится на сайте и остаётся доступным магазину, даже если уведомление не дошло.

Это разделение защищает покупку: если сотрудник узнаёт о ней только из письма, сбой уведомления фактически остановит обработку заказа, хотя сведения о покупке уже сохранены независимо от почтовой доставки.

Начните с экрана, где сотрудник видит новые заказы независимо от почты. Это надёжнее общего почтового ящика: доступность продажи не связана с тем, примет ли письмо сервер клиента. Ответственный сможет продолжить обработку покупки и отдельно разобраться с уведомлением, не разыскивая заказ в цепочке писем. Если же почта остаётся единственным сигналом для отдела, подключение другого сервиса сохранит прежнюю уязвимость. Отказ адреса или фильтр спама снова скроют покупку от сотрудника, хотя на сайте уже сохранены её состав и обязательства магазина. Сначала отделу дают доступ к заказам, затем принимают доставку сообщений.

Какая покупка породила письмо и кому оно предназначено

Письмо связывают с определённым событием заказа, чтобы покупатель узнал, что изменилось и требуется ли от него действие. Подтверждение покупки, сообщение об оплате и сведения о передаче в доставку отвечают на разные вопросы. Если запускать отправку при любом сохранении карточки, исправление заметки менеджером тоже породит уведомление. Клиент получит повтор без понятной причины, а отделу придётся выяснять, действительно ли операция выполнена дважды. Для каждого вида письма заранее называют событие, адресата и содержание, а запись об отправке связывают с той покупкой, по которой событие произошло.

Для отдельного событийного письма документация Unisender sendEmail предусматривает адрес получателя и подтверждённый адрес отправителя sender_email. При неподтверждённом отправителе встречается ошибка unchecked_sender_email.

Покупатель и сотрудник — разные получатели. Подтверждение клиенту не содержит внутренние замечания магазина, а служебное уведомление не подменяет клиентский ответ.

Содержание принимают отдельно от доставки. В клиентском письме оставляют состав покупки и следующий шаг, которые помогут человеку продолжить заказ, а замечания менеджера для коллег выносят в служебное сообщение: покупателю они ничего не объяснят и могут раскрыть обсуждение, адресованное только сотрудникам. Ответственный за продажи утверждает оба текста до подключения отправки.

Для письма берут контакт, указанный в заказе. Если покупатель исправил контакт после покупки, магазин определяет, куда отправить повторное уведомление и как сохранить связь с исходным заказом. Последний адрес из профиля переносится в заказ только после выяснения, к кому он относится. Иначе сведения о покупке могут уйти другому получателю. Ошибку контакта исправляет сотрудник по принятому порядку, а не бесконечная серия отправок.

Отправлено, доставлено и прочитано означают разное

Магазин сохраняет идентификатор сообщения — номер, по которому сервис отвечает о судьбе конкретного письма. Рядом остаётся связь с заказом, поэтому сотрудник видит, о какой покупке идёт речь, даже когда клиент сообщает только, что подтверждения нет. Полученный номер означает приём отправки, а результат доставки запрашивается отдельно и может прийти позже. Если состояние ещё неизвестно, рабочий экран оставляет ожидание видимым. Преждевременная отметка об успехе закроет проблему для отдела, который тогда узнает о ней только из жалобы покупателя. При сдаче интеграции покажите путь от заказа к последнему состоянию его сообщения.

В описании метода checkEmail ok_sent — промежуточное состояние отправки. Оно ещё не является подтверждением доставки.

Статус ok_delivered означает доставку. Чтобы понять, завершён ли разговор, отдельно учитывают ответ или нужное действие покупателя: почтовое подтверждение сообщает о результате передачи письма, а договорённость с человеком появляется в переписке по заказу.

Код ok_spam_folder означает, что сервер получателя доставил письмо в папку спама. Для клиента такое уведомление легко останется незамеченным, хотя техническая передача завершена. Если из-за отсутствующего ответа останавливается доставка заказа, сотрудник связывается с покупателем доступным способом и выясняет нужные сведения. Обсуждение папки спама помогает найти письмо, но заказ продолжает вести отдел.

Повторная попытка не всегда означает новое письмо

При err_will_retry сервис продолжает попытки доставки того же письма. Если сайт создаст ещё одно сообщение, покупатель может получить оба после устранения временного сбоя. Поэтому в этот момент запрашивают состояние прежней отправки, а решение о новом письме принимают по её исходу. Два одинаковых подтверждения оплаты способны заставить клиента искать повторное списание. Привязка каждой попытки к событию заказа помогает сотруднику объяснить, что происходило, и отделить повтор сообщения от повторной операции.

Обрыв соединения оставляет результат неизвестным. Сервис мог принять сообщение до того, как сайт перестал получать ответ.

Кнопку повторной отправки связывают с историей события заказа: при сохранённом идентификаторе сотрудник сначала получает состояние прежнего письма, после окончательного отказа выясняет причину, а новое письмо отправляет после устранения причины отказа с актуальными сведениями о покупке. Для неизвестного результата без идентификатора потребуется отдельный разбор: слепой повтор лишь перенесёт неопределённость в переписку клиента.

Исправленный адрес создаёт другой случай. Здесь повторная отправка оправдана после подтверждения контакта, но в журнале остаётся причина и связь с прежней попыткой. Сотрудник видит, что первое письмо не доставлено, а не считает обе записи отдельными уведомлениями о разных заказах. Сам текст пересматривается, если состояние покупки уже изменилось.

Ограничения сервиса входят в поведение магазина

Два события покупки могут произойти почти одновременно, но каждое сообщение придётся пропустить через правила сервиса. В документации sendEmail минимальный интервал для одного адресата составляет 60 секунд. Это относится к отправке через обычный Unisender, а правила отдельного сервиса Unisender Go здесь не рассматриваются. Очередь предпочтительнее немедленного повторения запроса: сайт сохраняет ещё не отправленное уведомление, сотрудник видит причину задержки, а покупатель позже получает сведения о состоявшемся событии без отдельного разбирательства о пропавшем письме и лишних одинаковых подтверждениях. Если подтверждение заказа и оплаты решено объединить, письмо отражает оба свершившихся события. Исполнитель объясняет выбранный порядок ожидания, а сотрудник видит его результат в записи заказа.

Обработку заказа продолжают без письма. Сотруднику объясняют задержку уведомления, чтобы он мог ответить покупателю и не запускал лишнюю отправку.

Поле ref_key позволяет сайту задать письму уникальный ключ-идентификатор. Документация требует уникальности, но не описывает это поле как готовый запрет повторной отправки. Защиту от дублей принимают отдельно: повтор события заказа не создаёт новый экземпляр уже принятого сообщения.

Сведения об отказе нужны сразу на рабочем экране. Документация рекомендует передавать error_checking=1, чтобы получать расширенный результат с ошибками отправки. Например, неподтверждённый адрес отправителя возвращает unchecked_sender_email. Сотруднику рядом с таким кодом дают пояснение и имя ответственного за почтовое подключение. Тогда отказ адреса клиента разбирает тот, кто ведёт заказ, а проблему настройки отправителя — специалист по интеграции.

Срок хранения статуса не равен сроку хранения заказа

Сервисный журнал — временная история доставки. Документация checkEmail указывает, что статусы хранятся только месяц. Если клиент вернётся к покупке после этого срока, сотруднику понадобится собственная запись магазина: по событию заказа он найдёт прежнее письмо, увидит последний полученный результат доставки и сможет объяснить ход обработки обращения без повторного запроса к уже очищенному сервисному журналу. Срок и доступ к этой истории компания определяет по своим задачам. Она связывает событие с сообщением и последним полученным состоянием, не копируя лишние персональные данные.

Долгое хранение не требует полного письма. Для части задач достаточно времени, вида сообщения и результата, а содержание доступно из версии шаблона и данных заказа по разрешённому доступу.

Передавать каждому сотруднику ключ API ради просмотра статусов неразумно, потому что журнал магазина способен показать нужный результат с правами по его рабочей роли, тогда как секрет доступа открывает технические возможности шире обычного разбора заказа.

В рабочем экране удобнее понятное название события и ссылка на покупку, чем один англоязычный код. Исходный статус тоже сохраняют: он понадобится специалисту для разбора отказа. Рядом сотрудник видит объяснение, продолжает заказ и передаёт проблему нужному ответственному.

Почта и сообщения в другом канале принимаются отдельно

Успешное письмо не подтверждает работу SMS или мессенджера. Другой канал требует своего адресата, условий отправки и статусов. Если магазин поддерживает несколько способов, для каждого описывают собственный путь сообщения. Это не повод автоматически дублировать любое письмо везде. Один покупатель не должен получить серию сообщений с одинаковым содержанием только потому, что у компании есть несколько подключений.

Канал выбирается по задаче. Подтверждение с подробностями заказа отличается от короткого напоминания и от важного уточнения, без которого доставка остановится.

Для дополнительного канала попросите показать его ограничения и смысл результата доставки, чтобы решение о повторной отправке опиралось на ответ этого сервиса, а не на знакомое название почтового статуса, которое специалист перенёс в общий экран магазина. После этого станет ясно, какое сообщение нужно повторить, а по какому ещё продолжаются попытки.

Критерии этой статьи относятся к почтовому пути sendEmail. Дополнительные каналы остаются отдельным объёмом работ, если они нужны компании. Разбор того, какие вопросы возникают после покупки, можно связать с причинами обращений в поддержку: повторные вопросы о заказе помогут выбрать содержание уведомлений, но не подменят проверку самой доставки.

Приёмка закончена, когда отказ виден и его можно разобрать

При сдаче пройдите основные исходы на согласованных тестовых адресах и сопоставьте запись заказа с ответом сервиса. Так станет видно, способен ли сотрудник продолжить покупку без помощи разработчика, а не только открыть технический журнал. Ошибки моделируют на тестовых данных. Для этой интеграции нужны следующие результаты:

1. Обычная отправка. Письмо связано с заказом, адресатом и полученным идентификатором. Позже появляется результат доставки.
2. Несуществующий адрес. Видны окончательный отказ и сотрудник, который уточнит контакт перед новой отправкой.
3. Неподтверждённый отправитель. Ошибка передаётся ответственному за подключение, а покупка остаётся доступной отделу.
4. Продолжающаяся попытка. Ожидающее письмо сохраняет прежний идентификатор. Новый дубль автоматически не создаётся.
5. Повтор события заказа. Уже принятое уведомление не отправляется заново. Для намеренного повтора остаются причина и связь с прежней попыткой.

Магазин знает, какое событие породило письмо, кому оно ушло, чем завершилась доставка и кто исправляет отказ.

Эти сведения полезнее общего обещания настроить почту, потому что после передачи интеграции сотрудник сможет продолжить обработку заказа и при ошибке сообщения, не ожидая, пока разработчик вручную найдёт скрытый технический журнал.

Для настройки писем в ШТАБ ИТ подготовьте события заказа, название сервиса и примеры текущих состояний без ключей доступа. По ним можно определить объём доработки и принять её на понятных исходах доставки.