The ABC’s of Moving to Cloud Email Templates

Welcome to the Future

So you’re a product manager or engineering lead and your organization is finally deciding to make the switch to cloud email templates — congratulations! The first step for a successful transition is setting proper expectations:you should anticipate a project on the scale of a switch from an old HTML website to a content management system (CMS) like Wordpress. It’s actually an apt comparison, in many ways your team’s needs are best suited by a “CMS for email”.

A common counterpoint from engineering teams is that this is something they can just build themselves, and that’s exactly how I built my expertise in this area. Trust me, after building numerous in-house email systems, I can say with certainty this is something that requires a dedicated solution. That said, not all cloud email template systems are created equal, so what should you be looking for?

Trust

Typically you’re looking at migrating your transactional email templates to a cloud provider, which means that these emails are not only tightly tied to your product, they’re also very important. These are incredibly valuable emails like confirmations or password resets, so it’s important to find a reliable solution in order for your product, engineering, and marketing teams to have confidence in the end result. Let’s break down what that means to each stakeholder.

For your engineering organization, the most important thing is to trust that when their systems want to send an email, the right email gets sent. To ensure this happens, the two most important features are a static identifier for each template and a simple API for triggering the email send. The ability to support a staging environment and integration with unit testing are two additional capabilities your engineering team may be looking for.

Your product team is going to care most that the email template, as a product itself, works as intended. They’ll be most concerned that the right data, personalization, and any other dynamic content is all incorporated properly. To ensure this, look for products that specifically require template validation before it can be published to production.

Finally, your marketing team needs to be confident that they can work with email templates without having to go back to engineering. Things like validation and email client testing are especially important here.

Separation of Engineering and Email

If you’re contemplating this switch, likely the number one driver is something along the lines of: “Be able to update email templates without a code deploy”. While that’s really important, it’s equally important to think about what the future “division of labor” will be. Knowing how expensive engineering time is, and that your company wants its resources focused on building what they’re best at, you’re answering the question of “how much does this free up engineering”.

A simple way to think about this is to ask yourself “what if the proposed template solution doesn’t support looping?” If this new process doesn’t support looping, any time you have an email template that would include a list of things (such as line items in a receipt or multiple items in a notification email), that list would need to be rendered (or generated) in your backend. Considering the original driver we stated, does the solution really solve the your problem?

What you’re looking for with a move to cloud templating is not a loss in features by doing less than your engineering team. Your goal is to find a platform that actually enables new capabilities. Thinking back to the WordPress example, nobody would use WordPress if the blog post editor was just plain text like an HTML file. WordPress makes it easy to add images, embed a YouTube video, or link to another web page. In terms of email templates, this encompasses things like dates. If you render dates and times in your backend, you can ensure it’s localized to the customer’s time zone (aka “Oct 1, 9am pacific time”).

If a solution doesn’t support localization, you now have a choice of dropping localization all together, or making a sacrifice in your separation of engineering and email. For example, if you wanted to change that date to “Saturday Morning”, like Uber does in their email subject lines (“Your Saturday Morning ride with Uber”), your marketing team would need to go back to engineering and request the change.

Collaboration of Product and Marketing

Just as it’s important to separate your (very valuable and time constrained!) engineering team from email, it’s equally important to increase collaboration between your marketing and product teams with regard to email. Key points to consider for this collaboration include how a cloud email template solution handles your staging environment, how product will test a new feature release, and how both teams can collaborate on growth efforts.

To start, look for a mechanism for product and marketing to test email changes without going back to engineering. This is similar to how Wordpress has “draft” and “publish” stages for a post; your marketing team needs to be able to draft email template changes prior to them going into production. This should all happen without having to go back to your engineering team. More advanced platforms may even allow for different tiers of user permissions such that your product team can have the final say before a template change goes live.

Support for staging or demo environments is a must as well, without any additional changes from engineering. Find a platform that allows marketing to prep whole email branding changes and deploy them without additional engineering effort.

The final consideration for the product team is the ability to A/B test transactional email changes. Often a product team will be tasked with growth-related activities (like increasing on-boarding engagement), and the transactional emails that are part of your on-boarding process are key to that optimization.

Additional Considerations

A popular phrase in the engineering world is “don’t repeat yourself’ or DRY. It’s based on the idea that you should write code once and then try to re-use it as much as possible. This idea is very useful in the world of email templates, where not only do you have many common elements (header, footer, your logo and more), but email template HTML is notoriously finicky. Find a platform that allowed you to build your “responsive emails” once and reuse them over and over.

While you are choosing a particular vendor, keep lock-in as one of your considerations. If the vendor uses an open source email template engine, for example, you always have the power to migrate to another solution.

Finally, as much of this piece has illustrated, find a platform that caters towards collaboration between multiple stakeholders. One example is thinking about your customer support team. Some transactional email template platforms track every email sent, and let you preview what the email looks like as it was sent to the customer — an obvious benefit to your support team. A second key aspect to this is permission sets. While customer support may need access to view email logs, they probably don’t need to be updating email templates in production.

I hope this helps guide you on your journey! Between building solutions for others and founding my own my company Sendwithus, I’ve devoted countless hours to cloud email templating solutions. I’m passionate about email and helping others find their way — feel free to contact me on twitter (@mrmch) or email (matt@) to discuss.