ТЗ на автоматические письма: как объяснить разработчику, что вы хотите
Время прочтения: 15 минут
Автор: Мария Агеева
Автор: Мария Агеева
Автоматические письма сами ничего не «автоматизируют», если у вас нет нормального ТЗ. Именно оно превращает идею «давайте вернём клиентов из брошенной корзины» в понятный разработчику сценарий: какие события ловим, какие данные передаём и какое письмо уходит в каждый момент. Рассказываем, как описать это всё так, чтобы цепочка действительно заработала, а не превратилась в бесконечную переписку с программистом.
Автоматические письма сами ничего не «автоматизируют», если у вас нет нормального ТЗ. Именно оно превращает идею «давайте вернём клиентов из брошенной корзины» в понятный разработчику сценарий: какие события ловим, какие данные передаём и какое письмо уходит в каждый момент. Рассказываем, как описать это всё так, чтобы цепочка действительно заработала, а не превратилась в бесконечную переписку с программистом.
Триггерные письма
Это автоматические сообщения или цепочки, которые отправляются по принципу «если — то». Произошло событие или выполнилось условие — уходит письмо с нужным контекстом и призывом к действию. Классические примеры: welcome‑серия после регистрации, подтверждение подписки, брошенная корзина, напоминание об оплате, письмо после заказа, реактивация неактивных подписчиков, поздравления с днём рождения.
Когда нужно ТЗ на триггерные письма
Через какие уровни сложности вообще проходят автоматические письма? С одной стороны — простые сценарии, которые маркетолог спокойно собирает в интерфейсе ESP. С другой — сложные цепочки, завязанные на поведение пользователя в продукте, CRM, оплатах и кастомных событиях. В первом случае достаточно аккуратно настроить сервис рассылок. Во втором — без нормального ТЗ и разработчика можно даже не стартовать: всё упрётся в данные и интеграции.
Когда достаточно простого ESP
ESP (Email Service Provider) — это сервис рассылок, в котором вы храните контакты, собираете подписчиков, отправляете кампании и настраиваете базовую автоматизацию: welcome‑цепочки, серии после подписки, реакции на открытие или клик. Его логика строится вокруг списков, тегов и простых триггеров внутри самого сервиса.
Если ваш сценарий укладывается в эту модель, полноценное техническое задание может и не понадобиться. Достаточно внутреннего мини‑ТЗ для маркетолога или интегратора:
- что является триггером (подписка через форму, добавление тега, перенос контакта в список);
- какую цепочку писем он запускает и с какими задержками;
- какие поля из карточки подписчика используются в письмах (имя, город, интерес, тариф и т. п.).
Типичные задачи для «простого» ESP:
- welcome‑серия после подписки на рассылку или лид‑магнит;
- одиночное письмо с обещанным бонусом/материалом;
- напоминание об оставленной форме заявки, если сервис умеет ловить это событие;
- заказ переходит по цепочке статусов в CRM — после «Выполнен» через 10 дней уходит запрос отзыва (в настройке указать, при каком статусе сделки передается контакт);
- простая онбординг‑цепочка внутри онлайн‑курса или сервиса, если основная логика уже реализована в ESP.
Во всех этих случаях вы работаете с теми данными, которые уже «живут» в сервисе рассылок, максимум — подключаете готовый коннектор к CRM или платёжной системе. Разработчик может понадобиться только один раз: настроить интеграцию и прописать нужные поля. Дальше всё управление сценариями лежит на стороне маркетолога.
Когда без полноценного ТЗ и участия разработчика лучше не начинать
Как только вы выходите за рамки «подписался → получил серию» и начинаете опираться на реальное поведение пользователя в продукте, одного ESP уже не хватает. Вам нужно понимать, что человек делает на сайте или в приложении, какие статусы получает его заказ, как меняется подписка, сколько бонусов он накопил и какие события происходят в CRM. Здесь в игру вступают CDP‑платформы или собственные системы, а вместе с ними — необходимость в полноценном ТЗ.
В таких сценариях триггер живёт уже не внутри сервиса рассылок, а в вашей инфраструктуре:
- пользователь заходит в личный кабинет каждый день, но перестаёт появляться — запускается реактивация;
- платёжный шлюз фиксирует просроченную оплату — стартует последовательность напоминаний;
- CDP анализирует просмотры и покупки и формирует персональные подборки для триггеров «Рекомендуем к покупке», «Вернитесь, у нас есть новинки по вашим интересам».
Здесь уже мало сказать «хотим письмо после заказа». Нужно заранее описать:
- какие события, статусы и поля считать триггером;
- где именно они возникают (CRM, сайт, CDP, платёжный агрегатор, который принимает оплату от покупателей на сайте и передаёт деньги на расчётный счёт) и как передаются в систему рассылок;
- какой набор данных нужен в письме: от имени до состава заказа и рекомендованных товаров;
- как сценарии будут пересекаться между собой и что делать при конфликте (например, когда одновременно срабатывают «брошенная корзина» и «реактивация»).
Без структурированного ТЗ разработчик видит только набор общих пожеланий и документацию к API. В результате либо реализуется минимальный, «обрезанный» сценарий, либо проект превращается в нескончаемую серию уточнений и переделок. Полноценное Т З в таких кейсах — не бюрократия, а единственный способ собрать из событий, полей и запросов живую систему триггеров, которая действительно будет приносить деньги, а не просто «что‑то отправлять».
Шаг 1. Постановка задачи: куда и зачем идём
Этот блок задаёт вектор: ради чего вы вообще запускаете автоматические письма. Без такой рамки легко уйти в набор разрозненных триггеров, которые «что‑то отправляют», но не двигают важные метрики.
Что важно зафиксировать:
Бизнес‑цель: уменьшить долю брошенных корзин, увеличить долю повторных заказов, снизить отток подписки, повысить вовлечённость в продукт, вернуть «спящих» подписчиков;
KPI и горизонт: на какие показатели вы смотрите (конверсия в покупку, количество повторных заказов, open/click, реактивация базы) и в каком периоде планируете оценку;
Бизнес‑цель: уменьшить долю брошенных корзин, увеличить долю повторных заказов, снизить отток подписки, повысить вовлечённость в продукт, вернуть «спящих» подписчиков;
KPI и горизонт: на какие показатели вы смотрите (конверсия в покупку, количество повторных заказов, open/click, реактивация базы) и в каком периоде планируете оценку;
Вклад сценария в воронку: на каком этапе customer journey триггер включается и куда должен перевести пользователя (из «зарегистрировался» в «активировался», из «первый заказ» в «второй заказ» и т. п.).
Хорошее ТЗ всегда привязано к конкретным формулировкам: «снизить долю брошенных корзин с 70% до 60% за 3 месяца», «вернуть 3−5% неактивных клиентов за 90 дней». Тогда и маркетологу, и разработчику проще принимать решения: стоит ли, например, усложнять логику или достаточно одной‑двух простых веток.
Хорошее ТЗ всегда привязано к конкретным формулировкам: «снизить долю брошенных корзин с 70% до 60% за 3 месяца», «вернуть 3−5% неактивных клиентов за 90 дней». Тогда и маркетологу, и разработчику проще принимать решения: стоит ли, например, усложнять логику или достаточно одной‑двух простых веток.
Шаг 2. Условия отправки: точная формулировка триггера
Здесь вы формализуете принцип «если — то»: какое именно событие в какой системе считается пусковым крючком, какие фильтры и исключения к нему применять. Это критичный блок: одна расплывчатая фраза — и сценарий начинает стрелять по не тем людям.
В ТЗ стоит описать:
Событие/состояние: «создан аккаунт», «подтверждён email», «изменился статус заказа на „Выполнен“», «количество бонусных баллов достигло 1000», «пользователь не заходил в аккаунт 14 дней», «оформлен платный аккаунт»;
Источник события: сайт, CRM, платёжный шлюз, CDP, приложение, внешняя платформа;
дополнительные условия: минимальная сумма заказа, принадлежность к сегменту, канал привлечения, возраст аккаунта, наличие согласия на рассылку;
Событие/состояние: «создан аккаунт», «подтверждён email», «изменился статус заказа на „Выполнен“», «количество бонусных баллов достигло 1000», «пользователь не заходил в аккаунт 14 дней», «оформлен платный аккаунт»;
Источник события: сайт, CRM, платёжный шлюз, CDP, приложение, внешняя платформа;
дополнительные условия: минимальная сумма заказа, принадлежность к сегменту, канал привлечения, возраст аккаунта, наличие согласия на рассылку;
Исключения: не отправлять тем, кто уже получил эту цепочку за последние N дней, не отправлять одновременно с более важным триггером (например, счётом или критическим уведомлением) и т.д.
Сложную логику описывают через операторы «И» / «ИЛИ», лучше прямо в текст ТЗ:
«Письмо отправляем, если (статус заказа = „Выполнен“ И сумма заказа ≥ 5000) ИЛИ (клиент — постоянный, с ≥3 заказами за год)»;
«Реактивационное письмо отправляем, если (клиент получал письма (статус „Доставлено“) за последние 90 дней) И (не открывал сообщения) И (не было заказов в этот период) И (доступен к рассылкам (не отписался и емейл корректно указан)».
Сложную логику описывают через операторы «И» / «ИЛИ», лучше прямо в текст ТЗ:
«Письмо отправляем, если (статус заказа = „Выполнен“ И сумма заказа ≥ 5000) ИЛИ (клиент — постоянный, с ≥3 заказами за год)»;
«Реактивационное письмо отправляем, если (клиент получал письма (статус „Доставлено“) за последние 90 дней) И (не открывал сообщения) И (не было заказов в этот период) И (доступен к рассылкам (не отписался и емейл корректно указан)».
Шаг 3. Момент отправки: тайминг и ограничения
Даже идеальный триггер можно убить неверным временем отправки. Очень важно, когда именно письмо должно уйти, если условия выполнены.
ТЗ стоит дополнить нюансами:
Задержка после события: «отправить сразу», «через 30 минут», «через 2 дня», «через 10 дней после статуса „Выполнен“», «через 7 дней до истечения подписки»;
Фиксированные даты: «7 числа каждого месяца», «в день рождения», «за неделю до вебинара, затем за сутки и за час»;
Задержка после события: «отправить сразу», «через 30 минут», «через 2 дня», «через 10 дней после статуса „Выполнен“», «через 7 дней до истечения подписки»;
Фиксированные даты: «7 числа каждого месяца», «в день рождения», «за неделю до вебинара, затем за сутки и за час»;
Ограничения по времени суток и дням недели: не отправлять B2B‑письма ночью и в выходные, переносить отправку на ближайший рабочий день, избегать пересечения с массовыми рассылками;
Учёт часовых поясов: важно для продуктов с географически распределённой аудиторией, особенно когда «утро» пользователя и ваше «утро» — разные вещи.
Практика показывает, что универсального «лучшего времени» нет. Его ищут через A/B‑ и мультивариантные тесты: разные окна, разные дни недели, разный лаг после события. Поэтому в ТЗ можно сразу заложить возможность тестов: «нужна возможность запускать сценарий с двумя вариантами времени отправки и сравнивать результаты».
Учёт часовых поясов: важно для продуктов с географически распределённой аудиторией, особенно когда «утро» пользователя и ваше «утро» — разные вещи.
Практика показывает, что универсального «лучшего времени» нет. Его ищут через A/B‑ и мультивариантные тесты: разные окна, разные дни недели, разный лаг после события. Поэтому в ТЗ можно сразу заложить возможность тестов: «нужна возможность запускать сценарий с двумя вариантами времени отправки и сравнивать результаты».
Шаг 4. Базовые настройки: отправитель, темы, технические нюансы
Этот блок часто недооценивают, а он сильно влияет и на доставляемость, и на восприятие писем.
Что важно описать:
Домен и адрес отправителя: с какого домена уйдут письма, настроены ли SPF/DKIM/DMARC, есть ли отдельный поддомен под транзакционные/маркетинговые письма;
Домен и адрес отправителя: с какого домена уйдут письма, настроены ли SPF/DKIM/DMARC, есть ли отдельный поддомен под транзакционные/маркетинговые письма;
Имя отправителя: бренд, подразделение или конкретный «персонаж»; в e‑commerce хорошо работают понятные комбинации вроде «Бренд — магазин», «Бренд — служба заботы», в медиа — «Бренд — новости», «Бренд — дайджест»;
Принципы формирования тем: отражать контекст («что произошло и зачем письмо»), делать призыв к действию понятным и избегать пустых формулировок вроде «Важно» или «Срочно»; лёгкое ощущение срочности допускается, агрессивный кликбейт — нет.
На уровне ТЗ имеет смысл зафиксировать и технические ограничения: максимальный размер письма, допустимые вложения/ссылки, нужны ли A/B‑тесты тем, где будут настраиваться эти тесты — на стороне ESP или вашей системы.
Принципы формирования тем: отражать контекст («что произошло и зачем письмо»), делать призыв к действию понятным и избегать пустых формулировок вроде «Важно» или «Срочно»; лёгкое ощущение срочности допускается, агрессивный кликбейт — нет.
На уровне ТЗ имеет смысл зафиксировать и технические ограничения: максимальный размер письма, допустимые вложения/ссылки, нужны ли A/B‑тесты тем, где будут настраиваться эти тесты — на стороне ESP или вашей системы.
Шаг 5. Содержание письма: структура, логика, аналитика
Содержимое — не просто текст и дизайн, а инструмент, который должен поддерживать ту самую цель из первого раздела.
В ТЗ можно структурировать этот блок так:
Сценарий по письмам: для каждой цепочки — кратко, что делает письмо № 1, № 2, № 3 (например: «напоминает и объясняет выгоду», «добавляет социальное доказательство», «даёт ограниченную по сроку скидку»);
Контент и формат: продажное письмо, обучающее, обзорное, подборка, приглашение на событие; какие блоки в письме обязательны — оффер, выгоды, социальное доказательство, FAQ, кнопка CTA;
Дизайн и вёрстка: будете ли вы использовать блочный редактор ESP, внешний HTML, есть ли гайдлайны бренда по стилю, типографике, изображениям;
Сценарий по письмам: для каждой цепочки — кратко, что делает письмо № 1, № 2, № 3 (например: «напоминает и объясняет выгоду», «добавляет социальное доказательство», «даёт ограниченную по сроку скидку»);
Контент и формат: продажное письмо, обучающее, обзорное, подборка, приглашение на событие; какие блоки в письме обязательны — оффер, выгоды, социальное доказательство, FAQ, кнопка CTA;
Дизайн и вёрстка: будете ли вы использовать блочный редактор ESP, внешний HTML, есть ли гайдлайны бренда по стилю, типографике, изображениям;
Аналитика: какие события клика/просмотра нужно отслеживать (клика по основным кнопкам, переход по второстепенным ссылкам, скролл до определённых блоков, карта кликов).
UTM‑метки и разметка ссылок — обязательный пункт. Фиксируйте:
Единый шаблон UTM для сценария (utm_source, utm_medium, utm_campaign, utm_content);
Кто их подставляет — вы в HTML или разработчик через автоматическое дополнение ссылок;
Нужны ли разные UTM для разных писем/веток сценария (чтобы видеть, какое письмо реально продаёт).
Хороший тон — сразу предусмотреть A/B‑тесты ключевых элементов: темы, первого экрана, CTA‑кнопки, размера скидки. В ТЗ можно отметить: «нужна возможность запускать A/B‑тест по двум вариантам письма в рамках одного триггера».
UTM‑метки и разметка ссылок — обязательный пункт. Фиксируйте:
Единый шаблон UTM для сценария (utm_source, utm_medium, utm_campaign, utm_content);
Кто их подставляет — вы в HTML или разработчик через автоматическое дополнение ссылок;
Нужны ли разные UTM для разных писем/веток сценария (чтобы видеть, какое письмо реально продаёт).
Хороший тон — сразу предусмотреть A/B‑тесты ключевых элементов: темы, первого экрана, CTA‑кнопки, размера скидки. В ТЗ можно отметить: «нужна возможность запускать A/B‑тест по двум вариантам письма в рамках одного триггера».
Шаг 6. Динамический контент: переменные, правила, «что если данных нет»
Динамика — то, что превращает массовый шаблон в персональное письмо: имя, товары, бонусы, рекомендации, поведение.
Расширьте этот блок в ТЗ до полноценной «карты переменных»:
Перечень всех дополнительных полей: {{first_name}}, {{email}}, {{order_id}}, {{order_date}}, {{order_total}}, {{bonus_balance}}, {{promo_code}}, {{promo_expire_date}}, {{preferences}} и т. д.;
Описание каждого поля: источник данных (ESP, CRM, CDP, сайт), формат (строка, число, дата), обязательность, дефолтное значение, если данные отсутствуют («если нет имени — обращаться „Здравствуйте“»);
Перечень всех дополнительных полей: {{first_name}}, {{email}}, {{order_id}}, {{order_date}}, {{order_total}}, {{bonus_balance}}, {{promo_code}}, {{promo_expire_date}}, {{preferences}} и т. д.;
Описание каждого поля: источник данных (ESP, CRM, CDP, сайт), формат (строка, число, дата), обязательность, дефолтное значение, если данные отсутствуют («если нет имени — обращаться „Здравствуйте“»);
Логика генерации: как считается дата окончания промокода, каким алгоритмом выбираются товары в блоке рекомендаций (по просмотрам, по истории покупок, по популярности, по марже), как формируются персональные скидки.
Отдельно пропишите:
Обязательность ссылки отписки {{unsubscribe}} и формат её передачи, чтобы сервис корректно маркировал отписавшихся;
Как отписка отражается во внешних системах: когда человек кликает по ссылке, какие статусы меняются в CRM/CDP, какие сегменты обновляются;
Что делать, если динамический блок не может быть заполнен (нет товаров, нет бонусов): скрыть блок, подставить заглушку или не отправлять письмо.
Чем точнее описана динамика, тем меньше риск увидеть «{{Имя}}» вместо имени или пустые блоки с товарами в боевой рассылке.
Отдельно пропишите:
Обязательность ссылки отписки {{unsubscribe}} и формат её передачи, чтобы сервис корректно маркировал отписавшихся;
Как отписка отражается во внешних системах: когда человек кликает по ссылке, какие статусы меняются в CRM/CDP, какие сегменты обновляются;
Что делать, если динамический блок не может быть заполнен (нет товаров, нет бонусов): скрыть блок, подставить заглушку или не отправлять письмо.
Чем точнее описана динамика, тем меньше риск увидеть «{{Имя}}» вместо имени или пустые блоки с товарами в боевой рассылке.
Шаг 7. Пример реализации: сценарий целиком
Один‑два примера «живого» сценария часто ценнее десятка абстрактных формулировок. Хорошо, если вы показываете не только условия и время, но и связь с целями и метриками.
Например, сценарий «Брошенная корзина»:
Цель: снизить долю брошенных корзин с 60% до 45% и вернуть к оформлению заказа не менее 12% пользователей в срок до 31.03.2026. Цель считается достигнутой при одновременном выполнении обоих показателей по итогам отчетного периода;
Условия: добавлен товар в корзину, есть email и согласие, заказ не оформлен в течение суток и пользователь ушёл с сайта;
Цель: снизить долю брошенных корзин с 60% до 45% и вернуть к оформлению заказа не менее 12% пользователей в срок до 31.03.2026. Цель считается достигнутой при одновременном выполнении обоих показателей по итогам отчетного периода;
Условия: добавлен товар в корзину, есть email и согласие, заказ не оформлен в течение суток и пользователь ушёл с сайта;
Момент отправки: письмо № 1 — через 30 минут, письмо № 2 — через 24 часа, письмо № 3 — через 72 часа (опционально), с оговоркой по дням недели;
Содержание: первое письмо — мягкое напоминание и выгодное завершение заказа, второе — усиление мотивации (отзывы, выгоды), третье — ограниченное по сроку предложение со скидкой;
Динамика: имя, список товаров, рекомендации «с этим берут», персональный промокод и дата его окончания;
Ограничения: если заказ оформлен на любом шаге, все последующие письма сценария не отправляются.
Такой пример помогает разработчику прокрутить сценарий в голове и сверить реализацию с ожидаемым поведением на каждом шаге.
Содержание: первое письмо — мягкое напоминание и выгодное завершение заказа, второе — усиление мотивации (отзывы, выгоды), третье — ограниченное по сроку предложение со скидкой;
Динамика: имя, список товаров, рекомендации «с этим берут», персональный промокод и дата его окончания;
Ограничения: если заказ оформлен на любом шаге, все последующие письма сценария не отправляются.
Такой пример помогает разработчику прокрутить сценарий в голове и сверить реализацию с ожидаемым поведением на каждом шаге.
Завершение: передача, сопровождение, тестирование и оптимизация
После того как вы собрали все разделы, у вас на руках не просто описание идей, а рабочий документ, по которому можно планировать сроки, оценивать трудозатраты и запускать разработку.
Дальше начинается этап сопровождения:
Обсуждение ТЗ с разработчиком/интегратором, уточнение неочевидных кейсов, корректировка разделов, если какие‑то вещи технически невыполнимы или чрезмерно сложны;
Пошаговое тестирование: прогон сценария на тестовых данных, проверки разных последовательностей действий, имитация одновременных триггеров, проверка корректности подстановки переменных и работы отписок;
Запуск в ограниченный сегмент (если возможно) и наблюдение за метриками: открытия, клики, конверсии, отписки, жалобы, влияние на ключевые показатели (доля повторных заказов, выручка, LTV).
Лучшие практики сходятся в одном: работа с триггерными сценариями — это не «один раз настроил и забыл», а непрерывный цикл итераций и экспериментов. Хорошее Т З делает этот цикл управляемым: вы всегда понимаете, что именно реализовано, какими данными сценарий пользуется и какие изменения нужно внести, чтобы следующий запуск был ещё эффективнее.
📩 Подписывайтесь на нашу рассылку — будете первыми получать полезные кейсы, лайфхаки и обновления.
📲 Также заходите к нам в ВК и становитесь подписчиками Школы Марии Агеевой ProEmail
Оставьте реакцию на статью!
Лидеры просмотров
Будьте в курсе новостей email-маркетинга ― подписывайтесь на рассылку Agebrand
Узнавайте о новых статьях и советах первыми!
ПОДПИСЫВАЙТЕСЬ ПРЯМО СЕЙЧАС