Транзакционные письма: что это и чем отличаются от рекламы

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

Эта статья посвящена сервисным сообщениям. Автоматические маркетинговые цепочки разобраны отдельно — в гайде про триггерные рассылки, а регулярные выпуски и работа с базой — в статье об email-маркетинге.

Что такое транзакционное письмо

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

Смысл письма определяется содержанием и обстоятельствами отправки, а не названием шаблона в сервисе. Уведомление «Ваш заказ принят» остаётся сервисным, пока помогает исполнить запрос клиента. Купон на следующую покупку и подборка товаров добавляют рекламную задачу.

Чем транзакционное письмо отличается от рекламного

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

Формула «это транзакционное письмо» не защищает рекламный блок. Если вы хотите отправлять акции, соберите отдельное согласие и используйте отдельную кампанию. Условия отказа от маркетинговых сообщений описаны в статье про отписку от рассылки.

Какие транзакционные письма нужны интернет-магазину

Минимальный набор повторяет путь заказа. Клиенту не требуется письмо после каждого движения строки в CRM; уведомляйте о событиях, которые меняют его ожидания или требуют действия.

1. Заказ создан. Номер, состав, сумма, способ оплаты и доставки.
2. Оплата подтверждена. Статус расчёта и ссылка на чек либо информация, где он придёт.
3. Статус изменён. Сборка, передача перевозчику или готовность к выдаче — только значимые этапы.
4. Заказ можно получить. Адрес, часы, срок хранения, код или документы.
5. Заказ отменён или изменён. Причина, возврат денег и способ связи.

Если статус не изменился, не отправляйте уведомление ради активности. Пять одинаковых писем «мы собираем заказ» не добавляют информации и снижают доверие к следующим сообщениям.

Что писать в подтверждении заказа

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

Тема: Заказ № 1842 принят

Анна, мы получили заказ № 1842 на сумму 3 460 ₽.
Состав: ежедневник — 1 шт., ручка — 2 шт.
Доставка: пункт выдачи на ул. Лесной, 8.
Сообщим отдельным письмом, когда заказ можно будет забрать.

Если в данных ошибка, ответьте на это письмо или позвоните по номеру [номер].

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

Как оформить письмо с чеком и оплатой

Кассовый чек формируется по правилам расчётов, а email служит одним из каналов доставки. Не подменяйте чек красивым подтверждением «Спасибо за оплату»: если по операции требуется фискальный документ, клиент должен получить именно его предусмотренным способом.

Как отправлять статусы доставки

Письмо должно отвечать на три вопроса: где заказ, что будет дальше, требуется ли действие клиента. Формулировка «статус изменён» заставляет идти в кабинет и искать разницу. Напишите изменение прямо в теме и первом абзаце.

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

Как написать письмо для восстановления доступа

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

Тема: Восстановление доступа

Мы получили запрос на смену пароля для аккаунта a***@example.ru. Ссылка действует 30 минут: [изменить пароль].

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

Ссылка должна быть одноразовой и вести на ваш защищённый домен. Дополнительную защиту аккаунта объясняет статья про двухфакторную аутентификацию.

Как настроить отправку транзакционных писем

Источник события — сайт, приложение, CRM или платёжная система. Он передаёт сервису отправки идентификатор шаблона и нужные поля. Ответ сервиса сохраняют, чтобы видеть, принято ли письмо в обработку.

1. Составьте список событий. Оставьте только те, что полезны клиенту.
2. Назначьте владельца данных. За сумму отвечает заказ, за доставку — складская или логистическая система.
3. Опишите обязательные поля. Без номера заказа или адреса получения письмо не уходит.
4. Создайте шаблон. Добавьте запасной текст для необязательных полей.
5. Передайте событие. Используйте API, SMTP или готовую интеграцию.
6. Сохраните статус. Принято, доставлено, временная либо постоянная ошибка.
7. Пройдите тест. Успех, отказ оплаты, отмена, повторное событие и неверный адрес.

Для отправки от домена настройте его аутентификацию. Что делают записи и как проверять их по очереди, описано в инструкции SPF, DKIM и DMARC.

Что делать, если письмо не пришло

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

Какие метрики отслеживать

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

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

Какие ошибки встречаются чаще всего

• Реклама внутри подтверждения. Подборка товаров смешивает две разные цели.
• Письмо приходит раньше статуса. Клиент открывает кабинет и видит старые данные.
• Нет защиты от дублей. Повторный запрос системы создаёт два одинаковых уведомления.
• Важное спрятано под баннером. Номер и действие не видны на первом экране.
• Адрес no-reply без контакта. Получателю некуда сообщить об ошибке.
• В письме лишние персональные данные. Для подтверждения хватает маскированного адреса или последних цифр.
• Шаблон не проверен без имени. Пустое поле ломает обращение и тему.
• Один шаблон на все статусы. «Ваш заказ обновлён» не объясняет, что произошло.

Если компания собирает и хранит контакты, роли и сроки обработки стоит описать заранее. Базовые обязанности разобраны в статье про персональные данные для бизнеса.

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

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

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

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

Текст сообщения согласуйте с интерфейсом. Кнопка «Изменить адрес» должна вести на экран изменения адреса, а статус в кабинете — совпадать с письмом. Если операция доступна только до начала сборки, покажите срок рядом с кнопкой. Ссылка на главную заставляет клиента заново искать заказ и повышает число обращений.

Подготовьте резервный канал для критичного сбоя, но не дублируйте каждое событие автоматически. Восстановление доступа иногда требует отдельного безопасного процесса; изменение времени доставки можно сообщить тем каналом, который клиент указал для заказа. Общую схему контактов после покупки помогает выбрать разбор «Почта, бот или канал».

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

После запуска разберите обращения за неделю. Фразы клиентов часто точнее метрик показывают пробел: «не понял, оплачен ли заказ», «где код получения», «почему сумма другая». Сгруппируйте вопросы, исправьте верхнюю часть письма и проверьте повторно. Методика сбора таких сигналов есть в материале про обратную связь от клиентов.

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

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

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

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

Чек-лист