Transactional email is simultaneously one of the most critical and mots overlooked elements of a web application. It can easily be mis-configured. Constructing emails is one of the most tedious and un-evolved tasks a developer can perform. And despite using email almost every day, most delivers have only a very cursory understanding of how it all works.
With that in mind, we were constantly working on making useful and approachable educational materials for customers and wrote extensively about the nuances of sending—and successfully delivering—email for web applications. These are the articles I wrote while working to help developers better understand and make the most of the email infrastructure in their applications.
If you use Gmail, you may have noticed small buttons on the right side of previews in your inbox. These are called “Actions” or “Inbox Actions,” and they’re based on open standards from schema.org. Despite being based on open standards, Gmail is currently the only provider with widespread adoption, but given Gmail’s rather large market share, there’s a good chance Inbox Actions could improve the experience for a meaningful portion of your userbase.
Transactional emails are one of the key touchpoints for anyone using your products or services. Welcome emails provide an opportunity to make a good first impression; digests and notification emails can help folks stay on top of their work; order confirmation and delivery update messages give customers peace of mind.
Not all email service providers (ESPs) are created equal. Like with any other product or service, there are huge differences—primarily in the quality of delivery, troubleshooting capabilities, APIs, and customer support. This list can help you evaluate and make informed decisions about the best provider for your needs.
Password reset emails are one of the most common kinds of email. It’s almost impossible to build a software application without an email notification for a forgotten password. In a way, this is exactly what makes the design and content of a reset password email tricky. They’re so common that they’re easy to take for granted, but there are subtle details that affect whether your password reset emails are convenient and useful or whether they cause confusion.
In many cases, you may want to send emails on behalf of your customers. For instance, if you run help desk software but want to use Postmark to power your emails, you can set up all of the necessary authentication for your domain, vendordomain.com, but your customers would most likely rather their customers see their brand, customerdomain.com, instead of yours.
Chances are pretty good that if you run a software company, your software comes with some sort of trial period. How you structure the trial period may vary, but near the end of a trial period, you should follow up with an email or two to help folks avoid any interruptions in service if they’d like to continue using it.
If you run any kind of online business, you’re almost guaranteed to have email receipts and invoices. Any healthy business will need to process payments and send receipts for those payments. As ubiquitous as they are, they’re emails that are frequently overlooked in terms of value and customer experience. A well-designed receipt or invoice can make a great impression on your customers and even help generate additional revenue.
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.
Not every application will need user invitation emails, but they’re an important one to get right if you send them because they’re the first impression for many. Done poorly, recipients won’t trust this email and could very well report them as spam. Done well, however, they’ll help new users seamlessly join in and use your software. These are people who have been carefully selected by your other users to join in. It’s a key moment to make a great first impression.
When sending large amounts of transactional email, it’s inevitable that some will bounce. Maybe there was a typo in the email address, the receiving server could be down, the mailbox may have been deleted, or there could just be a transient error somewhere in the chain. Regardless of the cause, understanding the reasons can help you understand how to handle the bounce and provide the best experience for your users.
Email communication is an integral part of the user experience for nearly every web application that requires a login. It’s also one of the first interactions the user has after signing up. Yet too often both the content and context of these emails is treated as an afterthought (at best), with the critical parts that users see first—sender name and email, subject, and preheader—largely overlooked.
If you’re sending transactional email for your application, you’ve probably got the basics down, but you may be missing out on some of the more advanced best practices without even knowing it. This guide will help you make sure that you haven’t overlooked anything and aren’t unwittingly doing something wrong that could be hurting your delivery or user experience for your recipients.