Auditing transactional emails

Overview

Quicket went through a rebranding with a new logo and style guide, and at the same time I took over the responsibility of creating and maintaining transactional emails from two of my colleagues in marketing and development. I would need to ensure all of our transactional emails reflected the new branding.

Problem

We had no official inventory of our transactional emails resulting in a lack of organization and standardization across templates. The emails were also rarely updated for content resulting in some outdated, confusing, and inaccurate information going out to users.

My contribution

• Content audit: assessed and took inventory of 80+ transactional email templates

• Content strategy: analyzed and documented email lifecycles; migrated email design process

• Content design: applied new styling and edited each template for content and grammar

Constraints

We unfortunately didn’t have any budget for an email testing service such as Litmus. Because of this, testing emails was very time consuming, and I often had to send multiple test emails to myself or colleagues using different browsers and email account providers.

Migrating services

I wanted to move our email design process from MailChimp, where the previous team tediously built templates using HTML, to a simple drag and drop service. Building templates in HTML is useful when they contain a lot of data, as drag and drop services can inject additional code into the emails, causing them to clip in the recipient’s email account. However, at the time our emails were not especially complex, so the benefit of quickly creating and updating emails outweighed the benefit of reducing clipped emails. I compared a few email design services, looking at simplicity and affordability, that I presented to my Product Manager, and we landed on the platform BeePro.

Template organization

In MailChimp, all 80+ templates were listed in one folder which was another reason content updates fell by the wayside. To create an efficient process in BeePro for myself and anyone who came after me, I needed to find a common way to organize the templates into separate folders.

I printed out each template so I could physically sort them into different categories. I tried a few different attributes to sort by such as messaging type (confirmation, warning, or general information) and user type (event organizer, ticket buyers, or general user). If there were multiple emails that didn’t fit into a possible category, I knew that wasn’t the best way to organize them.

Content analysis

I met with my colleague on the dev team to go through the trigger for each email. I created a spreadsheet so I could see the full context of what actions triggered an email and what other emails they might receive around the same time. I used my previous experience as a Quicket Customer Success agent, where I spoke to dozens of users every day, as my lens while analyzing the information, language, and timing of each email.

Template structure

I met with my colleague in marketing to ensure the templates aligned with the new Quicket style guide. The templates needed to use the same colors and font styles as the website, but there were no specific guidelines for email styling (e.g. padding or alignment). I had a lot of freedom to structure the emails based on my audit and experience on the CS team, and I looked into email best practices for guidance on layout to ensure important information was easy to find and for styling tips such as how much white space to include.

Solution

I organized the emails in BeePro based on user type: event organizer, ticket buyer, or general user. When a new email was created or an old one was updated, there was typically a coinciding help article that needed to be updated as well. The Help Center was already divided by user type, so, as the person who managed both transactional emails and help articles, this allowed me to move seamlessly between the two systems.

Drawing from the new site style guide, I created a layout with recommended style options for email templates. While I was the one solely responsible for creating transactional email templates, we had marketing emails that fell under the domain of the marketing department, and this ensured we had consistent styling across the board. My colleagues had access to a UXPin wireframe of an email template that we updated over time.

The content analysis revealed the emails that needed updating for clarity. The old “Order Success” email, for instance, had the word “purchase” in the title which alarmed people who booked free tickets, as it implies an exchange of money. I remembered speaking to customers when I was on the CS team who thought we had somehow charged them for their free tickets. I also made sure the order reference was clearly visible, as it’s useful for ticket buyers to find tickets in their Quicket account and helps the Customer Success team with support queries.

I also found that we had a lack of standardized merge tags during the content analysis. For example, in one email we used “reference” and in another we used “purchase_reference.” This left room for ambiguity when creating merge tags for new emails which I wanted to reduce. A marketing colleague helped me create a spreadsheet called The Merge Tag Matrix, where I could see at a glance the merge tags in every email. There was too much backend development required to standardize them all at once, but it was a great reference point for what merge tags to use when creating or updating emails in future.

Lessons

Looking back, printing out 80 email templates was not the best way to try and organize them. Viewing a stack of 80 templates on my desk had me frozen at times, so using an online card sorting tool such as Optimal Workshop would have been a much better strategy.

This project really solidified the importance of consistent and quality communication with other teams. For each email I updated, I had to make sure the devs and I were on the same page about the spelling of merge tags and the data they should send. Then they each had to be tested, even if the same merge tags were used across the board. I unfortunately let a few broken merge tags slip by before I fully grasped this lesson.

Impact

As Quicket added new products and features, our inventory of transactional emails grew from around 80 to over 120. The Merge Tag Matrix in particular became very helpful when we started changing our merge tag language from MailChimp to Handlebars, allowing me to keep track of which emails used which language. This project made it possible for me to quickly organize, find, and update emails when needed so that our users always had the right information at the right time.