Skip to content

Email operations: the processes that turn a pile of campaigns into a programme

 

Most email teams do not have a process; they have a calendar and some good intentions (me too tbh). 

Every send gets assembled more or less from scratch by whoever has capacity. The checks that happen depend on who is doing it and how busy they are. Testing happens when somebody remembers. Nothing gets reviewed afterwards unless it went badly wrong. And the knowledge about how any of it works lives in one person's head, which nobody notices until that person is on holiday.

Which is survivable at low volume and becomes expensive quickly, because email is the one marketing channel that is high volume, irreversible and public. You cannot recall it, you cannot edit it, and thousands of people see the mistake before you do.

The industry has started calling this email operations rather than email marketing, and the distinction is useful. Marketing decides what to say. Operations makes sure it goes out correctly, to the right people, and that you learn something from it afterwards.

Btw, my own emails are functioning like this at the moment, right now we are stretched, so the important thing is to remember to optimise the bits that will make the most impact. 

 

Before you dig in, why don't you get access to RE:markable

 RE:markable is the weekly email about emails. Dropping the latest email marketing news, updates, insights, free resources, upcoming masterclasses, webinars, and of course, a little inbox mischief. 

 

 

The send process

Seven stages, and most teams have three

  1. Brief. What is this for, who is it going to, what should they do, what are we excluding and why. Written down before anybody opens the builder. Half the bad emails I see were never briefed, they were just started.

  2. Build. Copy, design, links, personalisation, audience. The part everybody has covered and the only stage most teams formalise.

  3. Review. Somebody other than the builder runs the checklist. Not a vague look, a list with items on it, which is the next section.

  4. Approve. A named person signs off, and knows what they are signing off. Approval that means "I skimmed it and the design looks nice" is worse than no approval, because it creates the feeling of a safety net without the net.

  5. Test. Real inboxes, multiple clients, images off, dark mode, phone. Not the platform preview.

  6. Send. With the exclusions applied, the cap respected, and somebody awake for the next hour.

  7. Review afterwards. The stage almost nobody does, and the only one that makes you better. More on the cadence below.

Seven stages, and most programmes run build, send, and occasionally look at the numbers a week later. The four missing stages are where all the errors, all the learning and most of the deliverability risk sit.

 

The checklist

What to check before every single send

Split into three, because these are three different kinds of failure with three different costs.

 

What breaks the email

  • Every link clicked, by a human, in the test send. Including the ones in the footer and the ones inside images. A broken link on an email whose whole purpose was that link is the most common reason for a correction send.

  • Personalisation tested with a fallback. Send yourself a version where the merge field is empty and see what happens. Hello FIRSTNAME at scale is a bad day.

  • Images off. Does the email still make sense, and can somebody still take the action? Alt text present on anything meaningful.

  • Dark mode. Logos disappearing into backgrounds, buttons inverting, brand colours becoming something else.

  • Mobile, on a real device. Not the responsive preview. An actual phone, held in one hand.

  • Subject line and preheader checked together. They are read as one thing and frequently written by two people at different times.

 

What breaks the experience

  • The right audience, confirmed by count. Does the number look like the number you expected? An audience that is unexpectedly large usually means a filter did not apply.

  • Exclusions applied, and verified. Recent purchasers of this thing, people in a live service issue, people in an active flow, anyone who already did what you are about to ask for.

  • Frequency collision checked. What else is this person receiving this week, from campaigns and from flows together.

  • Tone appropriate to what is happening. A cheerful promotion going out on the day of a service outage is avoidable with one question.

  • Reply-to goes somewhere a human reads. And somebody knows they are on duty for it.

 

What breaks deliverability

  • Authentication still passing. Check periodically rather than assuming. Records get edited by people who do not know what they do.

  • Unsubscribe present, visible and working. Click it in the test. Not the header, the actual link.

  • Volume in line with your normal pattern. A send three times your usual size needs a conversation before it needs a subject line.

  • Dormant and high-risk groups excluded from broad sends. Every time, not just when somebody remembers.

  • Sending from the right domain and stream. Marketing from marketing, transactional from transactional.

 

The rule I would apply:

The checklist is run by somebody who did not build the email.

Not because builders are careless, because nobody can proofread their own work. You read what you meant to write, which is precisely why the typo survived four reads and died in front of forty thousand people.

 

Email health check

Free Email Marketing Health Check

Audit your entire ecosystem in under 30 minutes

Answer a set of straightforward questions across every area of email marketing and get a personalised score, traffic-light priorities, and clear actions and improvements you can make today.

Testing

Stop guessing, and stop testing things that do not matter

Most email testing is button colours and subject line variants, run without a hypothesis, on samples too small to tell you anything, and then acted on as though the result meant something.

Which is worse than not testing, because it produces confident conclusions from noise and those conclusions get written into templates and repeated for years.

 

Test with a hypothesis, or do not test

A hypothesis has a shape: we believe X, because Y, and if we are right we will see Z. Without it you are not testing, you are comparing two things and picking the bigger number.

  • We believe our audience does not understand what the product does. Because support keeps answering the same question. If we are right, an email leading with the use case will out-click one leading with the offer.

  • We believe our frequency is too high for the lapsed segment. Because their complaint rate is triple the rest of the list. If we are right, halving frequency to that group will reduce complaints without reducing revenue proportionally.

Both of those teach you something about your audience that survives beyond the test. A subject line winner teaches you about one subject line.

 

