Order & delivery care
Resolve “where is my order?” before it becomes a ticket
Order status questions are the most predictable contacts you receive and the least valuable use of a support agent. Worse, they surge exactly when your team is already stretched. This blueprint resolves the routine order journey from live system data, handles approved changes and returns inside value thresholds, and pulls a person in when the money or the relationship warrants it.
- The team
- 3 AI worker roles escalating into 1 human decision owner.
- The process
- 6 orchestrated stages, each with a named decision owner.
- The channels
- Web chat, SMS, WhatsApp, Email, Voice on one shared context.
The shift
What breaks today, and what changes
The challenge
- Status and delivery questions crowd out the contacts where a human actually changes the outcome.
- Peak season volume arrives faster than seasonal hiring can absorb it, and quality drops as the queue grows.
- Customers repeat their order details on every channel switch because context does not travel with them.
What changes
- Routine order questions resolve in the conversation, using live order and carrier data rather than a static FAQ.
- Approved changes, returns, and reorders complete inside configured value thresholds without a queue.
- High-value orders, repeat contacts, and negative sentiment reach a person with the full history attached.
The team
Every seat has one job and a defined level of autonomy
This is what gets configured in Team Canvas: role-scoped AI workers, the humans they escalate into, and a trust level on each connection that sets what a worker may do on its own. Trust starts tight and widens on evidence.
AI workers
Order worker
Looks up live order and shipment state and explains the next real milestone.
- Owns
- Order visibility
- Trust level
- Acts within policy — read-only, after identity check
Resolution worker
Executes approved changes: address edits, returns, replacements, and reorders.
- Owns
- Routine resolution inside thresholds
- Trust level
- Acts within policy up to value threshold, then approval required
Exception worker
Detects lost, damaged, and stuck shipments and opens the right carrier or warehouse case.
- Owns
- Exception classification
- Trust level
- Acts with approval on anything with a cost attached
Human decision owners
Retention specialist
Takes high-value, repeat-contact, and unhappy customers with the full journey visible.
Owns: Goodwill and service recovery
The process
The conversation starts the work. The workflow finishes it.
Each stage records the decision that was made and the role accountable for it — which is what makes the run reviewable afterwards rather than a black box. Where the platform executes a stage rather than a person or agent performing it, that is named too, and accountability still sits with the role.
- 1
Recognise
Is identity confidence sufficient to expose this order?
Order worker
Run by integration
- 2
Read live state
Is this order on its normal journey, or is it an exception?
Order worker
- 3
Resolve
Is the requested action inside the configured value and policy threshold?
Resolution worker
- 4
Handle exception
Carrier case, warehouse case, replacement, or refund?
Exception worker
- 5
Recover
Does order value, sentiment, or contact history warrant a human now?
Retention specialist
- 6
Close the loop
Are the helpdesk, order system, and customer all updated and consistent?
Resolution worker
Run by workflow
Decision rules
The non-negotiables encoded in the workflow, not left to a prompt.
- Identity is verified before any order detail is disclosed, on every channel.
- Order status claims come only from live order and carrier data — never from an inferred estimate.
- Refunds, credits, and goodwill above the configured threshold require human approval before they are offered.
- Negative sentiment, third contact on one issue, or high order value routes to a person with the full history.
Controls & guardrails
What makes this safe to run in production, and provable afterwards.
- Identity checks before disclosure and value thresholds before action.
- Live system data as the only source for any status claim.
- Sentiment and repeat-contact triggers that force a human handoff.
- Auditable writeback so the helpdesk record matches the conversation.
Platform capabilities
What this blueprint runs on
Nothing here is bespoke. Each blueprint is a configuration of the same platform, which is why the second one you launch reuses the governance you already reviewed.
Channels
- Web chat
- SMS
- Voice
Systems it reads and writes
- Ecommerce & order platform
- Carrier tracking
- Helpdesk
- Payments & refunds
Measurement
What we instrument from day one
These are the measurements the pilot puts in place, not benchmark results. You set the targets against your own baseline — and the same instrumentation is what decides whether a worker's trust level widens.
- Containment rate
- Tracks the share of order contacts fully resolved in conversation, split by contact reason so you know what is actually being absorbed.
- Repeat-contact rate
- The honest counter-metric to containment: a contact that returns was not resolved, however it was closed.
- Threshold discipline
- Shows how many refunds and goodwill actions ran automatically versus went to approval, and whether the thresholds are set correctly.
Resolved without a human
Same issue, second touch
Approvals vs auto-actions
Rollout
How this one goes live
A deliberately narrow start, supervised, with autonomy widened per role once the record supports it.
Weeks 1–2
Status and tracking on one channel
Answer order status and delivery questions from live data on web chat. Read-only, so the grounding and identity checks are proven before anything writes.
Weeks 3–4
Approved actions inside thresholds
Enable address changes, returns, and reorders up to a deliberately low value threshold, with everything above it going to approval.
Week 5+
All channels, peak-ready
Extend across messaging, email, and voice with shared context, and raise thresholds where the audit record supports it before peak season.
Questions we get asked
Order & delivery care, in practice
- How do you stop the AI inventing a delivery date?
- Status claims are sourced from live order and carrier systems through the integration layer, and the workers have no authority to estimate. If the system of record has no date, the worker says what is actually known and, where useful, opens a carrier case rather than guessing.
- Can it issue refunds?
- Within thresholds you configure. Below the threshold the resolution worker completes the refund and writes it back; above it, the action requires human approval before it is offered to the customer. Every automatic and approved action is recorded with the reasoning.
- How does this handle peak season?
- Capacity is not staffed by headcount, so the same blueprint absorbs surge volume across every channel at once. Containment on routine order questions is what frees your team for the exceptions that actually need judgement during peak.
What changes in Retail & ecommerce
Peak volume is absorbed by containment on routine order questions, with refunds and goodwill gated by value thresholds.
Read the full Retail & ecommerce analysisRelated blueprints
Teams that run next to this one
Service & resolution
Resolve delivery exceptions before the customer starts chasing
Read the blueprintService & resolution
Keep customers informed through an outage without melting the queue
Read the blueprintService & resolution
Diagnose service issues before they become a cancellation
Read the blueprint
Next step
Build this team around one measurable win.
We map your version of this process, compose the worker roles, connect your systems, and agree the escalation points with the people who own them — then run it supervised.