Руководство для PM: с чего начать работу над e-mail рассылками для сайта заказчика

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

Когда-то я тоже была начинающим руководителем проекта, и мне пришлось разобраться с письмами с нуля. Поделюсь здесь рекомендациями по организации процесса. Про то, как собрать письмо на конструкторе, писать не буду – об этом у каждого конструктора есть свои инструкции. А как сделать письмо эффективным для бизнеса, разбираются e-mail-маркетологи.

Будет здорово, если эта статья поможет хотя бы одному начинающему РМ. Ну или опытному, но не работавшему раньше с письмами.

Картинки по делу особо не нашла, так что будут просто разные картинки на тему писем 🙂

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

Это важная классификация, которая поможет вам точно формулировать задачи, связанные с письмами. Если вы различаете виды писем, то знаете, что на каком этапе предложить заказчику.

Транзакционные – письма, которые автоматически приходят в ответ на взаимодействие (транзакцию) пользователя с сайтом и которые необходимы для того, чтобы он мог полноценно пользоваться сервисом, а также для соблюдения требований закона.

Примеры:

Такие письма нужны для интернет-магазинов, сайтов с бронированием услуг, для многих сайтов с регистрацией и авторизацией, личным кабинетом. В некоторых случаях вместо писем могут быть смс и пуши. Если у заказчика нет определенных пожеланий (регистрация и покупки на сайте будут, но заказчик не знает, нужны ему письма или лучше выбрать другой канал уведомлений), нужно рассмотреть 2 следующие категории писем (триггерные, маркетинговые). Если они нужны заказчику – то и транзакционные письма тоже с большой вероятностью нужны. И нужны они сразу, прямо при запуске MVP, если в него входит регистрация и интерактивный функционал для авторизованных пользователей. Даже если таких пользователей на сайте 10 человек.

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

Триггерные – письма, которые автоматически приходят в ответ на взаимодействие (транзакцию) пользователя с сайтом, но они НЕ необходимы, а применяются для вовлечения пользователя во взаимодействие с сайтом, повышения метрик, проще говоря – рекламные.

Примеры, связанные с активными действиями пользователя:

Примеры, связанные с пользовательскими данными и наступлением дат:

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

Эти письма могут приходить пользователю каждый раз, когда у него наступило определенное действие или событие, но чтобы не заваливать пользователя письмами, можно настроить ограничения («не чаще чем раз в…», «при повторении 3 событий за такой-то период высылать 1 письмо…»). Такие ограничения указывает заказчик (его менеджер или маркетолог). Менеджеру обычно не приходится в этом разбираться, достаточно просто быть в курсе, чтобы вовремя задать правильные вопросы или поддержать коммуникацию, если на стороне клиента появится отдельный специалист или сторонний подрядчик по письмам и прочим маркетинговым коммуникациям.

Маркетинговые – те письма, которые привычно называть «рассылками». Их отправляют по отдельным сегментам базы пользователей независимо от поведения пользователей на сайте в данный момент.

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

Пример:

Чтобы рассылать такие письма по базе подписчиков, надо эту базу собрать. Еще надо различать, что пользователь не обязательно равен подписчику, он мог не дать своего согласия на получение маркетинговых рассылок. А отправлять без согласия – нехорошо (нарушение закона). Если недостаточно этических причин, то добавим, что пользователь может легко пожаловаться на ваши письма, рейтинг доверия к вашему домену снизится и ваши письма перестанут нормально доходить и до других пользователей. Информация об этом гуглится, но она несколько противоречива из-за того, что почтовые сервисы не раскрывают до конца свои механизмы фильтрации спама. На старте проекта, пока нет базы подписчиков, делать такие рассылки не придется, а дальше, скорее всего, ими займется отдельный специалист, но, опять же, менеджер должен быть как минимум в курсе возможностей и последствий.

Выводы для РМ:

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

2) обсудите с клиентом, хочет ли он в будущем заниматься e-mail маркетингом, слать триггерные и маркетинговые письма;

В зависимости от этого определитесь с инструментами для подготовки писем (о них дальше, после глупой картинки).

Определяется целями внедрения писем на проекте, требованиями к их виду и ресурсами заказчика. Это важно. Рассылочные сервисы умеют многое, в них встроены конструкторы, но:

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

Когда появляются маркетинговые письма, на них составляется отдельный план. Это уже работа маркетолога. Они умеют составлять огромные разветвленные планы с цепочками писем. А предыдущие пункты вполне может взять на себя студия/агентство заказной разработки: даже если вы не занимаетесь e-mail маркетингом, РМ может самостоятельно или с помощью выбранного ответственного лица собирать в таблички всю информацию о письмах. В моем опыте этим занимались аналитики и специалисты по поддержке пользователей.

Вы наверняка встречали надпись: «Данное письмо сгенерировано автоматически… Напишите нам на другой адрес». Разные почты заводятся для удобства обработки, но если почта support теоретически еще может быть на отдельном домене, то почта, с которой вы будете рассылать письма (а не принимать обращения) от лица сайта, должна соответствовать требованиям:

Предположим, что у вас уже есть почта, а письмо вам нужно создать с нуля.

0. Цель письма. Для транзакционных писем – РМ и команда разработки может сформулировать цель и объяснить клиенту. Для триггерных и маркетинговых – это задача на стороне клиента. Тогда РМ должен просто понять цель письма и его место в плане рассылок.

Вот какие моменты для каждого письма РМ должны иметь в виду и проконтролировать:

1. Контент

2. Дизайн

3. Верстка

4. Настройка триггеров на бэке

5. Тема и заголовок письма

6. Разметка (события для веб-аналитики)

7. Прикрепленные файлы (если нужны)

Самые чувствительные моменты в этом списке – дизайн и верстка, о них расскажем отдельно.

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

1. Разрешения: Письма рисуются с учетом двух основных разрешений - мобильного (обычно 320px-480px) и десктопного (обычно 600px-800px), чтобы обеспечить корректное отображение содержимого на различных устройствах.

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

3. Интерактивные состояния: В электронных письмах не поддерживаются интерактивные состояния, такие как ховеры на ссылках или состояния кнопок при нажатии.

4. Шрифты: Рекомендуется использовать стандартные веб-шрифты, такие как Arial, Helvetica, Times New Roman, Georgia, Courier New и Verdana. Эти шрифты широко поддерживаются в различных почтовых клиентах и обеспечивают более надежное отображение текста на различных устройствах и платформах.

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

Примером может служить Outlook, где некоторые свойства CSS, такие как background-image, border-radius и float, не поддерживаются. Это ограничение может привести к тому, что письма в Outlook не будут выглядеть так привлекательно, как хотелось бы. Однако, даже при таких ограничениях можно добиться более приемлемого внешнего вида писем. Для этого следует прибегнуть к использованию более простых стилей. Рекомендуется избегать использования вышеописанных свойств в письмах, поскольку они могут отображаться некорректно. Поэтому важно, как можно тщательнее тестировать письма, в различных почтовых клиентах и браузерах.

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

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

Информации о письмах в интернете много, но это не математика, тут нет терминов. Я не претендую на исчерпывающие знания и идеальные формулировки и буду рада, если вы поправите/дополните меня в контексте этой темы.