Rethinking multi-marketplace publishing

• Average time to publish an advertisement cut by 80%
• Onboarding time for marketplace training reduced 75%, with higher NPS
• Marketplace channel activation up 20%
• Marketplace-related support tickets down from 7% to 4% of total volume
• Merchants can now publish 20+ advertisements in a single flow, replacing a one-at-a-time process

Picture a Magazord merchant with a large catalog. To grow, they decide to sell across more marketplace channels. On our platform, Brazil's biggest ones were all available: Amazon, Mercado Livre, Magalu, Shein, Americanas, Centauro, Renner, and more than forty others.

The catch: they had to publish their catalog to each channel manually, one product at a time. For a merchant with hundreds of products and a handful of active channels, that meant thousands of repetitive submissions, each one an opportunity to give up.

By the time the work reached me, a direction had already been approved above me: add a new registration step to the existing flow so merchants could tie products to channels earlier. It was a reasonable-sounding patch. It was also a patch on top of the exact structure that was causing the pain.

I could have executed it. Instead I asked to spend a week understanding why publishing was so heavy before committing a single screen.

I ran interviews with two groups that the original decision had skipped: the marketplace support team, who fielded the complaints every day, and merchants who lived inside the flow.

Two things came out fast. First, the friction was not the absence of a registration step. It was that the same product data had to be re-entered, reformatted, and re-validated for every one of the 40+ integrations, each with its own rules. Second, the support team was absorbing that cost invisibly, walking merchants through the same manual work over and over.

I took this back to the stakeholders and changed the frame of the problem. The question was never "where do we add a registration step." The question was "how do we let a merchant enter product data once and publish it everywhere."

That reframe moved the work from a small addition to the old flow toward a scalable, self-serve publishing model. It was a harder problem, but it was the right one, and the evidence from support and merchants was enough to shift the direction that had already been set.

I designed a batch publishing flow where a merchant selects products, maps them to as many channels as they want, and resolves channel-specific requirements in one guided pass instead of forty separate ones. Shared data is entered once. Channel-specific fields surface only when a channel actually needs them, so the merchant is never re-typing the same information.

I prototyped the core interaction with Claude Code to pressure-test it before handing off, and I brought the junior designer on my team into part of the execution as a mentoring opportunity.

• Time to publish an advertisement dropped by 80%
• Merchants publish 20+ advertisements in a single flow, replacing one-at-a-time submissions
• Marketplace channel activation rose 20%
• Onboarding and training time fell 75%, with a measurable NPS lift
• Marketplace-related support tickets dropped from 7% to 4% of total volume

The most valuable thing I did on this project was not the flow. It was refusing to build the approved solution before I understood the problem. The interviews cost a week. Building the wrong thing would have cost a quarter and left the real friction untouched. Taking the reframe back to the people who set the original direction, with evidence they did not have, is the part I would repeat every time.