ARTICLES · Operations

    Closing Fulfillment Exceptions When Carriers Fail: An AI Playbook

    4 min read

    Closing Fulfillment Exceptions When Carriers Fail: An AI Playbook

    Most e-commerce orders ship without incident. The 5–15% that don't — the lost packages, the address corrections, the carrier delays, the damaged-on-arrival claims — consume a disproportionate share of ops-team hours. This playbook walks through how Wisnots's agents close the long tail of fulfillment exceptions: the carrier ecosystem, the OMS connection, the decision tree, and how customer-facing communications stay on-brand.

    The fulfillment-exception problem

    A retailer doing 100,000 orders a month with a 7% exception rate has 7,000 exceptions a month — most repetitive (address typos, carrier exceptions, partial damage), some genuinely complex (multi-leg returns, fraud holds, carrier-loss arbitration). Each exception carries customer-comms work: notify the customer, set expectations, refund or reship, follow up.

    Doing all of that manually means a team that scales with order volume. Doing it with an AI agent that's integrated with the OMS, the WMS, and the carrier APIs means the team scales with exception complexity instead.

    The carrier ecosystem

    Wisnots integrates with the carrier APIs your team already uses: DHL, UPS, FedEx, regional couriers (DPD, Hermes, GLS, Royal Mail, etc.). Each carrier exposes:

    • Tracking events (out for delivery, exception, delivered, returned).
    • Exception reasons (failed delivery attempt, address invalid, refused).
    • Claim filing endpoints (for lost or damaged packages).
    • ETA recalculations after exceptions.

    The agent reads tracking events as they happen, classifies the exception, decides next-step (notify customer, file claim, reship, refund), and either acts autonomously (within the rules you set) or drafts the action for a human supervisor.

    The OMS + WMS connection

    Fulfillment exceptions don't exist in isolation. The agent needs to know:

    • What the order is (line items, value, ship-to address, ship-from warehouse).
    • Inventory state (can we reship from the original warehouse, or do we need a different one?).
    • Customer profile (first-time buyer? high-value? VIP?).
    • Order-level rules (gift orders, subscription orders, B2B orders all have different paths).

    Wisnots integrates with Shopify, commercetools, custom OMS systems, and standalone WMS connectors. The agent reads from all of them before deciding.

    The decision tree

    For most fulfillment exceptions, the path is:

    1. Identify: classify the exception type (address fail, lost, damaged, delayed).
    2. Look up context: order, customer, inventory, carrier.
    3. Check policy: what does the rule set say for this exception type, this customer segment, this order value?
    4. Draft action: address fix, replace, refund, escalate, file claim — with the right customer comms.
    5. Approve or auto-fire: depending on shadow vs autonomous mode + the confidence threshold + the rule set.
    6. Confirm closure: track the customer's response (was the issue resolved? did they contact again?). The case stays in "follow-up" until the SLA window passes without a reopen.

    Customer comms: matching your tone

    Customer-facing copy is generated from your historical comms — we learn how your team apologizes, refunds, reships, and escalates. We don't invent a tone; we match yours. For carrier-driven delays we draft proactive comms with the actual carrier ETA, not a generic "we're looking into it" placeholder.

    The DE/FR/ES/PT/IT comms work the same way: native phrasing learned from your historical multilingual comms, not on-the-fly translation.

    5–15%
    of orders trigger fulfillment exceptions
    industry average

    SLA + supervisor escalation

    SLA timers start where they start in your runbook. The agent prioritizes work closest to breach, escalates to a human supervisor BEFORE breach (not after), and never silently exceeds an SLA.

    For regulated content (consumer protection, mandatory notices), escalation always goes to a human. The agent drafts the templated copy; a human approves before customer-facing send.

    Pricing: pay per closed case

    Pricing follows the closure: pay per closed case. A case counts as closed when it stays closed for the agreed window (typically 14 days, longer for regulated workflows). If the case reopens within the window, we don't charge.

    Operations
    Back-office and operational tickets — fulfillment exceptions, contract changes, internal requests — closed end-to-end.
    See operations

    In-article FAQ