Writing · Marketing Ops · Dec 22, 2025 · 5 min

Email intake, rebuilt: one form, one board, one launch sequence

The process around our email was the thing that needed fixing. How I separated one-off requests from living cadences, enforced a data standard, and moved intake to a request board, turning a reactive channel into a predictable system.

5 required fieldson every request
24hfrom send to report

When I joined the team, email was quietly draining energy, which is worse than broken, because a quietly draining thing never makes it onto anyone's roadmap.

Requests came from everywhere: product updates, compliance notifications, internal announcements, one-off customer communications. None of them were wrong, and all of them were “urgent.” What was missing was structural: no shared definition of a proper email request, no data standard, no clear path from request to delivery. Decisions lived in long email threads that looped in more people over time, made, revisited, re-approved, sometimes reversed. The work shipped. The cost was attention.

I spent my first week just sitting in those threads before touching anything. The conclusion: we had no process.

Two kinds of email, two kinds of problems

My first instinct was wrong, and it's worth admitting. I treated everything as an optimization problem. Early on I started sketching an A/B test for a compliance notification before realizing how silly that was. A compliance notice has to be correct and on time; the subject line is the least of it.

That mistake was clarifying. What we called “email” was two categories that everyone, me included, had been treating as one:

  • One-off requests: product announcements, compliance notices, internal communications. These live or die on accuracy and coordination.
  • Ongoing cadences, programs tied to users, prospects, or customers. Living systems that need measurement and iteration.

Running both through the same pipeline confused everyone. An onboarding sequence doesn't need a stakeholder approval chain every time it fires, and a compliance notice doesn't need an experiment plan. Separate categories, separate workflows.

One inbox · every request
Product updatesurgent
Compliance noticesurgent
Internal announcementsurgent
Split into two workflows
One-off requests · accuracy + coordination1
Ongoing cadences · measure + iterate2
What we called “email” was two categories forced through one pipeline: one-off requests that live on accuracy and coordination, and living cadences that need measurement. Separate categories, separate workflows.

The request template nobody read

For one-off requests, the fix was standardization, but my first attempt at it failed. Version one was a document explaining how to submit a request: the data structure, the naming conventions, examples. I shared it in every channel. For about two weeks almost nobody used it. Requests kept arriving as threads, and I kept pasting the doc link like a doorman nobody listens to.

The lesson: a document is advice; a form is a rule. Version two was a request form I built with five required fields (the recipient list itself, first name, last name, source, and any attributes needed for dynamic content) that could not be submitted incomplete. Adoption stopped being a persuasion problem. And once every request arrived in the same shape, most of the clarifying back-and-forth disappeared, because the questions I used to ask by reply were now just fields. Remove the repetitive decisions and judgment goes where it is needed.

Two attempts at one intake standardsame rules, different enforcementVersion onea document, shared everywhereFormatExplainer documentShared inEvery channelCan skip a fieldYesAdoption, 2 weeksAlmost nobodyRequests arrive asEmail threadsVersion twoa form that will not submitFormatRequest formRequired fields5Can skip a fieldNoAdoptionThe defaultRequests arrive asOne shapeThe five: recipient list, first name, last name, source, and any attributes dynamic content needs.
Version two would not submit without all five fields, so adoption stopped being a persuasion problem.

Data quality as system protection

Before any list touched Mailchimp or HubSpot, I ran it through NeverBounce for deliverability. Bad data degrades sender reputation, and that's a debt every future campaign pays interest on.

On top of NeverBounce, every list got an LLM pass before upload. Nothing exotic: paste the column headers and the first rows into a prompt along the lines of “check this list against the five-field spec: flag malformed addresses, missing required fields, and values in the wrong columns.” It catches the embarrassing stuff, like a first-name column full of email addresses, faster than my eyes do. A human still approves every upload; the model just reads faster than I do.

A launch workflow that closes the loop

Once content was ready, I ran a fixed sequence: internal review for copy and design, test sends to ourselves, and only then stakeholder approval, in that order, so stakeholders reviewed something already correct. After launch, within 24 hours, I sent the requester a short report: delivery rate, open rate, clicks, and one suggested next step. Four lines, small enough to read inside a Slack message, and it took me minutes to write because the data was already in one place.

That 24-hour report did more than inform. It reset the expectation that email doesn't end at “send.” Requesters started asking about results instead of just delivery, which is exactly the habit you want them to have.

internal review1test sends2approval3report4the same order every launch
The fixed sequence is review, test sends, then stakeholder approval, plus a four-line report back to the requester within 24 hours, resetting the expectation that email ends at “send.”

From email threads to a request board

As volume grew, the threads themselves became the bottleneck, so I moved intake to an Asana board fed by that request form. Fair warning: the board also took a couple of weeks to stick (old habits route around new tools), and what finally moved people was me politely declining to schedule anything that wasn't on the board. After that, everything sat in one pipeline, priorities were visible, and for the first time next week's workload was knowable before Monday. Execution got smoother, but the bigger win was that planning became possible at all.

Iterating the cadences

Cadences ran on a different discipline, because here performance was the point. I tracked open and click-through rates per email, ranked the list, and made the bottom of the ranking the standing A/B queue, a concrete rule instead of arguing each month about what “underperforming” means. I tested subject lines first, because they're the cheapest change with the fastest read, then content. No single test was dramatic. That was fine. Small wins on emails that fire every day compound in a way one heroic win on a single campaign never does.

If you're where I was

The tools (Mailchimp, HubSpot, NeverBounce, Asana, an LLM for list checks) mattered less than how they fit together. The tools mattered less than how they fit together. I ran the same play later across the whole marketing-ops stack.

If you're drowning in email requests right now, skip my detours and do two things this week: split one-off requests from ongoing cadences and give them separate workflows, and replace your intake doc with a form that has five required fields and won't submit without them. The deliverability checks, the board, and the 24-hour report can come later, as volume forces the issue. The first two you'll want on day one.

Suggested posts