Comment notification email best practices

It’s very likely that update notifications will be one of your most frequently sent emails, and that means it’s one of the interactions that deserves an extra batch of attention and care. On the surface, these notifications feel like they’re just about letting people know something happened, but they can be much more useful and powerful if you’re careful how they’re designed and implemented.

Comments, actions, alerts, etc. #

We’re using “update notification” to encompass things like comments, actions, updates, alerts, or just general events that happen within software. Each of these types of events will have subtle differences with how the information is presented, but the surrounding content of the email like headers, footers, and metadata will be very similar.

For example, with each of these types of emails, the chances are good your recipients will be interacting with these types of emails frequently. These could be the most frequent communication you send. More than any other notification they should be simple, practical, and efficient. That means you should include minimal decoration and branding so they can focus on the content and the resulting tasks for the recipient. Skip the header and logo. Simplify the footer. Where relevant, make sure the recipient can reply directly to the email.

What are the goals of an update notification email? #

Notifications can be incredibly simple emails, and the over-arching goals seem obvious on the surface. However, sometimes once these notifications are designed they lose focus.

1. Notify the person and clearly provide relevant information #

With any of these types of notifications, the absolute most important priority is to clearly present the content of the notification. Many products obscure the important information with redundant and unnecessary things like logos, banners, and unnecessary legal disclaimers in the footer. The goal is to give the recipient as much actionable information as possible in the subject, and then present as much content as possible alongside as many actions as possible inside the email.

2. Let them easily respond to the notification if necessary #

Once people are notified, the chances are pretty good that they want to ignore, acknowledge or reply to the notification. So the next most important thing is making it effortless on their part to respond accordingly. Most ESP’s provide support for processing and parsing inbound emails, and this can be built without having to create a complex tool.

What are some common mistakes with update notification emails? #

There’s plenty of ways to get notification emails wrong and get in the way of the content the recipient wants, but knowing these pitfalls is half the battle. While none of these are written in stone, they’re all important considerations that can negatively affect your notification emails.

Reusing shared components of other emails #

One of the most common mistakes with notification emails is including the large logos, headers, and informational footers from other notifications. For instance, your comment notification emails don’t need a copyright notice or links to Twitter and Facebook. They don’t need a company logo or an oversized header plastered across the top of the email pushing the only content that the recipient cares about deeper down into the email. Notifications deserve their own custom elements to minimize the noise and enable the content to stand out instead of competing with unnecessary elements.

Treating the email as a teaser and forcing people to clickthrough for the full story #

In some cases, it’s impractical to include the full content of a notification in the email, but those cases are few and far between. In general, you should strive to include all of the content directly in the email, so the recipient isn’t forced to click through to view the page. Unless that content absolutely has to be secured, forcing people to click through isn't user-friendly.

If the recipient has to follow a link, they may be on a mobile connection and have to wait for a large page to download. They could also have to log in which isn’t always easy or practical on a mobile device. Whereas, if they can read the full notification inline in their email, they can make their own decision about whether it’s worth going to the site. This approach assumes you’ve optimized your emails for mobile so that they’re easy to read.

Failing to provide options beyond “view the details” for interacting with the content #

As an extension of including the full content in the email, there’s generally quite a few other actions that a recipient can take. Notification emails need more than a “View this” button. (They still need that button, of course.) Can they reply? Do they need to acknowledge something?

That said, the “view the details” or “read this online” options need to be available and at the top. If the email is broken or hard to read in a client and the button to view the content is hidden or lower on the page, it’s much more difficult for the recipient to view the content. Keep it simple, and always provide a clearly actionable button or link at the top of the email.

Making it difficult for people to adjust their notification preferences or batch-related notifications #

Notifications can be overly chatty, to say the least. Transactional emails aren’t legally required to have an unsubscribe option, but that doesn’t mean you shouldn't make it as easy as possible for the recipient to make changes to the frequency of the notifications. It’s a great way to show users that you value and respect their time and attention.

One of the most user-friendly ways to reduce the number of notifications is to avoid sending notifications immediately and batch notifications as a single email several times each hour. One of the primary reasons applications don’t do this is that requires a significant engineering change to their approach for sending emails. It’s trivial to fire off another email with every event, but it’s a bit more complex to create a background process to check for relevant notifications, pull them together, and then send them as a list of events in one email.

