Триггерные письма — это автоматические сообщения, которые отправляются в ответ на определённые события (триггеры), связанные с пользователем: подписку на рассылку, регистрацию, оформление заказа.

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

Настройка сценариев триггерных писем в сервисе рассылок. В UniSender за это отвечает раздел «Автоматизация»
Настройка сценариев триггерных писем в сервисе рассылок. В UniSender за это отвечает раздел «Автоматизация»

Но такой путь подойдёт не всегда. Иногда сервис не может реализовать сценарий: у него не хватает функционала или нужна слишком сложная интеграция.

Решить проблему можно 2 способами.

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

Настроить отправку писем своими силами, через CMS или CRM-систему. Этот способ дешевле, быстрее и проще. В CMS/CRM, которую мы используем на проекте, уже есть все нужные данные. Как правило, этот движок умеет отправлять письма — остаётся настроить нужный сценарий. Для этого нам понадобится помощь веб-программиста / студии, которая разрабатывала наш сайт или занимается его техподдержкой.

При этом мало просто поручить специалисту настройку триггерных писем. Чтобы получить хороший результат на выходе, нужно написать подробное техническое задание на внедрение (ТЗ).

В своей работе я пользуюсь следующей структурой ТЗ по каждому триггерному письму, которое собираюсь запустить:

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

Постановка задачи

Начинаем ТЗ, как водится, с общей постановки задачи:

запустить напоминание о брошенной корзине…

автоматически запрашивать отзыв после заказа…

предложить пользователю сопутствующие продукты…

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

Условия отправки

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

не продлил подписку на издание на следующий месяц…

сделал первый заказ, но не делает второй…

скачал брошюру «Шпаргалка по выбору цвета»…

Момент отправки

Если условие наступило, это не значит, что письмо должно уйти мгновенно.

Я предпочитаю обособлять это отдельным пунктом ТЗ, где конкретно описываю всё, что касается момента отправки:

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

Например, письмо отправляется:

7-го числа каждого месяца, в 12:00 по мск…

через 30 дней после присвоения заказу статуса «Выполнен» (в то же самое время, в которое был присвоен статус)…

через 3 дня после скачивания брошюры, в 11:00 по мск (только будний день — если отправка приходится на выходной, сдвигаем на ближайшие понедельник)…

Базовые настройки

Почти в любой системе есть какой-то простой интерфейс для работы с письмами. 

Как правило в нём отдельными полями выносятся:

  • Email отправителя — с какого адреса будет отправлено письмо / куда присылать ответы.
  • Имя отправителя — содержание строки «От кого» (From) в почтовом клиенте.
  • Тема письма — содержание строки «Тема» (Subject line) в почтовом клиенте.
Базовые настройки письма, например, в CRM
Базовые настройки письма, например, в CRM

Тему, адрес и имя отправителя удобно прописать отдельно в ТЗ, в качестве «базовых» настроек.

Содержание письма

Даём ссылку на HTML-код письма. На мой взгляд, это принципиальный момент. Не стоит нагружать программиста ещё и «упаковкой» контента. Это специфическая работа, которую лучше или выполнить самому — на базе онлайн-конструктора писем — или поручить email-верстальщику.

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

Из нюансов: во всех ссылках письма стоит заранее прописать UTM-метки —  обычно наша «домашняя» система не имеет функционала по их автоматической простановке. Или дополнительно обсудить этот момент с программистом, чтобы он добавил UTM при внедрении.

Динамический контент

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

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

Подставлять динамический контент из базы данных будет программист. Но в самом письме нам нужно разметить места для подстановок. Обычно я пользуюсь условными обозначениями вида {{dinamic_tag}}, которые добавляю в HTML-код:

Условные теги {{...}} показывают, где в письме динамический контент
Условные теги {{…}} показывают, где в письме динамический контент

В ТЗ, в отдельном разделе я прописываю, что именно нужно подставлять вместо тегов:

{{Имя}} — подставляем имя пользователя (например, Сергей).

{{email}} — подставляем email-адрес пользователя, на который отправили рассылку.

{{ДД.ММ.ГГ}} — подставляем дату окончания действия промокода (например, 03.02.20).

Я рекомендую предусматривать ссылку отписки как элемент динамического контента.

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

Пример реализации

Также я добавляю в ТЗ конкретный пример, как задуманный сценарий должен срабатывать:

Описание сценария работы писем по шагам, с конкретными данными
Описание сценария работы писем по шагам, с конкретными данными

Часто это значительно упрощает понимание задачи и добавляет объёма к ТЗ.

Результат

На выходе мы получаем документ — в нём где-то по 2-3 страницы на каждое письмо:

Далее передаём его в работу программисту. Не пускаем дело на самотёк и активно сопровождаем внедрение — отвечаем на вопросы, возможно, что-то корректируем по ходу дела:

Обсуждение деталей с разработчиком
Обсуждение деталей с разработчиком

Затем принимаем результат. На тестирование и отладку писем лучше заложить отдельное время — это полноценная задача, которая требует нашего внимания. Даже если мы детально прописали всё в ТЗ, вряд ли задуманная механика заработает как нужно с первого раза. Скорее всего понадобится несколько циклов тестирования / исправления ошибок.

Во время тестов испытываем систему «на прочность», инициируя несколько событий одновременно, в разной последовательности, с разными условиями. Например, бросаем корзину, затем оформляем заказ, снова добавляем товары в корзину, но почти сразу удаляем их. Смотрим, какие письма нам в этом случае приходят.

Подробное ТЗ на внедрение помогает получить на выходе то, что запланировали, вплоть до малейших нюансов и деталей. А именно из таких мелочей и складывается полноценный email-маркетинг.

Запись Как написать ТЗ на запуск автоматических писем впервые появилась Блог UniSender.

Читать далее

©