Jun 7, 2023
Overview
As part of product research for Waypoint, we talked to many software developers across different stages of companies to get a better understanding on how they send email notifications from software in 2023. In this article, we explore the different ways software teams send transactional emails and what we believe has been missing.
A transactional email, is simply an email message that is sent to a single person as a result of an action within your application. Think an invite, order confirmation, payment reminder, receipt, alert, or any other product-triggered system notification. The important piece to note here is that these kind of emails differ from marketing emails since these are 1:1 instead of 1:many email campaigns. See Waypoint's gallery of transactional email examples.
Transactional email examples.
Why transactional emails are important
Transactional emails are a key to a great user experience on products and are often seen as the ‘glue of UX’ for platforms as they do the wonderful job of keeping your users informed even when they are not actively on your platform.
As this Indie Hacker article explains, transactional emails are underrated opportunities and can be used as a tool for increasing revenue, gathering feedback, re-activating users, improving retention/followers, and boosting brand recognition.
Transactional email challenges
Before digging into the options for sending these emails, let’s get a better understanding for what kind of challenges software teams run into with transactional emails and why emails can be difficult to integrate into your platform. These challenges typically fall within the following buckets:
Deliverability – teams need to be able to easily deliver emails reliably at scale and ensure that they land in inboxes instead of spam folders.
Monitoring - teams need to be able to monitor emails to ensure deliverability and debug when needed.
Templates – teams need to be able to create, maintain, and test HTML email templates across many clients and devices.
Collaboration – teams need to be able to do all of the above without having developers become the bottleneck.
Options for sending transactional emails
Option 1: SMTP server
SMTP (Simple Mail Transfer Protocol) is the open and free email protocol for sending and receiving emails on the internet.
Sending emails through SMTP from your software is the exact same way your email clients are sending emails. This can be done through your own SMTP server or through your email provider’s server like Gmail (video tutorial).
From a developer perspective, tools like Nodemailer (Node.js) and Action Mailer (Rails) can be used.
While this is a free and open option, teams are limited by the usage limits set by the SMTP server. Additionally, this approach lacks sufficient tools to prevent landing in spam, insights and reporting, and collaboration.
This means most serious software teams, won’t even consider this as an option as they don’t address any of the challenges above.
Option 2: SMTP + SMTP relay (email service provider)
By using an SMTP relay, teams are solving for challenge #1 (deliverability) and #2 (monitoring).
SMTP relays are a software service provided by tools like Amazon SES, SendGrid, or Mailgun. These services will route your outgoing emails to a reliable server. This approach ensures high deliverability rates when sending high volume emails and provides monitoring services that help your team with insights and logs all the way down to the individual email email (eg. when it was sent, when it was delivered, opens, clicks, etc).
Example of monitoring on SendGrid
Again, from a code perspective, tools like Nodemailer and Action Mailer are still commonly used with the SMTP information simply set to the relay server.
The downside to this approach is that developers are still the bottleneck for creating and maintaining emails. This results in endless amount of back-and-forths between your product and engineering teams – or more typically, emails being hastily created once and then never touched again.
Additionally, if teams are sending branded HTML emails, creating email templates by hand is very time consuming and can feel like writing HTML in the 90's. Although, email coding frameworks like MJML can help with this.
Option 3: Email API + dynamic templates
Email APIs that support dynamic templates are the holy grail and solve for all of challenges above: deliverability, monitoring, templates, and collaboration. Platforms such as Waypoint, SendGrid, Mandrill (MailChimp), Brevo, and Postmark are great options to consider for this option.
Not only are emails configured through a simple REST API making it easier to integrate, data can now be passed as part of the API call to dynamic templates for collaboration purposes. This means designers can build templates using a visual builder, developers can simply focus on sending data and triggering templates, and product managers and monitor deliverability and logs.
Additionally, visual builders are designed with cross device/client rendering in mind. This means messy template code is no longer needed in codebases. For example, SendGrid's dynamic templates help decouple templates from your codebase. Outside of the inherit collaboration wins, the big benefit here is that dynamic templates can be updated on the fly without code changes, pull requests, and deploys (less developer bottlenecks).
Example of a dynamic template builder on SendGrid
Can it get better?
Of course software can always get better. People said online payments was solved when Authorize.net was the API of choice – and then Stripe, Finix, and others came along after to show us what’s possible.
We found that while other email API services have made great strides over the years, developers and software teams were still running into frustrations – mainly due to the fact that other tools are effectively repurposed marketing email builder tools designed for little to no dynamic data. This led us to building Waypoint.
Here are some of the key ways we are already improving the email platform experience for software teams:
Improved monitoring
Often teams need the full context of an email to properly debug or log for auditing purposes.
On Waypoint, we show a full log of all of the events as well as the full HTML and template data for each email sent through Waypoint.
Example of monitoring on Waypoint
As well as a full API request logs to help pinpoint any issues:
Example of API request monitoring on Waypoint
Improved dynamic templates for data-rich emails
We designed Waypoint’s template builder to be strictly focused on working with data-rich emails. This allows your team to work with test data that works seamlessly with Liquid templating and GitHub Flavored Markdown.
Example of a dynamic template builder on Waypoint
Liquid templating allows your team to take advantage of conditional tags or filters. For example, using a filter for formatting date strings:
Example of Liquid templating Waypoint
We also provide the ability to set different test data scenarios to properly test different data situations and conditionals within your template. As well as preventing delivery if data is empty (no more broken emails going out!):
Example of test scenarios on Waypoint
Improved automation
While still in the early releases, Waypoint workflows helps software teams move template orchestration logic from their codebase to a visual workflow builder.
For example, setting a delay on a template via a workflow:
Example of a workflow builder on Waypoint
Final thoughts
Luckily for software teams, there are now great options that make sending emails within software easier than ever.
With Waypoint, we've built a new email platform and API with unique approaches to helping teams divide and conquer the workload. Designers can build email templates visually, developers can focus on sending the right data with debugging tools, and product managers can orchestrate and monitor deliverability. Everyone can now focus on what they do best.
If you are part of a software team and want to collaborate around sending transactional email, we encourage you to give Waypoint a try!