THE ICONIC Seller Center

Before anything gets built, Cogent² maps how product, inventory and order data actually move between THE ICONIC Seller Center and the rest of the stack today, not how the diagram says it should. That usually surfaces a spreadsheet somewhere: a product feed massaged by hand before upload, a stock count reconciled against THE ICONIC's own dashboard because nobody trusts the automated one.

Sizes stuck inactive, categories filed under a catch-all, orders arriving faster than the warehouse can confirm them back. The diagnostic ends with a scoped recommendation and a fixed-cost delivery plan, not a generic list of integration opportunities nobody prioritises.

Get the category wrong on a THE ICONIC product set and it stays wrong. THE ICONIC locks the primary category attribute against seller edits, so a product filed under a default category because nobody owned the mapping needs THE ICONIC's help to move, or a full resend. That is support tickets and delay, not a configuration change.

The harder ownership question sits at size creation. A new size comes back `inactive` by default unless the create payload sets status, AU pricing activates on its own, and THE ICONIC's approval runs on a third track entirely. A size only sells once approved and active together, so whoever owns that mapping in the source system decides whether new stock goes live on day one or sits dark for a week before anyone notices.

On the finance side, facilitator-collected tax on marketplace orders has to post separately from direct-channel tax the business still calculates itself. Blur that boundary and finance is chasing mismatched tax lines at period close.

Point-to-point connections between THE ICONIC Seller Center and an ERP or WMS work until someone adds a second marketplace or swaps a 3PL, and then every custom link needs its own rebuild. Patchworks exists to take that off the table: an integration layer built for exactly this kind of marketplace and ERP combination, where onboarding a new channel or warehouse becomes a configuration task rather than a new integration project.

Cogent² runs on top of that as the operator, not the vendor. Expert integration consultants supported by AI-assisted delivery watch the queues for the specific patterns this connection throws up, a stuck retry against a maintenance window, a size stuck inactive, and a person decides what the flag means and what happens next. That combination keeps cost predictable as THE ICONIC sits alongside more systems over time, and a new channel next peak is weeks of configuration, not months of custom build.

Finance loses trust when a THE ICONIC payout lands and nobody can tie it back to the orders it covers, and the remittance file is already two weeks old by the time that question reaches them. Visibility on this connection means catching three things early: a dispatch confirmation stuck in retry against a maintenance window, a size sitting approved but still inactive while the listing shows live, and a stock push that failed silently instead of erroring loud.

| Field | Expected before sale | Common drift | |---|---|---| | status | active | left inactive from creation | | approvalStatus | approved | pending for days | | price status | active | fine alone, misleads |

Caught in a queue dashboard, that mismatch is a two-minute fix. Caught from a support ticket about a product that should be live, it is a lost sale.

Three things need writing down and nothing else: who owns the category mapping decision at product creation, who checks size status and approval before assuming a listing is live, and who the Help Desk ticket goes to when the Seller API throws a non-maintenance 503. THE ICONIC publishes no phone line for integration problems, only the Seller Help Desk inside Seller Center itself, so the runbook needs a named person who knows how to raise that ticket and what detail THE ICONIC needs to act on it. Skip that and every API wobble becomes an ad hoc Slack thread instead of a five-minute lookup.

Peak on a marketplace channel behaves differently to peak on a direct site: THE ICONIC controls the cut-off windows, the approval queue and the maintenance schedule, and none of that moves because a retailer has a big week planned. Hypercare after go-live means watching the size approval and stock-push queues daily, not just the order feed, because a backlog in approvals during a demand spike means stock that physically exists and can't be sold through this channel.

Escalation during peak routes through THE ICONIC's own Seller Help Desk for anything on their side, so the team needs to know what to log there versus what is a problem in their own ERP or WMS before the ticket goes in. Getting that split wrong wastes a cycle on a queue THE ICONIC is already stretched thin on.