One Person Email Team Image

Sending Quality Emails as a One Person Email Team

0

There are a lot of nuances to creating a good email. Even more when you consider technical limitations, accessibility, brand guidelines, and the limitations of ESPs (email service providers). This can be a lot to remember—to implement and check each email before it goes out the door. This is doubly true if you are a one-person email team or freelancer.

This post will walk through some handy ways to streamline your email pre-deployment process. By creating documentation to help minimize errors, you’ll streamline production, maintain email quality, and make your life easier.

What Does a Quality Email Look Like?

My approach to email is that I rather it be correct as opposed to on time. Unlike a mistake on the web where an article can be updated or incorrect code pulled from the live server or an update pushed to a server, recalling an email is not possible. It is true that a correction email can be sent, but that risks drawing more attention to an error that might have gone unnoticed. 

Cat wearing a hat as an email disappears

Instead of focusing on what could go wrong with an email, let’s focus on what a quality email could look like. When reviewing an email, either my own or someone else’s, I like to focus on three main areas: technical, content, and brand & design. This is in no way an extensive list, but a quality or accurate email from this perspective could look like this. 

Technical

    • The email is built with HTML code and passes validation
    • Personalization fields populate from the recipient file with fallbacks for null values
    • Email rendering is good on desktop, mobile and degrades nicely

Content

    • The content passes spell check with no errors
    • All external links are provided and landing pages are live, with correct tracking in place
    • All relevant images have descriptive alt text

Brand & Design

    • Spacing between elements is consistent with brand guidelines for mobile
    • Email uses correct brand colors for all text, buttons, links and other elements

In a perfect world, there would be another set of eyes to review each email before it goes out the door. But, as a freelancer or one-person email team, that may not be the option. Self reviewing our own work for accuracy is part of our day-to-day workflow in order to maintain quality. 

Mistakes May Happen

All of that said, we’re all still human. And despite how many years we’ve been doing this, the laser attention to detail or the muscle memory we’ve developed, mistakes happen

I've made a huge mistake

That said, we need to do our best to avoid mistakes. Especially mistakes that are in our control—or at least are in control for us to minimize the possibility of those errors from happening. We can do that, plus help make our day-to-day email life easier, by documenting our processes, common gotchas, and technical aspects to be aware of. 

Future You Will Be Thankful

As a fellow email-loving human, I have a confession to make.

I am terrible at taking notes. 

If I have to make a fix, I’ll refer to previous bookmarks or Google to find a fix, implement it, and move on. This is ok, if it works and I can get the email out the door. But what happens if the same issue pops up in the future? Or, if the once working fix from before no longer works? What do you do? To help future me from having to start from scratch each time, I can document the nuances of a campaign or project as I am working on it. 

Documenting For Future You

As I am working on a project, I approach documenting by writing down each step as I go. And when I say write down each step, I literally mean write down each step, not want I think each step is. Try not to assume that in the future I will remember which folders those files were saved in, or what to look for in a list. The first pass does not need to be pretty, typing it out bullet point style in a Word or Google doc is fine—refining and clarifying any gaps will come later. 

Consider breaking your document into sections. Documentation for a recurring, quarterly campaign may have sections for production (building the email, adding content, testing), launch (sender information) and data (which audience files to use, seed lists, etc). Be sure to write out common gotchas, such as change the sender name from ABC Company to Stacy at ABC Company, especially if it’s different from the norm.

Other things to note in your documentation include:

  • Naming conventions for templates, lists, assets, campaign tracking, etc.
  • Which pieces of the campaign are need and who they usually come from
  • Any data formatting or cleaning that needs to happen before the launch
  • Seed or test list recipients
  • Who will be approving the email for launch

If as a freelancer you are juggling campaigns or templates from different companies, including more of the technical, content, or brand and design specifics like I mentioned above would also be beneficial. The goal here is to help lessen your mental load, by writing down parts of your production, launch, and QA / QC process. Having a reference to walk through, step by step can help to make missed checks like double-checking the sender name less likely to happen. In my experience, most mistakes that I’ve made, I could have been prevented if I just slowed down and took the time to double or triple check my own work before hitting send.

Identifying Bottlenecks and Pain Points

Another approach to documentation is to think about what pain points exist in the current process. An example, is there confusion on where the data is coming from or what format it needs to be in for that campaign that comes in every so often? Or what columns the data should have for the variable content or personalization to work?

In addition to documenting your production or launch process, you can include information or answers to questions that may come up from external parties. Providing the data team with a sample file, or list of what columns should exist in the data upfront, may help cut down on the back and forth later. It’s frustrating to block out time to start working on a project, only to realize you are missing some pieces. This can be a headache for you and your client, especially if it causes delays in the project completion or launch timeline.

But Wait, Aren’t There Programs to Help Check My Emails For Me?

Yes.

Yes, there are. 

But as great as software is at helping us check (and fix) our work, there are a few places in your email that still need a human eye. For example:

  • Correct word spelling, but not the right usage (their, they’re, there): While Email on Acid will catch profanities and misspellings, you’ll still need a human to make sure copy makes scents. (Get it?)
  • That your links are going to the right destination. Again, Email on Acid can confirm that your links all work and that tracking is present and consistent throughout an email (and even update it when it isn’t), but the software doesn’t know where you intended to send people.
  • Wonky rendering.  Rendering platforms will show you how an email looks in different clients, but they aren’t yet able to tell you if what they show is correct or broken. This is where humans come in. 

Along those same lines, if you are not running your email through campaign precheck for each send, or with each major template or component change, you may be missing some of the issues it would bring to your attention. Overall, it’s a balance between using tools to help us send better emails and not relying too heavily on them to catch everything.

Conclusion

Again, this article is not meant to be a rulebook that applies to everyone right out of the gate. It’s meant to encourage you to look at your current process and think about it. What information or nuances are you keeping in your head? What’s that one thing you forget to double-check each time? If there was an emergency and you had to hand this project off to someone else, would they have all the information they need?

The idea of documentation can be a scary, time consuming one, but it does not have to be. Documentation takes some effort up front, but the payoff is saving time and mental load in the future, so you can maintain email quality more easily. Your documentation can be a literal checklist of what to review, or handwritten notes, or HTML comments in your own code. As long as it’s written down and it works for you and future you, that’s all that matters.

If you don’t QA, test and preview your email in
Campaign Precheck, are you really sending an email?

We always recommend testing every email every time. But why stop there when you can make so many other strategic and tactical enhancements? Things like accessible code, perfect inbox display, fast-loading images all play a critical role in an email’s ROI. Campaign Precheck is end-to-end email QA, testing AND previews in one seamless workflow. Optimize content and your code, test for deliverability and preview how it will look for subscribers to save time and improve performance. Sign up for a free trial and start sending better email.

Start a Free Trial

Author: Shannon Crabill

Shannon is a Senior Email Developer at UnitedHealthcare. She has 7+ years of experience as an email developer and has spoken at industry conferences about the importance of collaboration between email and marketing teams and maintaining quality in a high-volume environment. She gets nerdy about documentation and outside of email, she can be found tweeting about tech, coding with Javascript, Ruby on Rails and enrolling in every software development course she can find.

Author: Shannon Crabill

Shannon is a Senior Email Developer at UnitedHealthcare. She has 7+ years of experience as an email developer and has spoken at industry conferences about the importance of collaboration between email and marketing teams and maintaining quality in a high-volume environment. She gets nerdy about documentation and outside of email, she can be found tweeting about tech, coding with Javascript, Ruby on Rails and enrolling in every software development course she can find.

Leave a Reply

Your email address will not be published. Required fields are marked *