Building the MSOps payments division
Payment launches touched eight departments and no single function held them together. I made the case for a dedicated payments division inside MSOps, the Marketing Services Operations department, and built it from scratch.
What they asked for
Launches keep slipping. Each delay has its own cause, so keep fixing them one at a time.
What was underneath
The pattern was structural: no system connected the people who had to work together to ship a launch. Fixing launches one at a time would have meant fixing them forever.
The starting point
Sportserve ran payment launches across 12 countries, and every launch touched Product, Engineering, Compliance, Creative, Customer Support, and external payment providers. Each team could see its own piece clearly; nobody had a view of the whole sequence.
Launches kept slipping, and fixing them one at a time was a reasonable response, since each delay had its own specific cause. Looking across the portfolio, though, the same pattern kept repeating, which pointed at something structural: no system connected the people who had to work together to ship a launch.
From inside any one department that was invisible. It simply looked like a slow launch.
The decision
Solving launches one at a time would have meant solving them forever. I made the case to leadership for a standalone payments division inside MSOps (Marketing Services Operations), built from zero, rather than another workaround.
I designed it as an internal agency model: one team owning project management, B2C campaign execution, B2B onboarding coordination, creative production, vendor management, and customer issue resolution for everything payments-related, across all 12 markets.
How I measured it
Launch throughput and production error rate across the whole portfolio, not any single launch. If the system was working, every launch would get faster and cleaner, not only the ones I was close to. That was the honest test of whether the constraint was structural.
The build
I hired the initial team of 5 and defined the operating model: Agile sprint cycles, RACI models for ownership clarity, centralized project tracking, and a centralized project tracking system, and a prioritization framework that sequenced launches by market impact rather than by who asked first.
I wrote the SOPs, the QA processes, and the standardized launch templates so the team could execute consistently without me in every decision. Then I traveled to new regional offices to train local teams in person, since the model only worked if it held the same way in every market.
The division sat inside the broader MSOps department, which grew from 5 to 36 over the same stretch as four other leads built out their own divisions in parallel. That wider growth wasn’t my build. The 5-person division was.
0 → 5
Team built from zero
2×
Campaign throughput
~40%
Production errors reduced
Throughput doubled, errors dropped about 40%, and payment method adoption improved 20–30% by market, because launches finally ran through one system instead of eight. The structure outlasted me.
Tech
Jira
Sprint planning and backlog management
Agile and RACI
Delivery governance and ownership clarity
Confluence
SOPs and operational documentation
Creative production tooling
Merchant assets and campaign creative
Previous
Analytics and tracking infrastructure rebuild
Next
Founding and scaling CraftConcepts
Tell me what you’re working on.
If you’re working through a customer journey, system, or operational problem and think my experience might help, I’d like to hear about it.
Consulting on lifecycle, conversion, and automation—and open to the right senior role.