Rithum

A marketplace order arriving through Rithum with no matching stock record is the fastest way to generate a cancellation, a bad review, and a support ticket asking where the order is. Before Cogent² recommends anything, we map how stock, price and order data currently move between Rithum and the ERP, WMS or ecommerce platform sat behind it, and where a person is quietly patching the gap with a CSV export each morning. That diagnostic tells us whether the problem is a broken field mapping, an ownership question nobody has answered, or Rithum pushing stale availability to three marketplaces at once. The output is a scoped integration plan, not a slide deck, with a cost and a timeline attached.

Rithum is the channel layer: it is where listings, prices and advertised stock go out, and where marketplace orders come back in. It is not the ERP, the WMS or the finance system, and treating it as a source of truth for stock on hand is where most of these implementations go wrong. The ERP or WMS should own saleable quantity; Rithum should receive that figure and push it out across every connected marketplace, never the reverse. Order ownership needs the same discipline: Rithum raises the order, but the moment it is accepted, fulfilment status should be driven by the warehouse, not guessed at by polling Rithum again. Settlement data is a separate ownership question again, usually finance's, and conflating it with order status is how a tidy build turns into a monthly argument about which number is right.

Some businesses still run Rithum against the rest of the stack through scheduled CSV exports and a person who uploads one every morning. It works, until that person leaves, or a marketplace changes its export format and the gap sits for a week before anyone catches it. Patchworks replaces that with a maintained connector to Rithum and to the ERP, WMS or ecommerce platform behind it, so stock, orders and settlement move on a schedule that does not depend on a human remembering to run it. New channels and warehouses onboard in weeks rather than a fresh build each time, and the cost of running it stays predictable instead of growing with every connection added by hand. Cogent² operates that layer as expert operators, using AI-assisted checks to flag the exceptions that matter rather than replacing the judgement that decides what to do about one.

A stuck queue between Rithum and the WMS looks identical to a quiet day until stock on a marketplace drifts two days out of date and a popular line starts overselling. Monitoring needs to watch queue depth and retry counts, not just whether the last sync technically completed, because a sync that ran and failed silently on half its records reports the same green status as one that worked. Exceptions need a visible owner from the moment they are raised: an order stuck pending for more than an hour, a price push rejected by a marketplace, a settlement file that does not match the order count for the period. Catching that inside the queue, before a shopper messages support or finance closes a reconciliation that is already wrong, is the entire point of watching it.

Whoever owns marketplace operations needs a runbook that says, in plain terms, what to do when a Rithum order sits unpushed for an hour, when a stock feed fails for one marketplace but not others, and when a settlement file does not match. That runbook needs a named owner, not "the integration team", because a 2am oversell on a marketplace does not wait for a rota to be checked. Cogent² builds the SOPs with the team that will actually run them, and hands over escalation paths that name a person, a channel and a response time, not a ticket queue that nobody is accountable for clearing.

Peak is where Rithum implementations get tested properly: order volume spikes, marketplaces run their own promotions on top of yours, and the stock feed that worked fine in October needs to hold at several times the throughput in November. Hypercare after go-live means watching queue depth and exception counts daily, not waiting for a monthly report to surface a problem that has been live for three weeks. Once the business is stable, support moves to a lighter touch: scheduled health checks, a clear escalation path when Rithum changes an API behaviour without much notice, and a standing relationship with Cogent² rather than a one-off project nobody can call back into. Marketplace rule changes do not wait for a renewal date.