Email Templates

Why Shifting from Internal Template Generators to Newer Platforms Makes Sense

Everyone has an opinion on how to build the best ’email templates’ that capture a customer’s attention and leads them to a call-to-action. Some leverage great graphics. Others use captions like, “The 10 Best Mistakes That Cost You Millions of Dollars That You Will Do Again!”

What’s often neglected is ‘how’ to build these email templates in a flexible manner that supports the dynamic needs that drive today’s complex business. At SparkPost, we have found that most companies moving from either an on-premises MTA or a self-service cloud ESP were forced to build their own template generators. Some are fairly sophisticated and flexible with a UI. Most, however, are complex pieces of code that build the email through a series of conditionals and saved text.

Over time, these applications have become fragile systems so changes or upgrades are rare, if any. Even simple changes to text within an invoice email can take weeks given the backlog of work development already has. Plus, they need to test it to make sure they’re not introducing further bugs.

With this in mind, I’m writing this blog, and eventually a series of blogs, to help our SparkPost customers see a vision of how they can move from these older systems and leverage the SparkPost templating system such as:

  1. Why making the shift from internal email generation systems to newer platforms makes sense
  2. The simple stuff, moving from SMTP and fully built emails compiled by development
  3. White labeling email templates; Using substitutions to modify look and feel of the HTML output for branding and white labeling
  4. Shared or Global data versus Recipient data
  5. Arrays and how to leverage them
  6. Dynamic output with multiple rows and columns of data
  7. Multi-language support

Many customers write their own templating system out of necessity. And since most are code-rich and depend on development to make the simplest of changes, Marketing gets hamstrung in their ability to keep up with the demands of a rapidly changing world. Because of this demand for change, when possible, it’s better to separate Marketing Design from Development; this is the key factor for moving to templating for many customers. This doesn’t mean that development won’t help build or customize some of the email templates. It just means that much of the work they were doing is minimized. In a perfect world, development worries about obtaining the right data that goes into the message. And marketing worries about the aesthetics and wording of the message.
In the long run, the speed of change that takes place by separating the creative from development is well worth the change.

Now that development doesn’t need to worry about the creative, they can simply focus on three things:

  1. What data to send each customer,
  2. What events trigger sending the content, and of course,
  3. Any segmentation to target the right users during larger blasts such as newsletters.

Another benefit of separating the creative from development is that pulling the data for each user becomes simpler. The need for conditional after conditional to get the proper data for a given template can be simplified to gather all the data for a user, then letting the template decide which data to use. If the template doesn’t use the data, we only lose the cost of transmitting it from the back end server to the SparkPost platform. However, don’t take this approach to the extreme by sending obnoxious amounts of unused data. Typically, there’s a bulk of personalized information that one can gather and send as a standard bit of personalization data for a template to use. Now, Marketing and Development can synchronize on what data will be available. Then, Marketing can ensure it’s used properly and presents itself in a manner fitting to their banding and messaging.

Now that we have a business case of why to shift from internally built email generation systems to newer platforms that separate out development from the creative, we’re ready for our next blog post. In the next one, I’ll discuss gathering the data necessary for substitution and moving away from fully built out emails sent via SMTP.

Happy Sending,

Jeff Goldstein
Sr. Messaging Engineer, SparkPost
Some Sample Email Templates

10 Steps Great Deliverability Blog Footer