Content Syndication UX

The Platform

Recom’s content syndication tool exists because third-party tools didn't. After evaluating existing products with our Syndication Leadership team, I made the call to greenlight proprietary development because the available tools couldn't manage content at the scale, specificity, and uptime our client portfolio required.

What we built manages content publication and integrity across 40,000 product listings for a $600M client portfolio, continuously comparing Recom's prepared content against what's live on Amazon, flagging discrepancies, and giving operators the tools to resolve them.

The V1 platform worked, but the operators using it often didn't know what it was doing, or why.

A New Problem to Solve

The original interface was built to solve an engineering problem. The logic was sound. The language wasn't.

For example, two primary action buttons read "Check creatives (view report only)" and "Check creatives." These nearly identical labels resulted in two meaningfully different outcomes: one updated publication statuses and the other didn't. Operators couldn't predict what each would trigger. The progress modal showed a raw system log while a sweep ran, which was operationally meaningless to anyone who wasn't a developer. Errors surfaced in red text with no resolution path. The post-sweep report delivered findings without a framework for next steps.

I flagged this as a retention and accuracy problem, not a UX nicety. Operators were routing around a tool they didn't trust, which meant issues went unresolved longer and client content stayed at risk.


The Fixes

I brought three specific requests to the product and engineering teams:

1. Make every action describe its outcome, not its name.

The modal was renamed from "Creatives Sweep" to "Sweep Creative Content." The two action buttons became "Sweep & Update Statuses" and "Sweep Only;" explicit about consequences before the operator commits. A confirmation checkpoint was added before the status-update path to prevent irreversible actions on stale data.

AGENT B

Meeting notes creator. Once a human approves the weekly recap, this agent formats it into structured meeting notes following a defined template. Deliberately kept separate from Agent A because the team wanted control over when notes get created, and collapsing both into one agent was creating more anxiety than efficiency. 

3. Surface resolution before findings.

The post-sweep report was restructured so operators saw their resolution options before reading a single issue. Inline actions (Create Case, Update in Google Doc) were added at the point of discovery so operators never had to navigate away to act.

The Result

Listing issue resolution dropped from 10 to 15 days to 1 to 5 days. The platform's capability didn't change. What changed was whether operators understood it well enough to use it correctly.

When the language describes actions and outcomes rather than system internals, operators make fewer errors, escalate less, and move faster through issue resolution.

Content Sweeper — After

Previous
Previous

Signal

Next
Next

Stokke Translations