Blogroll: Postmark

I read blogs, as well as write one. The 'blogroll' on this site reproduces some posts from some of the people I enjoy reading. There are currently 7 posts from the blog 'Postmark.'

Disclaimer: Reproducing an article here need not necessarily imply agreement or endorsement!

Subscribe to Postmark feed
Updated: 3 hours 10 min ago

Managing your Postmark templates with Github using Travis CI or CircleCI

Thu, 27/06/2019 - 17:16

Postmark’s templating system comes with a web editor to manage your email templates, but sometimes it's more convenient to use your own code editor while also storing your templates in version control. Our CLI tool makes this all possible.

This guide walks you through how to store your Postmark templates in Github and use Travis CI or CircleCI to automatically push them to Postmark.

If you’re not familiar with continuous integration (CI) and continuous delivery (CD), no need to worry. In a nutshell, these tools let developers run automated processes against their code and deploy it somewhere. A common scenario is for developers to run automated tests each time they push their code to Github. If the tests fail for whatever reason, the CI/CD tool notifies the developer so they can fix the issue. And if the tests pass, their code gets deployed to their server.

Flow chart illustrating basic CI/CD workflow. Code → Github → CI/CD → Did tests pass? [YES] → Deploy code [NO] → Notify developers Basic CI/CD workflow

This is a very basic example, but some workflows can get pretty complex depending on the application. Luckily, we’re here to help you get up and running with a simple workflow. Let’s jump into it!

Flow chart illustrating Postmark template workflow. Templates → Github → CI/CD → Postmark Postmark template workflow Setting up your Github repository

First, you’ll need to set up a Github repository for your templates. Feel free to skip these steps if your repository is already set up.

  1. Create a Github repository. Check out Github’s help doc for instructions.
  2. Clone the repository to your desktop. Check out Github’s help doc for instructions.
Pulling your templates from Postmark

Once your repository is set up, you need to pull your templates from Postmark to your local repository. But before you get started, make sure that node.js is installed.

1. Open up your terminal, and install the Postmark CLI tool:

npm i postmark-cli -g

2. Run the Postmark command to make sure it’s installed. If you see a help screen, then you’re good to go:


3. Navigate to your git repository and pull your templates:

cd ~/Projects/your-repo postmark templates pull ./emails

The pull command accepts the path of where you want to save your templates. In our example, we are putting the templates in ./emails, but feel free to pass in a different path if you’re integrating into an existing project.

The CLI tool will ask you for your server token to authenticate. You can find your server token on the credentials page under your Postmark server. Once authenticated, your Postmark templates will be downloaded to your local git repository.

4. Next, let’s push your templates up to Github:

git add . git commit -m "Initial commit of Postmark templates" git push Setting up CI/CD

We’ll need to set up a CI/CD tool to push the templates from your Github repository to Postmark. Travis CI is popular option for open source projects, whereas CircleCI is more suited for private projects. Both have their own pros and cons based on OS support, number of concurrent jobs, and language support, but either tool is sufficient for what we’re doing.

Setting up Travis CI

If you don’t already have a Travis CI account, sign up at and authorize your Github account.

Once you’re logged into the dashboard, head over to the Settings page. You can find it by hovering over your avatar in the navigation:

Find your Github repository and click the toggle to enable it:

Next, click on the Settings button next to the repository. Scroll down to the Environment Variables section and add a variable called POSTMARK_SERVER_TOKEN. Enter your Postmark server token as the value.

The Postmark CLI tool automatically detects this environment variable to authenticate server-level requests. Make sure to keep Display value in build log disabled so that your server token does not get exposed in the logs.

Next, head over to your code editor and add a file called .travis.yml to your project root and paste this config into the file:

language: node_js node_js: - "lts/*" script: true before_deploy: - npm i postmark-cli -g deploy: provider: script script: postmark templates push ./emails -f on: branch: master

