Fahad H
- Dec 12, 2012
- 6 min read

Ensuring The Email Is Right Before Hitting Send

That moment before you click send on an email to millions of subscribers can really make you sweat, no matter how many times you’ve done it before. Once you hit send, it’s gone to the inbox, and the last thing you want to hear is “did that email go to everyone?”

Confirming an email is accurate before it deploys is more than just proofreading and having a second set of eyes; it’s strictly following a well-defined process to ensure that you’re delivering a message that reflects well on your organization.

On a rare occasion, mistakes will happen, but you need to constantly work and plan to minimize and mitigate your risks.

Here is a smart five-step process that will keep your organization on the straight and narrow with regard to accuracy.

Step 1: Establish An SLA

The first step to an accurate email is a Service Level Agreement (SLA). An SLA establishes deadlines for the campaign’s execution from start to finish. You might ask, what does this have to do with making sure the email is right?

Mistakes are more likely to happen when a campaign is rushed. An SLA gives all of the parties involved sufficient time for each step in the creation process, preventing the errors that are so often the result of someone being in a hurry.

Also, part of having an accurate email is having it deploy on time. An SLA works to meet this requirement of the campaign.

Step 2: Create Direction Document

Next, you will need a Direction Document, which identifies each component of the email and begins your Quality Assurance checklist.

These components include items such as campaign name, subject line, pre-header content, email asset location, copy, links, and more.

When testing, you will verify each component of the email against the original request in the Direction Document, and changes received after the original request should be logged there, as well.

The Direction Document should also accommodate validating verification at each step in the email creation process, from design to deployment.

Step 3: Build

For an email to be right, it must be appropriately coded. This means only using inline CSS, including appropriate code to accommodate Hotmail, Gmail, and Yahoo. It also means including a snippet of code to resize accordingly when viewed on a mobile device.

Coding for email is not the same as coding for the Web, and unfortunately there are too few classes geared toward coding for email. Coding for email is almost like reverting to the way the Internet was coded ten years ago, a way that isn’t encouraged in most Web development classes nowadays. (See additional resources below.)

Working from a template can help ensure required elements are included for every campaign, and that re-usable components (logo, navigation, etc.) are not recoded for each campaign. The less that is changed from email to email, the less risk that an error occurs.

Step 4: Test (And Re-Test)

At this point, you are ready for testing. As you can see, much of what ensures an accurate email happens long before a test email is ever sent. You should determine your complete platform testing criteria for all email campaigns and then base your validation checkpoints from here on out on that document (amending it as is necessary).

If you thought testing was complicated for websites (accommodating multiple browsers on multiple platforms), think again. Email spans multiple ISPs (including Hotmail, Yahoo and Gmail’s free email services); clients (Outlook, Apple Mail); and browsers – both for desktop (IE, Firefox, Chrome) and mobile devices (iPad, iPhone, Android, Blackberry). Each email client treats the code a little differently; and, just because an email renders correctly on one device doesn’t mean you’re in the clear with the others.

As a general rule, I recommend testing in the following environments:

Desktop
Apple Mail
Outlook 2010
Outlook 2000
Webmail – IE, Chrome & Firefox
Gmail
Hotmail/Outlook.com
Yahoo
Mobile
Android
iOS iPhone
iOS iPad

You will also want to consider the statistics of your subscribers to determine if you should accommodate additional testing options. It is important to note that you can no longer base this decision off of the domains of your subscribers (i.e., you have a lot of Gmail subscribers, so you can primarily just test in Gmail, etc.). You will need to take the mail environment (Browser or Native Client), as well as the device (Smartphone, Tablet, or Desktop), into account to know the true appropriate environment for testing.

There are tools available to assist in this kind of rendering testing, and I highly recommend leveraging one if you do not already. Return Path’s Inbox Preview and Litmus are two excellent options.

You will find having a tool like this is a great comfort during email building, like chicken noodle soup when you’re sick. You will feel better, trust me. Still, you will want to send a few live tests, because let’s face it; nothing is as good as the real thing.

In addition to just making sure the email displays right, you also need to proof all copy for spelling and grammar — and then proof it again.

This includes the text in your images in addition to your HTML text. While the creative team should have performed quality assurance testing before delivering the design, you are still responsible for all content in the email. I also recommend verifying prices of products featured in the email with the price displayed on the site.

You also need to click every link to confirm that: 1) it is a valid link, and 2) it arrives at the correct location.

Again, there are tools that can assist in the validation process for item 1; but, 2 requires human confirmation. Many times this is the last component for testing, because a link may not be live until the morning before a campaign deploys, when the website is updated. If this is the case, I recommend proceeding with all other elements of testing and completing this verification on the day it is live, prior to deployment if possible.

Again, for each of the components you are testing, you are validating against the content provided in the Direction Document. If at any time an item fails to pass, correct it and begin the entire testing process again from the beginning.

Once you have successfully passed each validation check in your own testing, find a second person and have them repeat the entire process. Two sets of eyes are better than one — always. If the second person fails any item at any given time, the original creator must correct the error, and the entire testing process resets again.

Step 5: Deploy

Hooray! Your email is finally approved for sending — but you are not done yet. Many errors occur during this final stage of an email campaign.

I recommend having a second set of eyes watch you as you schedule the campaign for deployment. This allows you to talk aloud at each step of the deployment, verifying the receiving lists or segments, noting any exclusions, confirming the subject line, date, and time for sending.

I also always recommend scheduling the email for deployment in the future, even if that means in 15 minutes. This gives you just enough time to reflect on the send and second-guess yourself or do a triple check if you want.

Uh Oh

Even with all of the verifications and multiple testers, an error can still occur. After all, while a lot of processes and documentation can be implemented, the promotional campaign still relies on a human.

Unlike a webpage with an error that can be (relatively) easily corrected, deleted, or replaced, once the email deploys, only a few items may be modified if absolutely necessary.

Unfortunately, subject lines and any other HTML text (which is not pulling from a webpage) cannot be changed once it is sent. Images and links can be modified on the backend if necessary. If a link is not functioning or an image is not rendering, these URLs can be updated. Due to email caching you may need to allow a few hours for the change to propagate for those who had already opened the email.

And That’s Just The Beginning

While this testing is exhaustive, it essentially only covers a single campaign for large distribution. I did not include testing cases for personalization or dynamic content here.

When a campaign becomes highly dynamic, there are hundreds of versions of your email. These require additional specific test scenarios and failsafes, because sometimes it is not possible to test for every option. Email accuracy is highly dependent on established processes that are documented and adhered to.

In addition, with technology changing so quickly, it is critical to evaluate the testing criteria frequently to accommodate that latest update from an ISP or new mobile device that hits the market. But the secret is to have a plan in place, and then to let that plan grow to accommodate new scenarios as they occur.