Order Exception Resolution

Detect order exceptions (failed payments, stuck fulfillment, shipping mismatches, inventory shortfalls) and resolve them with templated customer communications, escalating any refund or price change above the org's threshold for human approval.

When to use

• An order is stuck in a failed, delayed, backordered, or payment-declined state and needs diagnosis and a customer-facing response.
• A customer reports a shipping mismatch, missing item, or damaged delivery tied to a specific order.
• Recurring exception sweeps are needed to catch orders stalled beyond a normal processing window.
• A resolution requires a refund, credit, or price adjustment that may exceed the org's configured threshold.

Tools

• http-get
• http-post
• send-email
• create-task

Playbook

1. Pull the order record and its current status with http-get against the order management API (e.g. GET https://api.example.com/v1/orders/{order_id}). Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
2. Cross-check payment status with the payment provider using http-get (e.g. GET https://api.example.com/v1/payments/{payment_id}) and inventory/fulfillment status with http-get against the warehouse or 3PL (third-party logistics) API (e.g. GET https://api.example.com/v1/shipments/{order_id}).
3. Classify the exception type (payment failure, stock shortfall, shipping delay, damaged/wrong item) from the combined data before choosing a resolution path.
4. For resolutions within the org's threshold (e.g. reship, restock, minor discount, address correction), submit the fix via http-post to the relevant endpoint (e.g. POST https://api.example.com/v1/orders/{order_id}/reship).
5. If the resolution requires a refund, price change, or catalog write above the org-set threshold, do not execute it. Instead, open an approval request with create-task describing the order, proposed amount, and reason, and wait for a human to approve before any http-post write is made.
6. Send the customer a templated update with send-email explaining the issue, the resolution (or that it is pending approval), and expected timing.
7. If the order management or payment API returns 401/403 or no Integration is configured for that host, stop and message a human via send-message naming the service and scopes needed.
8. Log the exception outcome by updating the order record with http-post (e.g. POST https://api.example.com/v1/orders/{order_id}/notes) once resolved or once the approval task is filed.
9. If the needed action is an update or deletion (PUT/PATCH/DELETE) rather than a create, use http-request instead of http-post — if no suitable endpoint exists, route to a human handoff via create-task.

Failure modes

• Treating a payment-processing delay as a stock issue (or vice versa) leads to the wrong customer message and wasted resolution steps — always confirm exception type against both payment and fulfillment data before acting.
• Auto-approving a refund or price change that sits right at or above the threshold breaches the compliance gate — when in doubt, route to create-task rather than assume it's under the limit.
• Sending a customer template before the underlying fix is confirmed can create false expectations — only send-email once the resolution path (auto-fixed or pending approval) is certain.
• Retrying http-post writes after a 401/403 without checking the Integration row can trigger duplicate reship or refund attempts — stop and escalate instead of retrying blindly.

Done when

• The exception is classified, the resolution is either applied (within threshold) or filed as a human-gated approval task (above threshold), and the customer has received a send-email update.
• Any refund, price change, or catalog write above the org's threshold has a corresponding create-task awaiting or reflecting human sign-off before execution.
• The order record reflects the final resolution status for downstream reporting.