This config provides Travis CI with instructions on how to handle the workflow. Let’s go over what it does:

  • language - Our CLI tool uses node.js, so we’re making sure it’s available
  • node_js - Define’s the node.js version. The latest LTS version of node.js will work just fine.
  • before_deploy - Installs the Postmark CLI dependency before the deployment process
  • deploy - Tells Travis CI how to handle the deployment
    • provider - Travis CI supports a long list of providers, but we just need a script for our deployment
    • script - Where the push command is executed
    • postmark templates push - This command accepts the relative path of the templates. We are also passing in the force (-f) flag. By default, this command will ask users to confirm the push, but since it's executed inside of a build container, user confirmation isn’t possible. The force flag simply disables the confirmation.
    • branch - Specifies that templates are only pushed to Postmark whenever a push is made to the master git branch.

Let’s commit the Travis CI config to the master branch in your github repository:

git add . git commit -m "Add Travis CI config" git push

Travis CI will automatically detect your push and run the deployment. Head over to the Travis CI dashboard and click on your repository:

This will take you to the logs where you can see what happened during the build. You can even use the logs to see which templates were pushed to Postmark. If everything was successful, you should see a Deploying application step containing the list of pushed templates:

If you want to get fancy, you can even send custom email notifications each time certain steps are executed. I find it useful to send an email notification each time my templates are pushed:

after_deploy: - postmark email raw --subject="[Travis CI] Templates pushed" --text="Templates have been pushed to Postmark - $TRAVIS_BUILD_WEB_URL"

This utilizes the after_deploy step which is part of Travis CI’s job lifecycle. This step executes the postmark email raw command and inserts the build URL into the --text argument so that you can easily view the logs in Travis CI. Don’t forget to update the From email (-f) to a valid Sender Signature or email address on a verified domain. And enter the email address of where you want to send the notifications in the -t argument.

You’re all ready to go! I recommend checking out Travis CI’s help docs for more info on how to customize your workflow.

Setting up CircleCI

If you don’t already have a CircleCI account, sign up at and authorize your Github account.

From your code editor, create a folder named .circleci in your project root. Then add a file named config.yml to that folder. Paste this starter config into the file contents:

version: 2 jobs: build: branches: only: master machine: true steps: - checkout - run: name: Install Postmark-cli command: | npm i postmark-cli -g - run: name: Push templates to Postmark command: | postmark templates push ./emails -f

This config provides CircleCI with instructions on how to handle the workflow. Let’s go over what it does:

  • version - Defines which config version to use
  • jobs - Lets you define specific tasks for a workflow. In our case, we’re only running the build job to push our templates. You can also execute multiple jobs as part of a workflow if your process is more complex.
  • branches - Only run the build process on the master branch
  • machine - Specify the type of environment to run the workflow on. We’ll use the default machine provided by CircleCI.
  • steps - List of steps to be performed in this job
    • checkout - Helper step provided by CircleCI used to checkout the source code so that the templates can be accessed
    • run - Step type that lets you name and execute scripts. In our case, we start off by installing the Postmark CLI as a global dependency using npm, and then follow up by pushing the templates to Postmark.
    • postmark templates push - This command accepts the relative path of the templates. We are also passing in the force (-f) flag. By default, this command will ask users to confirm the push, but since it's executed inside of a build container, user confirmation isn’t possible. The force flag simply disables the confirmation.

Next, let’s commit and push the CircleCI config to the master branch:

git add . git commit -m "Add CircleCI config" git push

Head back to CircleCI’s web app and click on the Add projects link in the navigation. Look for your repository and click on the Set Up Project button:

This will take you to a set up page with a bunch of boilerplate config options. Under the Language section, select Node:

Scroll down to the instructions section and click on the Start building button:

This will trigger a build, but it will fail since we haven’t added an environment variable for your server token yet.

Head over to the Settings page, then select the Projects from the sub navigation. Find your project and click on the little cog icon:

Click on Environment variables from the sub navigation and add a variable named POSTMARK_SERVER_TOKEN. Enter your Postmark server token as the value:

The Postmark CLI tool automatically detects this environment variable to authenticate server-level requests.

Next, we will trigger a build to make sure everything works. Click on the Jobs link in the navigation and you will see the build that failed. Click on the title of your repository:

This will take you to the job details page. Click on the Rebuild button in the top right:

Once the build is finished, head back to the jobs page and click on your repository title:

From here you will be able to see all the details about the build. If you’re curious about which templates were pushed, scroll down to the test summary and click on the Push templates to Postmark button:

As with Travis CI, you can even send custom email notifications each time certain steps are executed. I find it useful to send an email notification after my templates are pushed. Add this step after the push command:

- run: name: Send notification email command: | postmark email raw --subject="[CircleCI] Templates pushed" --text="Templates have been pushed to Postmark - $CIRCLE_BUILD_URL"

This step executes the postmark email raw command and inserts the build URL into the --text argument so that you can easily view the logs in CircleCI. Don’t forget to update the From email (-f) to use a valid Sender Signature or email address on a verified domain. And enter the email address of where you want to send the notifications in the -t argument.

You’re all ready to go! I recommend checking out CircleCI’s help docs for more info on how to customize your workflow.

Using a bash script

Using a CI/CD tool sounds great and all, but what if you want to just push your templates locally using a bash script? This is another feasible option, but it’s tough to manage for larger teams.

1. Add a bash file (.sh) to your project and name it whatever you want:

#!/bin/bash export POSTMARK_SERVER_TOKEN=Enter your token # Push templates from current directory postmark templates push ./emails # Send notification email (Optional) postmark email raw --subject="Templates pushed" --text="Templates have been pushed to Postmark"

2. Enter your Postmark server token on line 2. The Postmark CLI tool automatically detects this environment variable to authenticate server-level requests. We recommend that you also add this script to .gitignore since it contains your server token.

3. Run your script:


4. By default, you will be asked to confirm your changes to prevent any accidental pushes:

That’s it! You can even use this script with deployment platforms like DeployBot or Buddy.

A note of caution

Once your templates are stored in Github, we recommend that you avoid making changes in our in-app web editor or you run the risk of template versions getting out of sync. If this happens by accident, follow these instructions:

1. Open your terminal and navigate to your project’s template directory:

cd ~/Projects/your-repo

2. Make sure that you have no changes in your current working tree:

git status

3. You should see something like this:

nothing to commit, working tree clean

If you see that there are changed files, you need to stash your files and proceed.

4. Remove your templates from the project:

rm -r ./emails

If a template was removed in Postmark, but not in your Github repository, the templates pull command will not remove it. So we need to make sure you are working from a clean slate since the pull command is only additive.

5. Pull your templates to the project:

postmark templates pull ./emails

6. Enter your Postmark server token to authenticate the request.

7. Review your changes:

git status

8. If everything looks good, push to your git repository:

git add . git commit -m "Sync templates from Postmark" git push

Your Github repository is now up to date with the latest template versions in Postmark.

What’s next?

We hope you find this helpful. This guide should serve as a starting point to setting up a template development workflow, but if you’re looking to use more advanced tooling, we recommend MailMason. With MailMason, you can use Grunt tasks, Handlebars, and SASS to streamline your template development workflow.

P.S. We highly recommend that you make use of Postmark Layouts. It's a way to define common elements like CSS, Headers, and Footers, and reuse those Layouts across many Templates. It will help save you a bunch of time time when developing templates.

Categories: Technology

Feature announcement: introducing Layouts for reusable components in Templates

Tue, 25/06/2019 - 16:58

Rejoice with us, Postmark Template users, for today is a good day. In our previous big enhancement to Templates we introduced template pushing to make it easier to manage templates across environments. We also recently released the official command-line interface for Postmark, which makes Templates even more tightly integrated with your existing development workflow.

But there was one feature that I know you have been waiting for the longest: the ability to reuse components across Templates. We know how frustrating it is to edit common elements like the date in a footer, or a logo, or a design change you want to make across all your Templates. So today we are really excited to announce the release of Postmark Layouts — a way to define common elements like CSS, Headers, and Footers, and reuse those Layouts across many Templates.

How it works

With this release, you are able to extract all the common elements from your emails, and add them to a Layout. Each Template that uses the Layout will inherit the common elements from that layout, and all you have to do is write the message content and include any calls to action you might need. The diagram below shows how this works:

When you go to the Templates section of your account you will now see a new tab called “Layouts” where all your reusable content lives:

We’ve made it really easy to create new Layouts and use them with your Templates. You can add Layouts independently, or do it as part of creating a new Template. What’s more, pushing from one server to another now pushes both Templates and Layouts, so testing global changes and then making it live across all your emails is really easy as well.

A quick detour on Partials vs. Layouts

I can hear that question in the back of your head… why did we go with a Layout approach, and not Partials, like many other email providers do? We did extensive research before and during the development of this feature, and what we heard from the vast majority of developers is this: even though Partials seem like the “right” way to go, Layouts are way simpler to understand and use, and covers most (if not all) of the possible use cases you have. We heard that all you want to do is extract the CSS from your emails, and be able to make changes to headers and footers once across multiple Templates.

As we were working on the feature our initial instinct was to just implement Partials because “everyone is doing it.” But we realized early on that Layouts is a more elegant solution to the problem we’re trying to solve, so we validated the idea with customers, you agreed, and off we went.

What’s next…

Ready to get started? Excellent. We have a couple of resources to get you on your way:

  • This help doc explains the ins and outs of using the feature in the UI.
  • We also updated the API so that you can manage Layouts easily, and we’ve updated our developer docs with the new endpoints and responses.
  • Mustachio (our templating engine for C# and other .net-based languages) has been updated with Token Expanders to make it easier to work with our new Layouts feature.

Over the coming weeks we’ll also add layout support to our official libraries, the Postmark CLI tool, and MailMason.

This release marks the final step in a long journey to build a Templating system that lets you confidently send your email without worrying about how it will work in different email clients. We really hope you enjoy the new Layouts feature, and would love to hear your feedback. Just get in touch — I read and respond to every email!

Categories: Technology

API Bulk: The Final Frontier

Mon, 20/05/2019 - 18:48

Traditionally Postmark has focused on sending only transactional messages with the highest deliverability standards, and that’s produced a ton of loyal fans that boast we’re the best in the business! *blushing* But if we can accommodate more types of messages with the same high-quality sending standards, many of our customers prefer us as their sole email provider.

Our mission 🛰 is to make email painless and enjoyable for development teams, and we're in the unique position to both preserve our world-class 🌎 transactional service and superior deliverability while using that experience to build the ultimate bulk sending environment in parallel♊︎. So I’m pleased to announce that we’ve launched 🚀 brand new infrastructure for managing what we call “API bulk”, that is, similar messages sent to multiple recipients.

Those who’ve been testing it here for the past 6 months have seen truly stellar ✨ and consistently fast deliverability that I’m over-the-moon 🌜about! Of course, the goal is to be more universal 🔭 about the kinds of messages Postmark can support, but so far selected customers have been sending mainly app updates, release notes, daily digests, and event invitations. I’m personally on the lookout for developers willing to go boldly 👩‍🚀 into more use-cases, so this is where you come in!

Please make contact 👽 if you’re interested in trying out Postmark API Bulk, and my team would love to chat about your specific sending practices and volume requirements. We always want to optimize our tooling and services to best support developers, ensuring your email needs and Postmark are always a match made in heaven 🌤.

Questions you might have Are you just trying to make more money?

To clarify our goals for this project, we definitely aren't trying to compete with the likes of Mailchimp or other email marketing platforms. This project is just an attempt to fill in the gaps we see in transactional vs. bulk messages, to be able to send more of that grey area mail that may not be pure marketing/promotional but does need to go out to multiple recipients at once. Traditionally we rejected all messages like this, which based on feedback from our customers split their app's messages across multiple providers. Our goal is to be able to accept more of those high quality, high engagement messages to make life easier for devs.

So you’re just accepting everyone as a customer now?

Postmark will never be an open door to any sender. We're still manually vetting each potential customer, chatting with them one-on-one about what they send and why. Unlike some other providers who accept almost anyone who will hand them money or free data, we're dedicated to supporting only senders who follow and exceed best practices. Of course just in case someone is especially clever at hiding their intentions, we've also built internal anti-abuse systems that not only help us analyze all senders' performance but can stop potentially spammy messages before they’re even sent. Our API Bulk project has provided even more opportunities to build on and improve those systems that preserve our exceptional deliverability and high standing with receiving ISPs.

Won’t this affect transactional mail?

Based on our experience, we have always recommended separating bulk and transactional traffic using different sending IPs and From domains. They have entirely different origins as well as vulnerabilities, and so following our own advice we’ve chosen to create a separate but parallel infrastructure for them. That means transactional and bulk traffic do not mix in Postmark, including when it comes to IP ranges. This follows best practices for separating email reputation as recommended by inbox providers like Gmail.

Do you have any documentation on how to send API Bulk?

If your account is approved for sending bulk messages, we'll recommend working with the /batch endpoint for sending to a maximum of 500 recipients at once, opening up to 10 concurrent connections.

Categories: Technology

Announcement: changes to the way we handle headers when sending with SMTP

Thu, 02/05/2019 - 17:38

We wanted to let you know that on Monday, May 20th we’ll be making a change to the way we process SMTP headers for emails that are sent with SMTP. Please note that this change does not affect sending via the API.

Historically, when Postmark accepted messages over SMTP, we have constructed the To, Cc, and Bcc headers for messages sent to show only the subset of recipients you specify during sending. In some uncommon cases, this behavior meant that not all recipients would be visible in the message that is delivered to your recipients.

With this update, we will ensure that the recipients that are visible in your messages’ To and Cc headers are the same as what will be shown to the final recipients of your messages. We will no longer reconstruct them based on our older behavior, which, in some uncommon cases, could have prevented some recipients from being displayed in the final email that we deliver.

What you need to know:

  • This change only changes behavior for SMTP sending; API sending is not affected in any way.
  • We will never include the Bcc header in messages we deliver to your recipients. Your recipients will never see a Bcc recipient list in their email client.
  • For most senders, this change will not impact you. If you do not explicitly set the To, Cc, or Bcc headers during sending, then your SMTP client is building these headers based on the recipients for your email.
  • If you send messages to single recipients, this change will not affect you.
  • If you use Postmark to relay mail out of an internal mail server (such as Exchange or Postfix), the To, and Cc headers will now be displayed with all of the original recipients of that message, even if you are only relaying the message to a subset of the recipients via Postmark. Again, these headers will have been set intentionally by your mail client if you have included multiple recipients in a single message.

For the vast majority of our customers, we do not expect this change to affect what is displayed or sent from Postmark on your behalf.

To be clear, this is how recipient headers should work — we shouldn’t be altering these headers from your emails, so we’re correcting that. However, given the sensitivity of displaying recipients in email, we wanted to provide as much context as possible so that you can review your sending integration ahead of our release of this change.

Please let us know if you have any questions.

Categories: Technology

Feature announcement: a more granular status page

Tue, 09/04/2019 - 17:58

We're serious about transparency at Postmark, so a useful status page has always been really important to us. We hear feedback from you all the time that you love and appreciate the page, but that you wish it could be possible to see the status of individual services so that it's easier to tell the impact on sending/receiving.

Well, wish no more. We just released an update to the status page that lets you see the status of each individual service, and also drill down into the response times and past incidents for each service.

There is now no more guessing as to how any service issues we might be experiencing are affecting your application email. We've also updated our Slack app and Status API to reflect these changes. Also remember that you can subscribe to status alert emails, or follow our dedicated alerts Twitter account to get real-time updates.

We hope you find these changes helpful, and please keep the feedback coming.

Categories: Technology

With Postmark, sends millions of emails with confidence

Fri, 05/04/2019 - 18:00

In this customer interview, we talked with Kate Reynier, Customer Success Team Lead at, an online scheduling tool for your team that eliminates back and forth emails and allows customer bookings straight into your calendar. Customer Success Lead, Kate Reynier Can you tell us a little bit about your experience and the work you do? is an online scheduling tool. We've been operating since 2008 and have customers all over the world. I am part of the Customer team, and I’ve been doing Customer Support and Customer Success for more than six years.

How are you using Postmark on projects today?

We send more than a million emails a month. This includes our own transactional emails and also emails to our customers' customers confirming, reminding and following up on their bookings.

The Customer team relies on Postmark for information about email delivery. A customer might not be receiving emails for some reason so we check the activity log for details about the process as well as any issues that mean the email wasn't delivered. 

Before moving to Postmark, we used a competitor that was extremely limited in its activity logs. We could only search the last two weeks and there was no easy way to identify specific emails in a group that had gone to an email address. So while we could be reasonably confident that the information was generally correct, we weren't able to point to specific, individual emails and how they performed. 

This and other limitations meant we dreaded using their logs and preferred other troubleshooting options. When the team saw the Postmark activity log we sent up a collective cheer! It is clear, easy to read and includes exactly the level of detail we need to troubleshoot issues with confidence.

Why did you choose Postmark to deliver your transactional email?

We had been looking for a long time for an alternative to the provider we were using due to their limitations and cost. Postmark has made it easier to help our customers because of its accessible and detailed activity log which means we get better information faster.

This interview has been lightly edited for clarity.

Categories: Technology

What not to do: When transactional emails become too robotic

Tue, 19/03/2019 - 13:00

One of the biggest challenges faced by SaaS founders is making their businesses feel human, relatable. In the modern era of the internet, consumers value the feeling that they can connect with a business beyond the boilerplate interactions they’re used to.

Building up a persona is one of the key ways you can stand out in the hailstorm of content online.

We as businesses understand this and put a huge amount of work into crafting our communications for optimum engagement. Landing pages, content, web copy, marketing materials and more are consistently optimized for sharp messaging and have that personable, fun edge.

Image of an email from Trello Trello email example

Despite all of the work going into 21st-century persona branding, there’s a hole in the bucket: the transactional emails that often have a big impact on our customers feel cold, stale, and robotic.

And on the one hand, it makes sense- after all, you need customers to trust that these messages are reputable. They’re entering sensitive personal information.

Thing is, you’re missing out on key opportunities to connect more deeply with your customers and build a positive brand experience into the simplest interactions they have with you.

So what do transactional emails look like for your business? You’re likely sending:

  • Password resets
  • Order Confirmations
  • Email receipts
  • Dunning emails
  • Subscription renewals
  • And more...

Alongside the meaningful impacts these messages have on your customer’s experience, each of these messages is also deeply tied to your overall bottom line.

So why are we letting them become so robotic and automatic?

The first step to improving your communication strategy is using a transactional email provider that allows you to brand, personalize, and optimize these emails. From here, let’s dig into the ways that you can make transactional emails a positive experience for your customer base.

Honor the customer experience

No matter what, you want to provide the best experience possible every time a customer interacts with you. When analyzing your transactional emails, start by taking the customer’s perspective.

A password reset is a quick response to solve a frustrating issue. Order confirmations and email receipts give your customers peace of mind that their request has been received and are often vital for their record-keeping. Trial ending emails ensure your customers know they’re not being duped into paying without notice.

In each of these situations, your team is providing a service, not simply initiating a mechanical response to a problem. Your materials should reflect this in a courteous, helpful manner.

Image of an email from Loom Loom email example

Dunning and subscription renewal emails help your customers to continue using a service they value. The catch here is that they also come with a monetary request. At this point in the customer journey, they are making the decision to stick with you, and your communications should reflect that.

You have a chance to nudge them in the right direction and show off the ways that you already improve their day-to-day functioning. Use it wisely.

Respect your customer’s time

While online businesses generally thrive on consistent, open-ended communication, transactional emails require a specific, nuanced approach.

In a nutshell: if you don't absolutely need to bother your customer with a transactional email, don’t.

For example, pre-dunning, or sending emails warning customers before a card expires, is an archaic tactic that will likely frustrate your users.

Used to be, you would reach out to customers thirty days, fifteen days, three days before their card was set to expire. It was irritating, sure, but given the available technology it was necessary for you to get paid and your customer to continue seamless use of your service.

Image of an email from Tick Tick email example

These days, one in five failed payments can be solved by simply retrying the same card.

Services like Stripe offer card updater services that are effective for over 70% of cards that are set to expire. The fact of the matter is that you can take care of the vast majority of your dunning behind the scenes without ever bothering your customers.

We need to start looking at all transactional emails in this light. How can I best serve my customer without unnecessarily bothering them?

Overdoing it on transactional emails like pre-dunning can have a “boy who cried wolf” effect- i.e. when customers receive too many messages in this vein, they can slip down the priority list and may not get opened when it’s really necessary.

Have a little fun

Okay, so you should absolutely respect your customer’s time, but that doesn’t mean you can’t also have a little fun. Bringing some brand personality into this side of your messaging can go a long way.

From password resets to card update emails, you have the opportunity to increase trust and turn a frustrating day-to-day task into an enjoyable experience.

Take a look at this example of a dunning email from Death to Stock.

Image of an email from Death to Stock Death to Stock email example

First thing’s first: the messaging starts with a humorous greeting, but it also moves directly into the “ask” of the message. It gets right to the point, then includes a couple of fun brand-oriented notes alongside the important information.

They manage to get it all across in the space of about four sentences- essentially compressing both information and personality into a clear, manageable CTA.

Genuine, human messaging like this is great from a business perspective because it’s memorable. It helps you to stand out and adds a personal touch to messaging that is so often robotic and insincere.

It speaks to your customers not as users, but as people. 

Here’s another great example from the folks at Wistia.

Image of an email from Wistia Wistia email example

Take a look at that subject line for starters. It’s a fun spin on a classically “boring” email. From there, it’s branded with clean, recognizable assets, providing trust for the customers.

Small tweaks can make a huge difference in the success of your transactional emails. Make these communication points more human, genuine, and yes, even a bit more fun when it’s appropriate. You know your users best, so follow your best brand guidelines and apply them to transactional emails.

Be transparent

First thing’s first: getting these messages into your customer’s inbox is vital. Third party delivery systems that exist for exactly this purpose can be a fantastic tool, but there are a few things to keep in mind.

While much of this process can be automated, you need to do some work before you set it and forget it.

Emails should generally come from a recognizable name with an address from your domain- “white-labeled” in industry terms. This creates the initial layer of trust your customers need to open the message.

You’ll want to send these emails via a different channel from your newsletter and other communications. This lets customers know that an email is related more directly to the status of their account and requires action on their end.

The trick here is establishing authority and trust for these messages. Always send your customers to secure pages. Monetary emails like dunning and subscription reactivations need to be clearly from you, and not phishing schemes.

From here, well-crafted branding goes a long way. Emails that echo the style and navigation of your website give that extra layer of recognition, as well as helping you to stand out amidst all the other similar messages in their inbox.

Monitor deliverability

I know I said you could set and forget your transactional emails, but that’s only partially true. While the basic framework of this system in an investment at the front end that will pay dividends over time, you need to check in on your processes regularly to keep them working at top efficiency.

What if someone never gets a dunning email because their contact information is out of date? What if your password reset emails are bouncing?

These issues can make the jump to bad customer experiences (and cancellations) quickly.

Make sure you’re taking regular dives into your analytics and looking specifically for leaks. Set up alerts for bounced emails. Slack is a great tool for getting these messages directly to you with no downtime, so your team can act when necessary.

An image of Slack messages Slack alerts example

Basically, don’t gamble on these vital messages. Don’t let your approach to transactional emails become robotic once you’ve just spent the time to breathe life into their content. Consistently refine your processes and recognize that the work is never done. Not really.

Pay attention to the little things

We’ve talked about a lot here, but really it all comes down to the customer experience. Your users are humans with feelings, moods, and differing levels of satisfaction with your service. You have a chance to build interactions that consistently improve their relationship with your business. 

Paying attention to the little things adds up over time to create a meaningful brand experience. Even small tweaks to the overlooked elements of your messaging can make a huge difference in building up customer loyalty and setting your business up for long-term retention.

Categories: Technology
Additional Terms