The other problem with sending batched notifications is that including the full content of a dozen notifications in a single email can be overwhelming. So with batches, you’d need to send summaries instead. As long as control over the delivery options is your users’ hands, this is alright. They can decide whether they’d like full notifications of every event immediately or a regular summary hourly,

Not allowing replies/interaction via email where relevant #

Accepting replies to notifications and automatically and correctly processing them into an application does require non-trivial development effort, but that effort is low enough these days it’s easy to justify the investment. Treating notification emails as a one-way communication stream breaks an incredibly natural and user-friendly interaction. People are very comfortable replying to emails, so much so that even if an application doesn’t support the feature, some users will consistently try to reply to notification emails.

In most cases, using a support email address in the reply-to is enough, but with content or action notifications, forcing users to log in and use a web interface can be downright user-hostile. Most good email service providers will have built-in functionality for handling inbound emails, and some even automatically parse the content of the email to provide a great API for accessing attachments, the stripped reply, and all of the key metadata in the headers. For instance, Postmark makes this incredibly easy with a dedicated inbound email processing web hook that even provides a configurable SpamAssassin spam filter. Given the relative ease of adding this and the high value to users, there are very few reasons to justify not implementing it these days.

What info should be in every update notification email? #

Our concept of update notifications encompasses a wide variety of use cases from alerts to comments. While each of these has their own subtle differences, they share a large set of information that should always be included.

Sender Name #

In cases where your application doesn’t send email from your users’ addresses, it can make it clearer who the actor is by using their name in the from name for the sending address. And since this is one of the first pieces of data a recipient will see, it’s especially important. However, it must be done right, or it could create confusion with recipients’ address books. For example, instead of using just the email address, like ‘notifications@example.com’ or the application name and email address ‘Example <notifications@example.com>’ you can insert the name of the person who caused the notification. So you could use ‘Jane Doe <notifications@example.com>’ instead.

But this is where it can get tricky. Some email clients are configured to automatically add email addresses to address books if the user replies to an email. So, in this case, ‘Jane Doe’ would incorrectly be added to the recipient’s address book with ‘notifications@example.com’ as the email address. Now, when the recipient goes to email Jane about something else down the road, auto-suggest would end up inserting ‘notifications@example.com’ for her email address, and Jane wouldn’t receive this message. That creates a lot of potential for missed communications.

The best solution to mitigate this problem is adding some sort of additional information to the sender name to clarify that your application is the real sender. You could use ‘Jane Doe via ExampleApp <notifications@example.com>’ or ‘Jane Doe (ExampleApp) <notifications@example.com>’ to clarify the relationship. Just remember, the fewer additional characters you use the better.

Who else was notified? #

Another common question when folks receive a notification is "Who else has seen this?" They might wonder if they need to pass it along or if it's likely that somebody else will be taking care of it. It doesn't need to be front-and-center, but including a small line that lets people know who was notified can be handy. Depending on how your notifications are sent, recipients could theoretically look at the To or CC fields, but that's a little less convenient.

Information about accepting replies #

If your application can accept email replies, and it should, then you’ll want a way to let people know. Moreover, if it’s more advanced and accepts and handles advanced commands via email, that can be just as useful. This can take a few forms, but the best way is to include a small note at the end of the email or in the footer along the lines of “You can reply directly to this email.” Alternatively, if your system handles advanced commands, you could link to a reference document that details and explains all of the available commands. This may seem small, but it’s the kind of improvement that can dramatically increase usage of a feature, and, by extension, customer happiness.

“Actor” or “Trigger” information #

Who or what caused this notification to be sent? If it’s something like a comment, this will be another user in the system. If it's an alert or something that’s sent in response to an event, then provide the details of the event that triggered it. Hopefully, you’ve already communicated this via the name of the sender, but it’s also good to repeat it within the email so that the context is visually near the content.

Absolute Timestamp (as opposed to relative) #

