FREE Salesforce Consultation: 508.935.2275 or contact us online

Scalable, Efficient, Custom HTML Template Systems in Salesforce Marketing Cloud’s Content Builder

Jake Gibbs | April 17, 2020 

Salesforce Marketing Cloud (SFMC) provides the framework to support efficient, scalable, custom templates, thus allowing non-technical users the option to easily build emails using a large library of custom-designed, hand-coded modules without knowing a lick of html.

But since your account is only provisioned with “stock” or standard SFMC template layouts that aren’t branded or very flexible, some work is required to build your own custom template system to be fully branded, custom coded, and ready for non-techies like marketers or designers to build emails. What does the full process look like? Read on brave template builder!

What are the benefits of modular template systems?

First, let’s clarify why modular design and a template system is better than simply building a template or two and calling it good. A template is typically seen as a rigid, unyielding layout that forces the user to stick closely or exactly to that layout. While good for keeping consistency, do you really want every email to look the same? And what if your content deviates slightly or even majorly from the initial, rigid layout? What then?

You’ll have to build more templates to accommodate, which kind of defeats the point of templates as you end up with “template bloat” as your template count rises. Not only, then, does it become harder to figure out what template goes with what scenario, but it also requires technical help to build new templates each time an unforeseen scenario or layout is needed. Not ideal!

A better method is to think modularly. A module is a section of an email template, not a template as a whole. A module could be a header, a hero, an alert bar, a 2 column product section, an article, a footer, etc. Modules can be rearranged, removed, or added as needed, creating highly scalable and flexible layouts. The ideal template, then, would allow for flexibility in how many modules and what order they go in. In other words, a template system turns the template into a lego mat, while the modules are the legos sitting in a container, ready to pull in as needed.

Modules allow you to build many layouts, create variations of modules based on designs and content, and can be stored neatly away in an organized content library folder structure. Ready to be pulled in at a moment’s notice, this module library allows you to build many types of emails with one single, master template. Down the road, you can easily expand your module library and any new module will work with the master template without requiring new templates to be built.

What does an efficient process of planning and implementing a custom template system look like?

There are typically multiple stages with multiple teammates, depending on your business structure and workflow. They are as follows:

  1. Strategy >> Marketers define the use cases for emails in general. What emails do you need to achieve your marketing goals? Are they for triggers, journeys, ad hoc campaigns, etc? What should the emails achieve? Who will be building them? This bird’s eye view should create a mind map of the requirements for what emails the template system should support.
  2. Content >> Now that the emails have been defined, what content will be in these emails? What layouts are needed to support that content? This stage requires thoughtful, module by module wireframing and determining what content, how much content, and what variations are needed. This stage should produce a list of every module needed, along with wireframes for each module.
  3. Design >> Once the content has been well defined, it’s time to bring some life into these wireframes. Skilled designers take these rough concepts of modules and ensure that their designs are branded, appropriately eye-catching, user friendly, hierarchal, and are possible to be coded given the many limitations of html for mobile, Dark Mode, stubborn email clients like Outlook, etc. The designs should also be easy for a non-technical user to edit, meaning fancy slice layouts, background images, etc should be avoided to prevent difficulty in building the emails down the road. In the end, the designs should be appealing, but not complicated as this will pose problems for developers coding the modules and / or non-techies building the emails.
  4. Coding and testing >> Here developers take 100% approved, completed designs and work their magic. They code a master template and modules in a way that they work seamlessly together. Considering all major mobile and desktop clients such as iPhone, Android, Outlook, Gmail, Yahoo, and many others, they platform test on Litmus or Email on Acid to ensure the code renders flawlessly. In situations where email clients don’t support advanced css properties (like rounded corners, custom fonts, or drop shadows), they ensure graceful fallbacks. Once their part is completed, no coding will be needed by anyone building emails from these modules.
  5. Platform Implementation >> After the code is fully operational and platform tested, it is ready to put into SFMC. This involves using logical, organized folder structures and naming conventions for the template, modules, and images used in the modules. After the library is implemented, it is ready to use and build emails!
  6. Training >> Typically non-technical users, specifically those unfamiliar with SFMC’s interface or email building in general, need 2 (or maybe more) training sessions to walk them through the process. Training session 1 is usually a walkthrough where the trainer, who ideally is recorded, gives an overview of the interface itself, along with how the template / modules are set up and organized. Then the trainer uses these assets to build an email, from start to finish, including adding modules, editing modules, and doing send previews using the completed email. At this point the attendees should feel comfortable trying a build on their own. After they have had a chance to build an email or two, they will likely have questions about the interface, process, or SFMC in general, which may require another training session. But eventually, even the most non-technical user will feel ready to build emails autonomously, without help!

