Как написать ТЗ на запуск автоматических писем

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

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

Когда нужно ТЗ на триггерные письма

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

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

Раздел 1. Постановка задачи

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

• запустить напоминание о брошенной корзине
• автоматически запрашивать отзыв после заказа
• предложить пользователю сопутствующие продукты

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

Раздел 2. Условия отправки

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

• не продлил подписку на издание на следующий месяц
• сделал первый заказ, но не делает второй
• скачал брошюру «Шпаргалка по выбору цвета»

Условия могут быть многосоставными: в таком случае лучше оперировать правилами «и» и «или». Например, одно и то же письмо в духе «Этот товар может скоро закончиться» может быть отправлено при разных условиях: если человек посмотрел товар, но не добавил в корзину, или добавил в корзину, но не купил в течение N минут, или просмотрел и провёл на странице товара дольше двух минут и т.д. 

Каждое условие нужно расписать как можно более полно — это убережёт от дальнейших недопониманий и дополнительных итераций разработки. 

Раздел 3. Момент отправки

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

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

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

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

• 7-го числа каждого месяца, в 12:00 по мск;
• через 30 дней после присвоения заказу статуса «Выполнен» (в то же самое время, в которое был присвоен статус);
• через 3 дня после скачивания брошюры, в 11:00 по мск (только будний день — если отправка приходится на выходной, сдвигаем на ближайшие понедельник).

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

Раздел 4. Базовые настройки

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

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

Email отправителя — с какого адреса будет отправлено письмо / куда присылать ответы.

Имя отправителя — содержание строки «От кого» (From) в почтовом клиенте.

Тема письма — содержание строки «Тема» (Subject line) в почтовом клиенте.

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

Раздел 5. Содержание письма

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

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

Как сверстать адаптивное письмо

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

Раздел 6. Динамический контент

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

Как использовать автоподстановки и динамический контент в email-рассылке

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

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

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

• {{Имя}} — подставляем имя пользователя (например, Сергей).
• {{email}} — подставляем email-адрес пользователя, на который отправили рассылку.
• {{ДД.ММ.ГГ}} — подставляем дату окончания действия промокода (например, 03.02.20).

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

Раздел 7. Пример реализации

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

Часто это значительно упрощает понимание задачи.

Результат

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

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

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

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

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