Skip to main content
WISMO quality depends on the context Duckie has before it responds. The intake layer should create or update a stable WISMO case, identify the order, and build a canonical context object that downstream workflows and agents can trust.

Entry Points

Entry pointTypical triggerFirst action
Customer ticketNew ticket, public reply, or WISMO tagIdentify customer and likely order.
Chat messageAuthenticated chat or widget intentUse session identity and recent order data first.
Email replyCustomer replies to an existing threadReuse the existing WISMO case and order if possible.
OMS eventOrder status, hold, cancellation, or fulfillment changeFind existing case or create proactive monitoring state.
WMS eventPick, pack, short-pick, label, or handoff updateUpdate fulfillment state and decide whether a customer update is needed.
Supplier eventETA, allocation, stockout, or inbound receiving updateRoute to supplier backorder handling or proactive monitor.
Carrier eventScan, no movement, delivery attempt, return-to-sender, or delivered updateRoute to carrier handling or proactive monitor.
Scheduled sweepFollow-up due, stale tracking, or missed webhook checkRehydrate the WISMO case and compare current status to last update.

Intake Contract

Every WISMO run should produce a structured case object before it routes to a specialist:
FieldPurpose
wismo_case_idStable key for the customer/order issue.
source_channelTicket, chat, email, webhook, or scheduler.
customer_idCustomer identity from authenticated context, ticket metadata, or lookup.
order_idTarget order. Ask for this only when multiple orders are plausible.
shipment_idsShipment groups attached to the order.
ticket_idActive support conversation, if one exists.
prior_contact_countNumber of WISMO contacts for the same order.
last_customer_update_atMost recent public status message to the customer.
last_status_sentStatus facts already communicated.
next_follow_up_due_atPromised next checkpoint, if any.
restricted_stateFraud, payment, address, legal, VIP, high-value, or confidence guardrail flags.

Order Context Workflow

Build order context in a repeatable order. This keeps the downstream agents focused on interpretation instead of basic data plumbing.

Required Context

SourceMinimum fields
Customer profileCustomer ID, email, customer tier, contact preferences, risk-safe flags.
OMSOrder status, order date, promised ship date, promised delivery date, payment state, hold state, cancellation eligibility.
Order itemsSKU, quantity, item value, item status, shipment mapping, replacement/refund eligibility.
WMSPick status, pack status, short-pick status, label state, handoff confirmation, warehouse queue.
InventoryOn-hand, reserved, inbound, allocation state, approved substitute availability.
SupplierPurchase order, supplier ETA, allocation note, inbound receiving state, ETA confidence.
CarrierTracking number, carrier status, latest scan, exception reason, ETA, proof of delivery, investigation status.
Support historyPrior contacts, previous customer promises, internal notes, escalation status, open tickets.

When to Use an Investigation Agent

Call the order investigation agent when:
  • OMS says shipped but WMS has no handoff confirmation
  • Carrier tracking has a label but no first physical scan
  • Inventory shows stock but allocation failed
  • Supplier ETA and promised customer date conflict
  • Multiple shipments contain overlapping or missing items
  • The customer references an order that does not match account data
  • The support history contains a newer human update than backend data
The investigation agent should return:
  • Current best understanding of the order state
  • Conflicting facts, if any
  • Recommended WISMO condition
  • Customer-safe facts
  • Internal-only facts that must not be shown to the customer
  • Recommended next action and confidence

Guardrails

  • Do not ask for an order number if authenticated metadata identifies one clear order.
  • Do not expose fraud, payment-risk, supplier blame, margin, or internal allocation notes to customers.
  • Do not proceed to a customer-visible answer when customer identity is ambiguous.
  • Do not treat “label created” as carrier possession unless handoff or first scan is confirmed.
  • Do not overwrite a newer human reply with an older backend status.

Next Pages

After intake and context:
  1. Build condition routing and agents.
  2. Add proactive follow-up.
  3. Add escalation and resolution for guarded cases.