Are there any best practices?

Now that the process has been covered, here are some considerations to make your modular library project go smoothly.

  • Think long term, not short term. Consider your urgent needs, along with those you may have months from now.
  • Avoid the politics and ego that often accompany these projects. No matter your role, be flexible and adaptable. Speak out instead of just doing what you’re told. Each person involved can play a big role in the success of the overall project, and politics and ego simply get in the way.
  • Go big, not small. Better to have a big library and lots of options than to limit yourself with a small library and have to constantly expand it and repeat the entire process any time a new scenario emerges. Aim for 50+ modules to force yourself to stretch a bit and aim high.
  • Make sure that the strategy and content stages are done properly and have been well thought out. Otherwise designers and developers will end up spending much more time modifying designs and code based on changing requirements, instead of having those requirements well-defined from the start.
  • Create variety in your library. Since there is no limit to how many modules you can have, why not make multiple headers/footers with different feels, such as different layouts, styles, or content. Make modules with variants and options. Not only will this support more use cases for your marketing team, but it will also create more visual variety for your audience, likely increasing engagement and conversions.
  • Involve the whole team through the whole process. Designers and developers, though their role happens later in the workflow, need to have a say from the beginning. Designers can help provide guidance on wireframing content and making sure the content requirements will lead to good designs. Developers can ensure that designers aren’t designing things that are not possible to be coded, or that will be hard for end users us build emails from.
  • No matter how well built the template system, the end user building the emails needs to be capable and willing to learn. While the SFMC template system isn’t rocket science to learn, it will require some effort on the part of the end user to become skilled at using the tools it provides. The goal of the team should be to make this very easy for the end user, and the team should enable them to ask questions, learn, and even expand their hard skills like html to enhance their abilities and independence from developers.
  • Understand that SFMC has limitations, primarily in its visual editor. When non-technical users are building emails, they will find scenarios where the visual editor in Content Builder either doesn’t allow a way to do something (like change padding for instance) or does allow it but only in the visual editor (like changing a background image). To avoid frustration with the product limitations, understand them up front and don’t blame the developer!

What about maintenance, expansion, and documentation?

No matter how well you architected and implemented your initial module library, over time things will change and use cases will arise where you didn’t (and couldn’t possibly have) foresee email or content requirements that your current library doesn’t support or fully support.

Maybe you’re rebranding. Maybe you’re looping in another business line. Maybe your new VP of Marketing has a new vision for where to take the email program. Maybe you’re expanding your email program. Whatever the change, know that you can always revisit this process as an expansion effort on your library, which by no means is etched in stone.

Additionally, maintenance may be needed on your library. Maybe some modules aren’t used that you thought would be. Maybe some modules need variants created. Or others need to be edited. in your team again and do some “Spring Cleaning” from time to time, ensuring that your library is always current and ready to use at a moment’s notice.

6 months from now you may encounter new opportunities or challenges, requiring you to expand or modify your library. Be flexible and consider it a living entity that can grow and evolve as your business needs change.

Lastly, on large accounts with large teams, documentation can be helpful to keep everyone on the same page in terms of expectations, and also as a way to map out the email program as a whole in terms of marketing, content, and designs.

Is the Effort Worth It?

A typical modular library project in SFMC takes about a month or less, depending on how large of a library is needed and how political and cohesive the team involved is in implementing. But one month of work will create the foundation for an email program that is robust, scalable, and efficient, even for the most non-technical of end user!

Back to Blog
Jake Gibbs

Jake Gibbs | Design Specialist

Jake Gibbs is a Design Specialist at ListEngage and an expert at designing and building elegant, cross-platform compatible, mobile responsive emails and landing pages on the Salesforce Marketing Cloud. From brainstorming and ideation to polishing the final product, he loves the creative process. Jake has worked with more than 60 clients since joining ListEngage in 2014. Some of his projects have included L’Oreal, Vanguard, Carhartt, Harvard Business School, RCI/Wyndham, Huggies, and Planet Fitness.