This was at PingPong, the cross-border payments company where I worked from 2021 to 2025. I joined as Marketing Manager, Ads & Lifecycle, on a US marketing team of seven or eight. 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, roughly ten to twenty a week across four or five departments: 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: nobody had a shared definition of a proper email request, nobody had a data standard, and nobody could name the path from request to delivery. Decisions lived in long email threads that looped in more people over time, and we made them, revisited them, re-approved them, sometimes reversed them. The work shipped. The cost was attention.
I spent my first week sitting in those threads before touching anything. We had no process.
Two kinds of email, two kinds of problems
My first instinct was wrong. I treated everything as an optimization problem. 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.
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.
The request template nobody read
For one-off requests I built a standard for intake, and my first attempt 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 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. After that, people used it. 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 fields. Once the form made the repetitive decisions, I could use my judgment on the requests that needed it.
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.
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 taught requesters that email doesn't end at “send.” They started asking about open rates and clicks.
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. That rule was mine, nobody above me signed it off, and once the board was visibly working it became the default. After that, everything sat in one pipeline, I could see the priorities, and for the first time I knew next week's workload before Monday.
Iterating the cadences
I ran cadences on a different discipline, because here the numbers were the point. I tracked open and click-through rates per email, ranked the list, and sent whatever ranked last to the standing A/B queue. That rule stopped us 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, because these emails fire every day and the small wins compound.
The two things I'd do first
The tools (Mailchimp, HubSpot, NeverBounce, Asana, an LLM for list checks) mattered less than how they fit together. I ran the same play later across the whole marketing-ops stack.
Skip my detours and do two things this week: split one-off requests from ongoing cadences and give them separate workflows, then 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.