Intact iQ

Most Intact iQ engagements start with a governance gap someone has been quietly covering for months. Before we recommend anything, we map who currently owns stock, pricing and invoice state across the systems feeding Intact iQ, and where a human is patching the join with a spreadsheet. That map usually surfaces the real cost: a finance team re-keying sales orders, or a warehouse working from stock figures nobody has validated in weeks. The commercial outcome we're driving towards is simple. Fewer manual touches at month-end, fewer disputed invoices, and a system of record finance can actually sign off against.

The decision that determines whether this integration survives contact with peak is ownership, not architecture. Does Intact iQ own stock once a sales order posts, or does the WMS? Does ecommerce own order status until dispatch, or does Intact iQ claim it the moment an invoice generates? Get this wrong and you get two systems both convinced they're correct.

Ownership map, in brief: - Stock on hand: owned by WMS, Intact iQ reads not writes - Sales order status: owned by ecommerce until dispatch confirmation - Invoice and payment state: owned by Intact iQ, full stop - Customer master: single direction, never bidirectional sync

Subsidiaries and FX add a second layer here. If Intact iQ runs multiple entities, currency and tax logic needs deciding at design stage, not discovered at the first cross-border order.

The integration layer isn't a passive pipe moving payloads between Intact iQ and everything around it. It validates, retries, logs and alerts, and if it only forwards data, it fails silently at the worst possible moment, usually peak. That's the governance role Patchworks plays for this integration.

For Intact iQ specifically, the practical gains are speed of change and lower coordination overhead. Adding a new warehouse or marketplace channel doesn't mean rebuilding point-to-point connections into Intact iQ's invoice-only endpoints. It means configuring another flow against a layer that already knows the retry and validation rules. Cogent² runs this as expert operators with AI-assisted monitoring doing the pattern-spotting across queues, not as some AI-first replacement for judgement. Cost stays predictable because change happens inside a known structure rather than a new custom build each time.

Mechanics only get you so far. The first sign is usually a queue backing up quietly, not an alert firing loudly. We build monitoring around the failure points that matter for this integration specifically: stuck sales order queues, invoice generation gaps, and stock corrections that failed retry and sat unresolved.

Where this breaks: a retry loop that succeeds on attempt four but nobody logs that it took four attempts. The order ships fine. The exception pattern that caused it doesn't get fixed, and it recurs at the next volume spike. Visibility here means catching drift in the queue before it reaches a finance close or a stockout, not a dashboard that looks healthy while three orders sit stale underneath it.

SOPs need to name who owns a stuck sales order, who owns a failed stock push, and who gets paged when invoice generation stalls. We write runbooks against the actual failure modes above, not generic incident templates. Escalation ownership gets named, not assumed, so a Friday evening exception doesn't sit unassigned until Monday.

Hypercare after go-live focuses on the two weeks where edge cases surface that testing didn't catch, usually order-editing timing and invoice retrieval gaps. Peak readiness means checking queue throughput against realistic order volume ahead of time, not discovering the ceiling live. When something does break, our escalation path gets the right person looking at the right queue within minutes, not after three internal handoffs. We stay on the integration past go-live rather than handing it off cold.