Narvar

Narvar rarely breaks on its own. It breaks at the handoff either side of it: which platform triggers the return, which system owns refund timing, and whether the ERP or the warehouse decides when stock becomes sellable again. Before recommending anything, we map that handoff against the retailer's actual stack, not Narvar's reference architecture. A business running three warehouses and two marketplaces carries a different ownership model to a single DTC store, and the diagnosis has to reflect that spread. The diagnostic closes on a scoped recommendation: what changes, what it costs, and what it protects, usually refund accuracy and the credit note line at month end, rather than a feature list Narvar could technically support.

Narvar can initiate a return, authorise it, generate a label and trigger a refund. Which of those steps actually belongs to Narvar, versus the ecommerce platform or the ERP, is the decision that determines whether finance trusts the credit note feed. Get it wrong and refunds fire twice, or a return sits approved in Narvar while the ERP still shows the original order as fulfilled and billable.

Ownership lines worth settling before build: - Return authorisation: Narvar or the ecommerce platform - Refund trigger: Narvar event or ERP-confirmed receipt - Stock disposition (resalable, damaged, write-off): the warehouse system, not Narvar - Store credit and gift card balances: the finance system, read-only to Narvar

None of these are architecture questions. They are contract questions, and the technical build only works once someone has answered them in writing.

Running Narvar's connections to the ERP, warehouse and ecommerce platform as hand-built point-to-point scripts works until someone needs to add a second warehouse or a marketplace, at which point every one of those scripts needs rebuilding. Patchworks, underneath those connections, gives them a shared substrate: adding a new fulfilment node or sales channel becomes a configuration change rather than a new project. AI-assisted monitoring on top of that substrate flags mapping drift and queue stalls faster than a person checking dashboards on a schedule, which matters most in the first weeks after a peak event when volume is highest and attention is thinnest. Cogent² operates that layer as integrators using AI-assisted delivery to move faster and catch more, not as an AI vendor selling a dashboard. The commercial case is speed of onboarding new channels and warehouses, and predictability in what each addition costs to connect.

Queue depth on the return-received event is the first thing worth watching, because it is the earliest signal that something downstream has stalled, usually before a shopper emails asking where their refund is. Exception volume on refund triggers is the second: a spike there usually means a mapping mismatch between Narvar's return reason codes and the ERP's credit note categories, not a Narvar fault.

Signal | What it usually means Rising queue depth, stable volume | Downstream system is slow or down Refund exceptions clustering by reason code | Mapping drift between Narvar and the ERP Carrier scan gap | Label generated but never used, or scan event lost

Catching these before the finance team closes the month, rather than during the close, is the entire point of watching them.

Returns operations teams need a runbook, not a product manual: what to do when a return sits in 'label generated' for more than 48 hours, who re-triggers a stuck refund, who owns the warehouse side of a receipt that won't post. Escalation ownership has to be named, not implied, because returns volume spikes at predictable moments, usually post-peak, and the team on shift then is rarely the team that built the integration. We hand over runbooks and name the escalation path at go-live, not as an afterthought once something has already gone wrong.

Hypercare after go-live is where mapping errors surface, because real return reason codes and real carrier exceptions are messier than anything caught in testing. The weeks after a peak selling period are the sharper test: return volume into Narvar can run well above baseline, and a queue that coped comfortably normally starts to lag under that load. Support in that window means someone watching exception queues and refund posting close to real time, not a ticket raised after a shopper has already escalated to the retailer's support desk. Once volume settles, support shifts from active watching to scheduled checks and change management.