> ## Documentation Index
> Fetch the complete documentation index at: https://docs.duckie.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> A blueprint for automating WISMO order-status operations with Duckie

This blueprint shows how to design a Duckie system for WISMO ("Where Is My Order?") operations in e-commerce. The example is a retailer that sells high-value computer parts, but the same pattern works for any order-status operation with OMS, warehouse, supplier, carrier, and support-history data.

The recommended design uses deterministic workflows for the repeatable control points and autonomous specialist agents for ambiguous investigation, customer-safe explanation, and internal decision support.

## Start With the MVP

You do not need to launch the full WISMO system at once. Start with a narrow loop that identifies the customer and order, pulls live order context, detects the most common WISMO condition, answers allowed status questions, and schedules a proactive follow-up when the status may change.

Then add supplier backorders, warehouse exceptions, carrier investigations, delivered-not-received review, replacement/refund approval, and broader proactive event handling after the first loop is trusted.

<Tip>
  Use the [MVP](/examples/wismo-order-status/mvp) as the starting point if you are building this blueprint for the first time.
</Tip>

## What This System Does

The system helps a CX and operations team:

* Receive WISMO questions from chat, email, ticketing, or backend events
* Identify the customer, order, shipment, and active support case
* Pull live OMS, WMS, supplier, inventory, carrier, and support-history context
* Route the same customer intent to the right specialist handler based on actual order state
* Send factual customer replies without generic status copy or unsupported ETA promises
* Proactively update customers when backend tracking, fulfillment, or supplier status changes
* Escalate high-value, repeated-contact, fraud/address-hold, or ambiguous cases to the right internal team
* Gate replacement, refund, cancellation, and address-change actions behind policy and approval
* Track conditions, outcomes, follow-up commitments, and automation quality

<Info>
  WISMO is not primarily an order lookup problem. The hard part is deciding what to say and do when the order state is stale, blocked, split across systems, or operationally ambiguous.
</Info>

## Design at a Glance

| Function                  | Duckie component                                                                                 | Why                                                                                                                        |
| ------------------------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------- |
| Customer and event intake | Deployments plus WISMO intake workflow or triage agent                                           | WISMO can start from tickets, chat, email replies, carrier events, supplier updates, or scheduled checks.                  |
| Order context             | Order context workflow                                                                           | Canonical OMS, WMS, supplier, inventory, carrier, hold, and support-history fields should be pulled in a repeatable order. |
| Ambiguous investigation   | Order investigation agent                                                                        | Conflicting or incomplete system data needs flexible tool choice and summarization.                                        |
| Condition routing         | Condition routing workflow                                                                       | Clear status rules, approval thresholds, and follow-up commitments should be auditable.                                    |
| Specialist handling       | Standard status, supplier, warehouse, split shipment, carrier, and delivered-not-received agents | The expensive variation belongs in agent instructions, runbooks, knowledge, and guardrails.                                |
| Proactive follow-up       | Proactive monitor workflow plus customer communications agent                                    | Backend changes should trigger customer updates before another ticket is opened.                                           |
| Resolution and approval   | Resolution eligibility workflow plus Slack escalation agent                                      | Replacement, refund, cancellation, and address-change decisions need controlled gates.                                     |
| Analytics                 | Categories, attributes, resolution rules, and run review                                         | Teams need to see which WISMO conditions are resolved, monitored, escalated, or blocked.                                   |

## Blueprint Pages

<CardGroup cols={2}>
  <Card title="MVP" icon="list-check" href="/examples/wismo-order-status/mvp">
    Start with the smallest useful WISMO loop before adding all exception handling.
  </Card>

  <Card title="System Map" icon="diagram-project" href="/examples/wismo-order-status/system-map">
    See the workflow backbone, specialist agents, proactive follow-up, and human review path.
  </Card>

  <Card title="Intake and Order Context" icon="inbox" href="/examples/wismo-order-status/intake-and-order-context">
    Normalize customer requests and backend events into a consistent WISMO case.
  </Card>

  <Card title="Condition Routing and Agents" icon="route" href="/examples/wismo-order-status/condition-routing-and-agents">
    Route order states to the right specialist agent or controlled workflow.
  </Card>

  <Card title="Proactive Follow-Up" icon="bell" href="/examples/wismo-order-status/proactive-follow-up">
    Send updates when backend tracking, supplier, warehouse, or shipment status changes.
  </Card>

  <Card title="Escalation and Resolution" icon="slack" href="/examples/wismo-order-status/escalation-and-resolution">
    Route human decisions and approval-gated actions through a structured internal loop.
  </Card>

  <Card title="Rollout Plan" icon="rocket" href="/examples/wismo-order-status/rollout-plan">
    Move from shadow-mode WISMO handling to broader live proactive operations.
  </Card>
</CardGroup>

## Recommended Reading Order

1. Start with the [MVP](/examples/wismo-order-status/mvp) to understand the smallest useful version.
2. Read the [system map](/examples/wismo-order-status/system-map) to see how the components connect.
3. Read [intake and order context](/examples/wismo-order-status/intake-and-order-context) to understand the data contract.
4. Read [condition routing and agents](/examples/wismo-order-status/condition-routing-and-agents) to map order states to handlers.
5. Add [proactive follow-up](/examples/wismo-order-status/proactive-follow-up) once backend events are reliable.
6. Add [escalation and resolution](/examples/wismo-order-status/escalation-and-resolution) before enabling high-impact actions.
7. Follow the [rollout plan](/examples/wismo-order-status/rollout-plan) before expanding live traffic.

## Related Docs

<CardGroup cols={2}>
  <Card title="Designing Agent Systems" icon="diagram-project" href="/examples/designing-agent-systems">
    Learn the general workflow-plus-agent design pattern.
  </Card>

  <Card title="Choosing an Agent Architecture" icon="sitemap" href="/concepts/choosing-an-agent-architecture">
    Decide when to use workflows, agents, runbooks, and human review.
  </Card>

  <Card title="Deployments" icon="rocket" href="/deployments/overview">
    Connect Duckie to ticketing, messaging, webhook, and scheduled triggers.
  </Card>

  <Card title="Replay Testing" icon="clock-rotate-left" href="/testing/replay-testing">
    Test historical WISMO tickets before live customer replies.
  </Card>
</CardGroup>