Escalation and Resolution

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

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.

After escalation and resolution:

Add proactive follow-up for backend-triggered updates.
Use the rollout plan before enabling high-impact write actions.

Overview

Use Case Blueprints

Escalation Flow

Escalation Triggers

Resolution Eligibility Workflow

Action Gates

Slack Review Request

Reviewer Decision Shape

Guardrails

Next Pages

​Escalation Flow

​Escalation Triggers

​Resolution Eligibility Workflow

​Action Gates

​Slack Review Request

​Reviewer Decision Shape

​Guardrails

​Next Pages

Escalation Flow

Escalation Triggers

Resolution Eligibility Workflow

Action Gates

Slack Review Request

Reviewer Decision Shape

Guardrails

Next Pages