Hey Marketing Nation,
The new company I work for has not taken the leap to Email 2.0 yet. As part of our preparations, we want to have one master email template developed to save down into several templates for various purposes. Now that so many companies have already made the switch, are there things you didn't include in your new master template that you wish you would have made part of the requirements?
Thank you in advance for any thoughts!
Full disclosure: I've never used Email 1.0, I started using Marketo the month that 2.0 was released. BUT I'm a bit obsessive about creating the ultimate template as I manage an instance with multiple brands and have worked to develop a single tokenised template that works for all of them. A few of my must-haves that made this possible:
I hope that's helpful, but I suspect you'll also find Grégoire Michel's detailed posts on the subject helpful as you go through this process:
This is all GREAT advice, Grace. I appreciate your input! Tokens I had thought of. As well as padding as a local variable. Clearable elements, alignment variable, and "don't make everything a default module" are just the kind of GOLD I was looking for. And I have read, several times, Grégoire Michel's posts. This time around I plan on the Email 2.0 going much smoother than the first. Thanks again.
Hey Bonnie - glad it's helpful
The other thing I would add - especially relevant if you're building the new template into program templates or always-on campaigns - make sure that the template has been thoroughly tested internally for ease of usability and externally for client responsiveness before you do build it into those.
When you make changes to an email template, those changes are carried into emails based on that template via the creation of a new draft. If the changes affect a specific module, those changes don't always automatically apply - often you will need to delete and re-introduce that module from the email for those code changes to be present. I'm sure you can see how this would scale to a significant piece of work pretty quickly if you make a significant change to a frequently used module in a template that's used across all your program templates and always-on comms!
It's not always avoidable, esp. with mobile responsiveness which is constantly changing, but it's good to avoid the obvious ones where you can!