The pitfalls of transactional emails - what to keep in mind when choosing a system

Amongst all the options available for transactional emails, what is important to consider? In this guide we’ll look at what are the challenges of transactional emails you should know about when selecting a system for your application.

📨 Email clients compatibility

Ensuring correct rendering of your email templates in all email clients is not an easy task. Outlook being the most problematic of all. In the email world we're still in 1999. 

What are your requirements in terms of email layout? Unless you only send very simple-looking emails or plain text only, go for a solution that includes a drag-and-drop email builder that handles all the email client compatibility for you.

💬 Multi language and translations: keep maintenance in mind

Does your application have multiple languages? If that’s the case, consider how the maintenance of your emails and each translation will work.

The solution offered by many email platforms consists of copying each template for each language required. This is how you quickly end up with an overwhelming amount of emails to maintain.

Other platforms require the use of good ol’ PO files (don’t we love them!). 

Duplicates are fine as long as you never have to update your emails. The problem arises when changes are needed. The same update must be done and tested in each language template. This is typically a long-winded workflow with a lot of back-and-forth between developers, designers and marketers.

At MailBindr we advocate for a different approach: one template should serve multiple languages. This saves you time and effort with fewer templates to maintain. We also don't enjoy PO files and much prefer working on translations in an usable interface.

👤 The challenges of personalisation

Chances are your transactional emails will include dynamic data specific to the recipient. So you will need a system to render custom data and also ensure they are validated.

Use validation to prevent sending broken emails

Validation is important to avoid sending broken emails to your users (emails missing content or showing code instead of the expected custom data).

Look for an email tool that include a validation system to prevent such errors.

In Mailbindr for example you can easily create your dynamic variables directly in the email editor and choose which ones are mandatory (required by the API) to send an email. This will ensure that all your emails are being sent with all the essential data. In case a field is missing, developers get a detailed response in the API call.

Dynamic data is resource-intensive

When you want to add dynamic data to your email template, you need a template language which modifies the HTML. If your ESP doesn’t support dynamic templating, you’ll have to do the logic in your application code and render the template there, which is resource-intensive. The more so, the larger your volume of emails.

We recommend using a platform that handles the HTML rendering for you so that you only have to pass the data. 

Preview your personalised emails with proper test data

Curly bracket are pretty but to send your emails with confidence to your users, it's important to be able to test your dynamic data and preview your email with proper test data. 

To connect your emails with test data, you'd have to implement a system to simulate test data and preview / send it. Additionally, to be able to change your test data, you have to implement an app with form and database entries. In itself this is not very complex but it's just additional time and effort needed for something you could easily outsource. 

Save yourself that hassle and look for a platform that supports inserting test data in your email previews. 

😮‍💨 Inefficient workflows that waste days of work

Team resources and the workflow for the creation and maintenance of transactional emails are important aspects to consider. A smart workflow will save you and your team days of work.

In the “old-fashioned” way, developers have to be involved for every single tiny change like a button color or adding a comma here and there. Any bigger edit will require another series of tests and sign-offs. That just sounds exhausting and it’s wasting precious development resources that could be better utilized for more high-level tasks.

Think about how to involve non-technical team members in the email creation process. Working only in code excludes a big part of your team. Designers, content creators and marketers should be able to work the content and design of emails directly themselves without developer intervention. With MailBindr you can allow others to support you in the email creation process.

⚠️ A risky publishing process 

Think about how you will update templates, which are already in use. How will you test updates of an email when there is already one version in production? How will you safely deploy your new version to your business-critical production code base?

This is a risky process, where errors can easily happen. We highly recommend selecting a service that allows you to publish to different environments (your local draft -> testing or stage -> production) in a controlled manner.

📈 Scalability: outsource the rendering process

Rendering and sending thousands of emails in a short amount of time can be challenging. You have to make sure the email data is prepared in your application. Rendering and sending emails with dynamic data is resource-intensive and will require a lot of your server power.

It’s recommended to move this process to a different worker or its own server. With MailBindr you already have an external infrastructure optimized to manage your email queue outside of your infrastructure.

💰Budget

Last but certainly not least: pricing. In the plethora of options available for transactional emails services, the price tag can go from free to thousands of $ per month for enterprise solutions. Are tools like Knak, Stensul or Dyspatch worth the high price? 

This is no right or wrong answer to this question. It depends a lot on your specific requirements, team size and capabilities. 

Consider the following:

• How many emails do you send per month? Many tools start very cheap for low volume but the price increases exponentially as your email volume grows. 
• Are you paying for features that you don't need? Do you need email automatisation? 
• What level of support and onboarding do you require?  

The justification for the expensive enterprise price tag is in the sales & marketing costs but not always necessarily the quality of features and product interface. 

At MailBindr, we strongly believe that smaller teams have that flexibility and closeness to users to make a great product. Being a small team with low overhead, we are able to pass on the savings on operation costs to our customers.