Giving ecommerce exceptions a durable operational lifecycle

Pinemark, an 11-person direct-to-consumer home-goods brand, processed about 4,600 Shopify orders a month with no engineer and two people splitting operations and support. About 5.8% of orders, roughly 267 a month, became shipping problems handled by hand.

Future Built reviewed six weeks of the team's "Shipping Problems" spreadsheet, shadowed the morning sweep, read shipping-tagged Gorgias contacts and mapped fulfillment timestamps. The sweep was a loop: check Shopify for fulfillment, ShipStation for a label or tracking and Gorgias for a customer message, then update a row and ask a teammate to take it. Nothing held state between sweeps, so the next one started over, often with the same order.

The loop cost 13.4 hours a week. The larger cost was delay: a median 6h 12m from exception condition to assigned owner, with 31% of tracked exceptions first discovered because a customer got in touch.

A dashboard would have made the loop easier to read without changing it. The missing object was the exception: when it started, why it qualified, who owned it and how it ended. An order cannot hold that state.

The first architecture decision was what not to own. Shopify owns order truth: order state, payment, fulfillment status, line items and addresses. ShipStation owns shipment truth: labels, carriers, tracking and execution. Gorgias owns support truth: tickets, conversations and replies. Replacing any of them would add risk without adding the missing capability.

The new system owns exception truth: detection, instances, ownership and SLA, notes, and resolution with its reason. Its Postgres database mirrors only what rules read, keyed by immutable Shopify, ShipStation and Gorgias IDs, and each record still lives where it was created. The console opens source records by deep link; nothing in this scope writes back. That boundary keeps a new database from becoming a fourth system of record.

Between providers and rules sits a normalization layer. Shopify and ShipStation describe the same order differently and on different schedules: a ShipStation label can push a fulfillment into Shopify, so an order reads Fulfilled before any carrier has the package. Webhooks are verified, acknowledged quickly and translated into domain events such as tracking.carrier_accepted, so rules evaluate one consistent order-and-shipment state.

Take one illustrative order. #58214 is paid Monday at 10:02. Its label is created at 10:19, pushing a fulfillment into Shopify while nothing has moved. Because the system watched the label appear, the label-without-movement rule starts its clock there. At Tuesday's 10:30 sweep, 24h 11m have passed without carrier acceptance; EXC-2291 opens and operations is alerted.

Rae K. takes it at 11:24, 54 minutes after detection: the label was missing from Monday's pickup manifest. At 13:06 the customer's Gorgias ticket links on order number and email, so support sees the problem is already owned while the reply stays in Gorgias. Rae finds the package on the dock. The carrier accepts it at 18:41, the condition clears, and Wednesday at 08:12 she resolves it: re-tendered to carrier.

Nobody searched three systems to learn whether a problem existed. They opened them only to fix it.

Each webhook's provider and event ID is recorded once, so a redelivered event produces one row and no duplicate work. Raw payload references are kept for diagnosis; rules read only normalized state.

The launch design uses four rules: stale unfulfilled (a paid, non-preorder order past a 48-hour fulfillment window), label without movement (no carrier acceptance within 24 hours of the label), stale partial fulfillment (open line items beyond 72 hours) and carrier exception (a configured carrier-exception status). The thresholds are Pinemark's configuration, not ecommerce standards. Rules run on each event and on a scheduled sweep, because some triggers are things that did not happen.

Each condition is known state, a known threshold and known event history, so a deterministic rule answers it exactly. Every match stores the facts it checked and the rule version, and the console shows operators those checks. Asking a language model whether an order looks late would add variance and an explanation gap to a question with an exact answer.

A match creates an exception instance, its own record rather than a badge on an order, with one open per rule and subject. Its states are Open, Assigned, In progress, Condition cleared, Resolved and Dismissed. Assigning an owner stops the assignment-SLA clock. If an event clears the condition, owned work stays visible; only unowned exceptions auto-close. Resolving requires an owner and a reason, and dismissals feed the false-positive rate. Detection without ownership would still be mostly a notification.

The first version of the data model failed in pilot week one. Before go-live, the system imported a snapshot of open orders and shipments, and rule 2 opened a wave of false label-without-movement exceptions.

The rule was right for live events: when the system watches a label appear, it knows whether a carrier scan has arrived since. The import held only each label and its current status, not the scans the system would have seen had it been watching. Version one treated the snapshot as observed history. An illustrative shipment labeled four days earlier arrived with zero tracking rows, so its clock ran from label creation and fired, although the carrier had already scanned it.

An imported record can prove a label exists. It cannot prove no scan happened. Rule 2 tests for an absence, and absence can only be established by observation.

The fix changed what the rule trusts as its clock, not its threshold. Each shipment records when observation began and whether its history is complete. Imported work is baselined at current status, and shipments with no status start their clock at the baseline. Rules with reliable historical timestamps still evaluate on day zero. Pilot false positives fell from 18.0% in week one to 6.7% before launch, not to zero.

New state had to earn trust before the old one was retired. After the day-zero baseline, a two-week pilot ran only rules 1 and 2, with the spreadsheet as a fallback compared daily. The launch gate was one full week of exceptions reconciled against it. Only then were the remaining rules enabled and the spreadsheet frozen read-only.

The results measure different things and stay separate. Manual exception-management work fell from 13.4 to 4.1 hours a week; the 9.3 released hours were search and spreadsheet upkeep. Median condition-to-owner time fell from 6h 12m to 1h 08m, about 81.7%, because ownership begins at detection. Both carry high attribution.

Exceptions first found through customer contact fell from 31% to 17%. That measures how problems are discovered, not complaint volume, and attribution is medium. The launch false-positive rate was 6.7%, and 90% of exceptions were resolved through the console.

At a modeled $33 loaded hour, 9.3 hours × 52 weeks is $15,959 a year of released capacity, not a payroll or cash saving. Against the $12,600 engagement, modeled payback is about 9.5 months. No revenue, retention, refund, chargeback or satisfaction effect is claimed.