Torque

We start by mapping where Torque's receipt and transfer events actually land, not where the documentation says they should. Branch logic for transfer orders, purchase orders and returns often diverges in ways nobody has documented, and that divergence is where margin leakage starts. A missing example payload from a receiving endpoint can block mapping work entirely, which is a diagnostic finding in itself: it tells us nobody has tested the hard path yet. The diagnostic closes with a scoped recommendation and a fixed-cost delivery plan, not a vague roadmap.

The decision that matters most is which system owns stock truth at each stage of the transfer order lifecycle. Get it wrong and the warehouse ships against numbers the ERP has already superseded, or finance posts a sales order before Torque confirms receipt. Ownership has to be explicit for TO, PO and RMA branches separately. They behave differently, settle differently, and fail differently. Package-level tracking is a smaller decision with outsized consequence: tracking attached to a product-level line instead of the master package line reads fine in testing and then confuses a customer's delivery notification in production. Design for the master line first.

Point-to-point connections between Torque and NetSuite work right up until a new 3PL, a new warehouse or a new sales channel needs adding, at which point every custom build has to be touched again. Patchworks removes that rebuild cycle. Pre-built connectors and a connector builder mean a new warehouse or channel onboards in days, not a fresh development cycle, and that speed compounds every time the business adds a location or a marketplace. The integration layer should validate, retry, log and alert; a pipe that only forwards payloads eventually fails silently, usually during the exact peak period when nobody has time to notice. Cogent² operates Patchworks as expert integrators, using AI-assisted monitoring to catch drift early, not as an AI-first shortcut around the work. Predictable cost and safer change are the actual commercial argument: fewer emergency fixes, fewer late nights reconciling a transfer order that should never have stalled.

Once the mechanics are live, the question becomes whether anyone would notice if they quietly stopped working. A stalled item receipt queue looks identical to a quiet day until stock drifts far enough that a warehouse picker is working against numbers nobody trusts. We build monitoring around the specific failure points this integration produces: receipt creation stalls from blocked ID lookups, transfer orders stuck mid-branch, tracking misattached to product-level packages instead of the master line. Exceptions get flagged and routed to a named owner before they reach a customer service queue or a finance close, which is the only point where visibility earns its cost.

Runbooks cover the three Torque branches separately, because a fix for a stuck RMA is not a fix for a stuck transfer order. Escalation ownership is named, not shared: warehouse ops handles receipt stalls, finance handles posting mismatches, and both know when to hand off. Short SOPs, reviewed at go-live and again after the first peak.

Hypercare after go-live is where the branch logic gets properly stress-tested, because real transfer volume surfaces edge cases that staging never will. We stay close through the first peak specifically, watching queue depth and exception rate on receipt creation and tracking assignment. Escalations route through a named owner, not a shared inbox, because a stalled item receipt at volume is a warehouse fulfilment delay, not a ticket to triage tomorrow. After the first clean peak cycle, support shifts to a lighter monitoring cadence rather than active hypercare.