Escalation Flow
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: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:- Add proactive follow-up for backend-triggered updates.
- Use the rollout plan before enabling high-impact write actions.