Лучшие практики для писем-уведомлений о комментариях

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

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

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

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

1. Уведомить получателя и чётко предоставить релевантную информацию

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

2. Дать возможность легко ответить на уведомление при необходимости

Как только человек получает уведомление, велика вероятность, что он захочет проигнорировать, подтвердить или ответить на него. Поэтому следующая по важности задача — сделать процесс ответа максимально простым для получателя. Большинство ESP (сервисов рассылки) поддерживают обработку и парсинг входящих писем, и это можно реализовать без создания сложного инструмента.

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

Повторное использование элементов других писем

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

Использование письма как тизера и принуждение к переходу по ссылке для просмотра полного содержания

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

Отсутствие вариантов взаимодействия с контентом, кроме «Просмотреть детали»

В дополнение к включению полного содержимого письма, у получателя обычно есть несколько других действий, которые он может совершить. Письма-уведомления нуждаются не только в кнопке «Просмотреть это». (Эта кнопка, конечно, всё равно нужна.) Может ли получатель ответить? Нужно ли ему подтвердить что-то?
При этом варианты «Просмотреть детали» или «Прочитать онлайн» должны быть доступны и находиться в верхней части письма. Если письмо некорректно отображается или его трудно читать в почтовом клиенте, а кнопка для просмотра контента скрыта или находится ниже на странице, получателю будет гораздо сложнее ознакомиться с содержимым. Сделайте письмо простым и всегда предоставляйте чётко заметную кнопку или ссылку для действия в верхней части письма.

Сложности с изменением настроек уведомлений или объединением уведомлений в пачки

Уведомления могут быть, мягко говоря, чрезмерными. Транзакционные письма не обязаны по закону содержать опцию отписки, но это не значит, что нельзя упростить для получателя возможность изменять частоту уведомлений. Это отличный способ показать пользователям, что вы цените их время и внимание.
Один из самых удобных для пользователя способов уменьшить количество уведомлений — не отправлять их мгновенно, а объединять несколько уведомлений в одно письмо, отправляемое несколько раз в час. Основная причина, по которой приложения этого не делают, — необходимость значительных инженерных изменений в подходе к отправке писем. Легко отправить отдельное письмо на каждое событие, но немного сложнее создать фоновый процесс, который проверяет релевантные уведомления, собирает их вместе и отправляет как список событий в одном письме.
Другая проблема при отправке объединённых уведомлений — то, что включение полного содержания дюжины уведомлений в одно письмо может быть перегружено для получателя. Поэтому при объединении уведомлений лучше отправлять краткие сводки. Пока контроль над настройками доставки находится в руках пользователей, это вполне приемлемо. Они могут сами решать, хотят ли получать полные уведомления о каждом событии сразу или регулярные сводки раз в час.

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

Приём ответов на уведомления и их автоматическая корректная обработка в приложении требует немалых усилий в разработке, но в наши дни эти усилия достаточно невелики, чтобы оправдать инвестиции. Рассматривать письма-уведомления как односторонний канал связи разрушает естественный и удобный для пользователя способ взаимодействия. Люди очень привыкли отвечать на письма, и даже если приложение не поддерживает такую функцию, некоторые пользователи будут постоянно пытаться ответить на уведомления.
В большинстве случаев достаточно использовать адрес поддержки в поле reply-to.

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

Имя отправителя

В случаях, когда ваше приложение не отправляет письма с адресов пользователей, можно сделать более ясным, кто именно инициировал уведомление, используя его имя в поле «От» для адреса отправителя. Поскольку это одна из первых данных, которые видит получатель, это особенно важно. Однако нужно делать это правильно, иначе это может вызвать путаницу в адресных книгах получателей.
Например, вместо того чтобы использовать только адрес электронной почты, как «notifications@example.com», или название приложения с адресом «Example notifications@example.com», можно вставить имя человека, вызвавшего уведомление. Тогда можно использовать «Юрий notifications@example.com».
Но здесь есть нюанс. Некоторые почтовые клиенты автоматически добавляют адреса в адресную книгу, если пользователь отвечает на письмо. В этом случае «Юрий» может быть неправильно добавлен в адресную книгу получателя с адресом «notifications@example.com». В будущем, когда получатель захочет написать Юрию по другому поводу, автоподстановка вставит «notifications@example.com» как его адрес, и Юрий это письмо не получит. Это создаёт риск пропущенной корреспонденции.
Лучшее решение для смягчения этой проблемы — добавить дополнительную информацию к имени отправителя, чтобы уточнить, что настоящее письмо отправлено вашим приложением. Можно использовать варианты «Юрий из HaskiMail notifications@example.com», чтобы прояснить связь. Главное помнить: чем меньше дополнительных символов, тем лучше.

Кто ещё был уведомлён?

Ещё один распространённый вопрос, который возникает у людей при получении уведомления: «Кто ещё это видел?» Они могут задумываться, нужно ли им передавать это дальше или, скорее всего, кто-то другой займётся этим. Это не обязательно должно быть в центре внимания, но небольшая строка с информацией о том, кто получил уведомление, может быть полезной. В зависимости от того, как отправляются ваши уведомления, получатели теоретически могут посмотреть поля «Кому» или «Копия», но это немного менее удобно.

Информация о возможности отвечать на письма

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

Информация об «Инициаторе» или «Триггере»

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

Абсолютная временная отметка (в отличие от относительной)

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

Метаданные и контекст

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

Основное содержимое

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

Ссылки для просмотра содержимого в контексте

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

Прямые ссылки для выполнения распространённых связанных действий

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

Ссылка для управления настройками уведомлений

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