Editorâs note: This guide builds on the tips from our transactional email guide that covers both content and technical best practices that apply to all of your transactional emails. Itâs a great primer for transactional email in general and will help make sure you get the most value from this guide too.
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

Managing email templates is a breeze with our Templates API
Choose from our range of responsive, well-tested, email templates or code your own.
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.