> ## 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.

# Escalation and Resolution

> Route WISMO exceptions, approvals, and high-impact actions through a structured human loop

Escalation should be a structured decision path, not a loose side conversation. Every escalation should include a case ID, order facts, detected condition, customer impact, requested decision, options, deadline, and return path.

## Escalation Flow

```mermaid theme={null}
sequenceDiagram
  participant Origin as Origin WISMO run
  participant Bridge as Escalation bridge tool
  participant Slack as Review Slack thread
  participant Reviewer as CX, shipping, supply-chain, or fraud reviewer
  participant Agent as Slack escalation agent
  participant Case as WISMO case

  Origin->>Bridge: create_escalation(case_id, question, options, deadline)
  Bridge->>Slack: post review thread with order and shipment context
  Reviewer->>Slack: reply with decision or missing info
  Slack->>Agent: thread reply triggers run
  Agent->>Bridge: record_escalation_answer(case_id, decision, rationale)
  Bridge->>Case: add internal note and update saved values
  Bridge-->>Origin: structured answer available
  Origin->>Origin: continue workflow with reviewer decision
```

## Escalation Triggers

| Trigger                                                            | Why it escalates                                                             |
| ------------------------------------------------------------------ | ---------------------------------------------------------------------------- |
| Customer contacted about the same order 2+ times                   | Repeated contact indicates stale or unsatisfying prior updates.              |
| Order value exceeds action threshold                               | Replacement, refund, and reship decisions affect money and inventory.        |
| Supplier has no ETA for a build-critical component                 | The customer needs a judgment-based choice, not a generic delay response.    |
| Alternate component may be needed                                  | Compatibility, price, and inventory rules may require human approval.        |
| Carrier says delivered, but customer disputes receipt              | Delivery proof, risk signals, and policy thresholds matter.                  |
| Fraud, payment, or address hold exists                             | Customer-facing language and next steps must be restricted.                  |
| Customer threatens chargeback, legal action, or manager escalation | Risk and relationship handling need a human owner.                           |
| Backend data conflicts across systems                              | Duckie should not choose a customer-visible answer from contradictory facts. |

## Resolution Eligibility Workflow

Use a workflow for deterministic action gates:

```mermaid theme={null}
flowchart TD
  Start["Recommended action from specialist agent"]
  Type{"Action type"}
  Replacement["Check replacement eligibility"]
  Refund["Check refund eligibility"]
  Cancel["Check cancellation eligibility"]
  Address["Check address-change eligibility"]
  Threshold{"Approval required?"}
  Draft["Create draft action and customer message"]
  Approval["Ask human reviewer"]
  Execute["Execute approved action"]
  Deny["Record denial and next safe option"]
  Notify["Customer communications agent"]

  Start --> Type
  Type -->|Replacement| Replacement --> Threshold
  Type -->|Refund| Refund --> Threshold
  Type -->|Cancellation| Cancel --> Threshold
  Type -->|Address change| Address --> Threshold
  Threshold -->|No| Draft --> Execute --> Notify
  Threshold -->|Yes| Approval
  Approval -->|Approved| Execute --> Notify
  Approval -->|Denied or changed| Deny --> Notify
```

## Action Gates

| Action                | Gate before execution                                                                                      |
| --------------------- | ---------------------------------------------------------------------------------------------------------- |
| Replacement order     | Inventory availability, order value, customer history, item class, delivery proof, and approval threshold. |
| Refund                | Refund eligibility, payment state, delivery state, return state, amount threshold, and approval threshold. |
| Cancellation          | Fulfillment stage, carrier handoff status, policy eligibility, and refund timing.                          |
| Address correction    | Identity verification, shipment stage, carrier support, fraud/address-hold state, and policy approval.     |
| Alternate item        | Compatibility, price difference, stock status, approved substitute list, and customer consent.             |
| Carrier investigation | Carrier status, time since last scan, route threshold, and duplicate claim check.                          |

## Slack Review Request

Each Slack review thread should include:

* Case ID and Duckie run link
* Customer and order identifiers
* Order value band and relevant threshold
* Detected WISMO condition
* Current OMS, WMS, supplier, carrier, and support-history facts
* Prior customer updates and promised follow-ups
* Recommended action
* Allowed reviewer options
* Deadline for decision

## Reviewer Decision Shape

The Slack escalation agent should return a structured decision:

| Field                   | Example                                                                    |
| ----------------------- | -------------------------------------------------------------------------- |
| `decision`              | approve, deny, request\_changes, manual\_takeover                          |
| `approved_action`       | replacement, refund, cancel, address\_change, carrier\_investigation, wait |
| `rationale`             | Short internal explanation.                                                |
| `customer_safe_message` | Optional wording or facts that can be shared.                              |
| `owner`                 | Reviewer or queue responsible for next step.                               |
| `deadline`              | When the next action or follow-up is due.                                  |

## Guardrails

* Never approve replacement or refund actions above threshold without human approval.
* Never expose fraud scores, payment-risk signals, supplier blame, margin, or internal allocation notes.
* Never update an address after shipment without required verification and policy approval.
* Escalate delivered-not-received cases when proof of delivery is ambiguous or value exceeds threshold.
* Escalate repeated contacts, angry customers, legal threats, chargeback threats, and data conflicts.

## Next Pages

After escalation and resolution:

1. Add [proactive follow-up](/examples/wismo-order-status/proactive-follow-up) for backend-triggered updates.
2. Use the [rollout plan](/examples/wismo-order-status/rollout-plan) before enabling high-impact write actions.