The team was shipping. Campaigns went out, the website got updated, data requests got answered. And still, everything felt harder than it should: attention fragmented across a half-dozen request channels, email threads that kept growing instead of closing, the same decisions relitigated week after week. Everyone was executing well. What none of us had underneath that execution was an operational system.
I realized the fix once I stopped treating the symptoms separately. Email campaigns, website updates, and data requests looked like three different workloads. They were one problem: ad-hoc intake. Every request arrived as an interruption, and context-switching was eating velocity no matter how much effort we put in. So I built an intake process for each surface. My first attempt at each one failed. Usefully. And that's most of what this post is about.
Website ops: ship in sprints
Our site runs on Webflow, and website requests used to arrive the way all requests arrived, urgently, from anywhere. The fix I landed on was three questions, asked in order, before any work started.
Who owns the decision?
First: does marketing alone own this change, or does it need compliance, legal, and product sign-off? Answering that up front directs the entire workflow that follows. Nothing burns a launch date faster than discovering a required approval after the page is built.
What's the real scope?
Second: does this fit an existing template, or does it need new design work? That one distinction drives the timeline, the resourcing, and how deep the review needs to go. A templated page and a net-new design are different projects, and pretending otherwise is how deadlines die.
When does it ship?
Third: instead of launching continuously, I moved us to bi-weekly website sprints. Pages enter a queue, go through pre-launch review, and ship together. The first sprint slipped, and it slipped for exactly the reason the three questions exist: I let a “quick” page in mid-sprint without classifying it, it turned out to need compliance sign-off, and the whole release moved with it. The rule I set after that was blunt. Anything that jumps the queue displaces something else, visibly, with the requester's name next to the trade. Queue-jumping got rare fast once it had a price tag.
After each launch, I send an internal update explaining what changed and why, so stakeholders hear it from us before they find it themselves. I also set up rotating internal reviews: team members walk the site and flag issues without emergency-response urgency. Findings go into a backlog I prioritize calmly, on a schedule, instead of triggering fire drills.
Email ops: intake before send
Email had the same disease in a different body. Requests came in from compliance, product, and other departments, each in its own format, each on its own clock. My first cure failed too: I wrote a spec template and emailed it around. Almost nobody used it, a template people have to remember is a template people route around. What stuck was a request form I built on an Asana board, one door for everything, and I answered every side-channel request with a link to the form and no lecture. The form asks for four things:
- The list, in a defined structure. Email address plus required columns for first name, last name, and source, plus any attributes the dynamic content needs.
- A naming convention. Picked from the set we already maintain.
- A timeline, a send window with a date on it.
- The approver, whoever signs off before this goes out.
Only then does a request enter the queue. Before any send, I run the list through deliverability verification with NeverBounce, no send goes out on an unverified list, because bad data keeps taxing every campaign that comes after it. I review every campaign internally before stakeholders see it, so what stakeholders approve is already sound.
The quieter win was expectation management. Stakeholders learned what “ready” actually means, and marketing could forecast workload instead of reacting to it. And after each campaign, I send a 24-hour performance summary back to the requester, framed as a feedback loop. That report buys more goodwill than any process doc ever did.
The answer changed from “no” to “yes, through a system.”
Data requests: one visible backlog
I moved data requests onto the same kind of board: every request visible in a backlog, priorities managed explicitly, and analysis time protected instead of shredded by interrupts. Nobody was told no more often. They were told yes, through a system that let them see where their request stood and let us do the work without breaking focus. The tell that it worked: the “any update?” pings stopped. When people can see the queue, they stop asking it questions.
This is the unglamorous end of marketing ops, and it's the part that made the glamorous part possible. The same intake-and-queue discipline became the foundation I automated on top of, lead handoff here eventually went from roughly 12 hours to 1–2 minutes, running across the 200+ automated workflows I built. None of that is buildable on a process that lives in email threads. You can't automate what you can't see.
If you're building this from zero
Build the intake form first, ahead of the sprint cadence and the review rotation. One door, four required fields, a board anyone can look at. Expect people to route around it for the first few weeks; answer every workaround with the form link, and don't take it personally. Add the sprint cadence second, once the queue is real enough to schedule against. Add the 24-hour performance summary last. It's the piece that pays for everything above it.
None of this is sophisticated. That's the point. The processes that survive are the ones boring enough that nobody has to remember them.