In previous posts, we talked about how to build emails and how to track the results in Marketing Cloud, but we missed the most important step in between both tasks, how to test the emails before pressing the Send button.
Nowadays, there are more email clients and devices with different screen resolutions than ever (the now trendy Dark Mode for mobile and desktop devices is a really interesting/challenging topic to tackle for the developers…). That increases the risk of one of the emails we sent to don’t be displayed properly when the customer opens the email. Of course, this is directly related to the probability of this customer to unsubscribe from our communications, so we have to minimize this as far as possible.
The Testing Team
As it happens when talking about software development, it is not really a good practice that the developer tests its own code. It happens the same when building emails. An independent testing team can provide a different point of view of the email and it will be easier to spot issues and improvements.
Which roles should be part of the team? As always, it depends on the content of the email and how the campaigns are structured, but in general lines, we would need someone to…
- …check the copies of the email (even more when managing different languages)
- Who? The agency or the owner of the campaign
- …check the links and UTM parameters are working fine
- Who? the Google Analytics team, if needed
- …check the email is displayed well in the main email clients (for this point, we can help our work using tools like Litmus)
- Who? the owner of the campaign or the same developer, in case we are using Litmus
Depending on the company, industry or the specification of the email, other checkpoints may be added. For example, to check the dynamic content fits accordingly to the defined rules.
Taking care of these three points, we will ensure the email is ready in terms of content and design. It is true that is really difficult to accomplish the 100% of email clients but, understanding the tracking results of previous sendouts, we can identify which are the main email clients and devices our customers are opening the emails from, so we can pay special attention to those when testing the emails.
The Approval Process
Now we have the Test Team, it is time to organize the checklist to make this process the most agile as possible.
Considering we have in place a process to define the aim and the technical requirements of an email (audience, sendout date, content details…), we have to do the same to specify who should approve what, and the steps that have to be followed once the email is ready to be tested (the checklist). With that, we will reduce the number of back and forces or emails that will get lost in the mail inbox (there are plenty of tools that can help us to improve these activities: Jira, Confluence, Trello, Asana, Microsoft Teams…) and we will ensure that the email was tested entirely, keeping also a track of the approval timings so we can improve the process based on this information.
There is no perfect checklist that works for all the scenarios, it depends on how many stakeholders are involved, how big the teams are, the specifications of the email and the campaign planning. Understanding and involving the teams to define this process will also help to improve communication and detect issues.
Time is one of the most important things to keep in mind when defining this approval process. We have to commit with sendout dates and the business needs, meaning that we have to do a retro-planning analysis, considering the gaps that will need to be covered in case of some delays or unexpected issues occurs.
Here is my personal opinion. Even when we are not able to commit with the sendout date or we are in a rush to make it happen, as the title says, better late than sorry. It is better to postpone the sendout and test everything carefully than press the button and cross fingers that everything goes well. When the button is pressed, there is no way back.