Stensul raises $34.5m in Series C funding

Why you need to rethink using Design-to-Code or Templates & Modules email creation workflows

It might just be the most dangerous phrase in business. Yet, when it comes to email creation, it’s been heard constantly since the 1990’s. “That’s the way we’ve always done it.”

We’re more than two decades into the 21st century, but Design-to-Code and Templates & Modules are the two most commonly-used email creation workflows. These methods were developed just as the web was coming into its own. Before the cloud. And, importantly, before collaboration became commonplace, courtesy of things like Google’s G Suite.

What makes this all the more remarkable is the world has, as Satya Nadella, Microsoft’s CEO, recently observed, experienced “two years of digital transformation in just two months.” But email creation is stuck in a time when Grunge style was fashionable.

These two approaches to email creation are too difficult, too unreliable, too unpredictable, and takes far too much time than they need to. In a recent analysis of email production cycles at companies across several industry sectors, stensul found it often took individual email requests days, often weeks, to complete.

Even with it taking a long time to produce an email, demand for this digital marketing channel shows no signs of diminishing. That’s because once produced, an email is uniquely able to generate revenue, deliver ROI, and retain customers. And that makes the need to find more efficiency and agility in your email production has never been greater.

In a careful examination of the Design-to-Code and Template & Modules email creation workflows, stensul found they’re still very much 1990’s methods. An assortment of single-purpose tools used by specialists to perform their tasks in the creation workflow. No tool, no person involved in either process is really connected. This results in single email requests taking lots of time to be completed. Errors abound that contribute to further delays. And, often, the output is of less quality than had been hoped for.

Design-to-Code: dependent on developers

The Design-to-Code workflow requires each email to be hand-coded. This takes a lot of time and effort on the part of the developers. But once the coding is completed, their work isn’t done. If in the approval process something is found that needs to be changed, it has to go back to the developer to be fixed. Even if it’s changing a comma to a period. Then during QA if something unexpected appears, the email returns to the developer to be adjusted. And back it goes for approval and QA.

In large part because of the dependence on developers, as well as all that back-and-forth, the Design-to-Code workflow can’t scale. Along with being prone to bottlenecks, the absence of automation limits the ability to produce more emails in a short, predictable timeframe.

Templates & Modules: error prone

The Templates & Modules email creation workflow is somewhat more time-efficient than Design to Code. This workflow has email requesters pulling templates or modules from a company repository. Using these frameworks makes the basic building of the email 30% to 50% faster than Design-to-Code. But, it’s still  dependent on developers. Only in a different way.

The templates selected may include superseded branding or out-of-date regulatory statements. To correct such things, developers have to get involved. In addition, the code in the templates can get broken. And back they go to developers for repair.

It’s worth noting that emails created in this manner can be completed in 1 to 2 weeks, versus the 2 to 3 weeks when Design to Code is used. But if the issues and errors mount up, whatever time advantage might exist is quickly lost.

Why rethink

As noted, Design-to-Code and Templates & Modules are workflows born in the 1990’s. Email volume wasn’t what it is now. Further, the way many companies operate is different from that era. More and more organizations work in a decentralized model where people who need something done often do it on their own.

The amount of emails that need to be created now and in the days ahead – quickly and with quality results – will only increase. The need to reduce dependence on developers – as well as the value of having them spend their time on higher value work than fixing broken code in a template – can spell the difference between a marketing operation being efficient and something far less.

Optimize workflow with an Email Creation Platform 

To increase the number of emails your organization creates per month by more than 150%, create them in 4 hours, not 5 to 10 days, and have all of them be on-brand and responsive, move from a Design-to-Code workflow to adding an email creation platform to your marketing technology stack.

Or, to cut the email build time in a Templates & Modules workflow 5x, with 4x fewer touchpoints, add an email creation platform to your marketing technology stack.

An email creation platform brings together all involved in the process into a highly connected, collaborative, automation-aided workflow. Individuals without any coding experience can produce effective emails in little time. And there’s no need to worry about compliance or, for that matter, technical quality. It’s all handled by the platform. Further, because the process takes far less time, there’s more time available to analyze data, develop communications strategies, and test for ways to achieve better outcomes. Oh yes, and developers will spend more of their time engaged in higher value work too.

To learn more about how and why an email creation platform does away with the deficiencies of the Design to Code and Templates & Modules workflows download the eBook “How to Optimize the two most-commonly used email creation workflows.”

And, to learn more about what an email creation platform is and does, download the eBook “An Introduction to Email Creation Platforms.”

Ready to see Stensul?

Recent Blog Posts