Even though the timestamp is somewhat implicit through the email’s timestamp, it’s helpful for an accurate timestamp to be easily visible in the body of the email so the recipient can determine if the possibility of the content is outdated. Just like having the name nearby is helpful, having the timestamp in close proximity saves the reader from having to jump around to check the timestamp. Moreover, if an email was delayed for any reason, the email timestamp will not accurately reflect when the original action occurred.

Metadata and context #

Dates are a key part of metadata, but there’s often much more metadata that can help provide context. Often times, that could be the comment or event immediately preceding the primary comment in the notification. For example, if you’re updating an issue in an issue tracker, you may want to include information about state changes like status, assignee, or category. Alternatively, in an invoicing application, you may want to include data about the status of an invoice in addition to the content of the invoice. Metadata about the content or update can be just as helpful as the primary content itself.

Primary content #

It should probably go without saying, but including the details of the event or action that triggered the notification is what this is all about. When possible, it’s best to include the full contents of the event so that the recipient doesn’t have to follow a link, log in, and wait for a web page to load in order to read it. If it’s a comment on a thread, it’s best to include the full content of the comment and any included attachments directly in the email. It’s not always practical to include the attachments in the email, so including a direct link to the attachments is the next best thing.

Links to view the content in context #

Even if the full content is included in the email, recipients will frequently need to see the content in the full context of your application. That includes related comments, all of the convenient links to follow, edit, or make their own updates. Or maybe they just don’t like reading long-form things the way that your emails format them. There are dozens of reasons people may want to view the full content in context. Don’t bury the link or make it difficult for people to skip the email and go straight to the content. Make it convenient and readily accessible without a bunch of scrolling, and if you’re deep-linking to content on a page, make sure to use anchor tags and take the reader directly to the content related to the notification.

Direct links to take common related actions #

While notifying someone about content is the primary goal, the content may frequently lead to common next steps or actions for the recipient. Where possible, and without overwhelming the email with infrequently used options, make sure to include simple links for any of the key actions someone may take. For example, if someone can unfollow a thread, you might want to include a link to let them do that directly from the email.

Link to manage notification preferences #

An extension of unfollowing a thread is the larger action of managing notification preferences. Depending on how your notifications work, you’ll probably have some additional controls to help your users fine-tune the details around which notifications they receive and how frequently they’re sent. There’s no better place to expose this than the most frequent notifications they receive. Simply provide a direct link to the best location for people to manage their notification preferences. Even though you aren’t required to have unsubscribe links in transactional emails, it’s still a good practice to give recipients some level of convenient control of their notifications.

The checklist #

And here's a quick summary checklist to help remind you of the individual points once you start designing and building your template.

• Sender name
• Who else was notified?
• Explain if they can safely reply to the notification
• "Actor" or "Trigger" information
• An absolute timestamp (as opposed to relative)
• Meta data and context
• Primary content
• Link to view the content in context
• Direct links to take common related actions
• A link to manage notification preferences

Postmark's comment notification template #

Even a relatively simple transactional email like a comment notification can take time to create from scratch. To help you save that time we've created a comment notification template based on all the best practices you've read about in this guide.

You can use this template with any email service provider, not just Postmark. You'll get the HTML template you see here and a nicely formatted plain text equivalent. You can grab this comment notification template and learn more about the rest of our template collection in their Github repository.

If you like Postmark's templates you should check out MailMason. It's a tool we've built to streamline every aspect of creating and maintaining your transactional email messages. Every Postmark template is included out of the box with MailMason. On top of those templates MailMason gives you the power of a Grunt-based email design workflow and makes it simple to maintain all of your transactional emails. You can use Mustachio to tightly integrate with Postmark's template engine, or adapt MailMason to your workflow for another email service provider. Like our templates, MailMason is 100% open-source.

We want to help you send incredible transactional email messages, even if you choose to use a different email service provider. If you have any thoughts on how we can improve MailMason, we'd love for you to share them in the MailMason repository on Github.

---

Read all of our transactional email best practice guides #

We've assembled a series of guides on best practices for multiple types of transactional email.

• Transactional email best practices
• Welcome email best practices
• Password reset email best practices
• Receipt and invoice best practices
• User invitation best practices
• Trial expiration email best practices