What is worth testing, roughly in order

  • Who you send to. Segment definitions, exclusions, timing relative to behaviour. The biggest lever and the least tested.

  • What the email is for. One ask versus several, give versus ask, format and length.

  • The offer or the proposition itself. Frequently the actual variable, and frequently treated as fixed.

  • Sender name and identity. Rarely tested, and it does more work than the subject line.

  • Then, if you have spare capacity, the subject line. Fine to test, and the least important thing on this list.

 

And run it properly

  • Big enough sample to distinguish a result from noise. A two percent difference on a four thousand person split tells you nothing at all.

  • One variable at a time. Or you have learned that one email beat another email, which you could have guessed.

  • Measure the outcome you care about. Opens are unreliable. Revenue, replies, or the specific action you wanted.

  • Write down what you learned, where somebody else can find it. Otherwise you will test it again next year.

 

Repurposing

Stop making everything from scratch

The most common reason email programmes go quiet or get thin is capacity, and the most common reason capacity runs out is that every asset is built once and used once.

Which is an enormous waste, because the hard part was the thinking and the thinking travels.

 

One idea, several outputs

  • Email to blog. A newsletter that landed well is a post with almost no extra work, and a post is a permanent thing that can be found, linked and cited.

  • Blog to email. In both directions. Publish, then send a version that makes the argument rather than just announcing that a thing exists.

  • Long to short. One substantial piece becomes five social posts, a short email, and three subject lines.

  • Live to evergreen. A webinar becomes a flow. A workshop becomes a sequence. A talk becomes a series.

  • Replies to content. Somebody asked you a question and you answered it properly in an email to one person. That answer is a send.

 

Build the archive as an asset

  • Tag everything by topic when you send it. So that in eight months you can find every email you have written about a subject in a minute rather than an afternoon.

  • Mark what is evergreen and what expired. Evergreen content goes into flows, gets re-sent to new subscribers, and works for years. Most teams treat everything as disposable.

  • Feed your best performers into automation. The email that performed best last year should not be sitting in an archive. It should be arriving automatically for every new subscriber.

The single highest-return operational change available to most teams is taking their six best-performing emails from the last two years and turning them into a flow. No new content, better results, permanently.

 

Documentation

The stuff that lives in somebody’s head

The test for whether your programme is documented: if the person who runs email left tomorrow, how long before somebody else could send safely?

  • A map of what is live. Every automation, what triggers it, what exits it, who is in it. Almost nobody has this and everybody thinks they do.

  • The exclusion rules, written down. What is always excluded from what, and why. So they survive the person who set them up.

  • The sending hierarchy. Which email wins when two could go, and who decides when the rules conflict.

  • The pre-send checklist. As an actual document somebody works through, not a habit.

  • Contingency templates and the escalation path. Pre-approved, ready, and findable at seven on a Sunday.

  • A log of things that went wrong. What happened, what it cost, what changed. The most valuable document your team will own and the one people are most reluctant to keep.

 

The cadence

What happens daily, weekly, monthly and quarterly

 

Daily, during any active sending period
  • Complaint rate and bounce rate on anything sent in the last 24 hours.

  • Anything that looks unusual against your normal pattern.

  • The reply inbox, read by a human.

Weekly
  • Performance against the previous versions of the same email type.

  • Placement indicators and Postmaster data.

  • What is scheduled next week and whether anything collides.

  • New subscribers by source, and first-email engagement.

Monthly
  • Cohort view: how each joining month is behaving over time.

  • Engaged list size, net growth by source.

  • Suppression and exclusion review.

  • What did we learn, written down somewhere findable.

Quarterly
  • Audit what is live against what should be live.

  • Review the flows that nobody has opened in six months.

  • Revisit engagement definitions and thresholds.

  • Check the documentation is still true.


Your action:

Pick the one stage of the seven that you currently skip most often, and add it to your next three sends.

For most teams it is the post-send review, which is also the one that compounds, because it is the only stage that makes the next send better.

 

The conclusion

None of this is glamorous and none of it will be the thing anybody congratulates you on. Process work never is.

What it does is remove the entire category of problem where a good programme goes wrong for reasons that had nothing to do with strategy. The broken link, the send to the wrong segment, the collision nobody spotted, the test that taught you nothing, the brilliant email nobody ever reused, the knowledge that walked out of the door in March.

Marketing decides what to say. Operations makes sure it arrives, correctly, to the right people, and that you are slightly better at it next month. You need both, and almost everybody is running one.

 

Getting email deliverability right What to know & track (1080 x 900 px) (1)

The operational half starts with deliverability

Most of what belongs in an email operations function is deliverability work: monitoring, exclusions, list hygiene, stream separation and knowing what normal looks like.

 

My free 60 minute Email Deliverability Training covers the metrics and the audit process. The Email Deliverability Certification Programme takes you through it properly, with the templates I use with clients.


Further reading from The Vault:


 

Like this blog? You'll love RE:markable

RE:markable is the weekly email about emails. Dropping the latest email marketing news, updates, insights, free resources, upcoming masterclasses, webinars, and of course, a little inbox mischief.

 

Email, CRM and HubSpot Support

I help marketers and businesses globally improve, design and fix their email, CRM, and HubSpot ecosystems, from strategy through to execution.

My services include:

  • Email marketing strategy, audits, training, workshops, and consultancy

  • CRM strategy and enablement

  • Full HubSpot implementations, optimisation and onboarding through my agency

If you’re looking for experienced external support (and lots of enjoyment along the way), this is where to start.