How we decreased bureaucracy and improved efficiency in our communications pipeline | #NovaTech
How do you handle your email templates? Do you store them in the database, or maybe even in code? Who can change those templates, and how? Is the process efficient, and clean?
At some point or another, you may have probably faced some of these questions, and, of course, there are many approaches to this issue, all with their own pros and cons. So, let me tell you what we had and see if you can relate…
Where we started
At Nova, we need to communicate with our candidates and users in an efficient, clean, and reliable way (like in most organizations). We also change our communication templates quite often, updating content, improving the design, reviewing copies, and so on, so we need easy, quick ways for those changes to happen.
We started with the email templates being stored in our database and implementing a WYSIWYG editor for the admins to be able to change them, for those of you who have tried this approach, you will understand what I’m about to say, and for those of you who don’t, pay attention, IMPLEMENTING A WYSIWYG EDITOR IS HARD, especially for email templates.
Let’s say you grab a library that implements the editor itself and you don’t go through the hassle of doing it yourself, you also need to manage media (images, videos, icons, etc), making sure it’s optimized correctly, and served through a CDN in an efficient manner. Also, even if the HTML looks good on your editor, it might not be rendered well as an email, not to mention that there are many email apps and basically, they all do whatever they like.
Most of the time the editor was not working properly, so, when a change was required, the communications team had to ask the tech team to do it. It would go in a sprint, have some dev to do it, check back with the comms team, and if everything was ok deploy it in the next release. 2 weeks to change a text in an email, it was crazy!
We’re not in the business of building an awesome WYSIWYG editor, we’re in the business of talents and community, so any time spent doing this was ultimately wasted.
Standing on the shoulder of giants
As said, we’re not in the business of creating email templates, so… who is? We were already using Stripo for making the layouts of our communications, so we thought we could start there. Stripo is an awesome tool that provides (among other things) a great WYSIWYG editor for email templates, it creates email safe templates, and also allows you to visualize in an easy way how it would look like in mobile, tablet, and desktop.
The communications team had also been using Stripo for a while, and they loved it, so it was clear that it was the right platform for us, but, how could we get those templates into our system to send them to our users?
Our first approach was to use stripo’s api to export them every time we needed them. At first, it worked, but we realized that this “export” functionality was not meant to be used this way. Also it was kind of slow for our needs, we tried caching them, we tried storing them, but it was not a good fit.
Ok, back to the drawing board… So, if Stripo is not the right tool to store the templates, which is? Where could we store the templates for later usage from our backend, but keeping the flexibility of the communications team being able to edit them through Stripo? Turns out the answer was right under our noses the whole time, it was Amazon Simple Email Service with their Email templates functionality, with which Stripo has the option to export the template directly into AWS, so… it was a match made in heaven!
Putting it all together
After having all the pieces, it was really easy to put it all together (most of it was already done for us), so, it would go like this:
- The communications team would create and test the template directly into Stripo, using handlebars for dynamic content
- After they are sure that everything is looking as expected, they export it to AWS.
- The backend side only has the references to the template ids, so every time we need to send an email we would grab the latest content
- From the backend, the handlebars dynamic content would get replaced, and the HTML sent through the service of our choosing (we use AWS SES, but it could be any other).
Side note: To improve performance, we implemented a simple cache to avoid calling SES every single time we needed a template
Conclusion
As you can see, we went from having a lot of bureaucracy when implementing simple changes, to having almost zero interdependence between teams. This way everyone is focused on doing their part, and no one is blocked or interfered in doing their tasks by external teams or cumbersome processes.
We have an awesome communications team that knows a lot about crafting incredible email templates, why should they be slowed down by the processes of the tech team? We also have a great tech team that is focused on building the next generation of Nova, why should they be bothered with petty changes that someone else probably can do better than them? This way, we are able to move forward faster, better, while also looking pretty 😉
Of course that by dedicating enough work and time, you can make your own editor, and have it working properly, but you should ask yourself, is it worth it? Will it make my business better? For us, the answer was no, and by efficiently using services that we already had, we managed to get a very lean, very efficient workflow, with very little work from our tech team, not only in the creation but also in maintenance in the long run.
