Order enquiry automation: an illustrative workflow

The problem and current manual process

A customer asks about a split shipment on WhatsApp. Support finds one tracking number in the store, another in a warehouse email and a return request in yesterday's inbox. A generic "shipped" reply creates another complaint.

Who should use this approach?

Retail operations and support teams that can access order, fulfilment and carrier records through supported integrations.

When it is not a good fit

A shop with very few enquiries may need a shared inbox and clearer tracking links first. Do not automate status replies if the source system cannot distinguish partial shipments or support identity checks.

Proposed workflow

Systems involved: Online store, carrier feed, helpdesk, WhatsApp Business.

1. Match the enquiry to a verified customer and order; retrieve line items, partial fulfilments and the latest carrier event.
2. Answer routine status questions from that record. Open a case for stalled parcels, missing items or conflicting delivery information.
3. Attach the conversation and evidence to the case, assign an owner and update the customer when the status changes.

Synthetic example: order DEMO-104 contains two items. One carrier reports delivery; the second shipment has only a label. The proposed reply describes both items separately and opens a follow-up for the uncollected parcel. It must not report the whole order as delivered.

Where AI is useful

AI can suggest an enquiry category and draft a concise explanation from the retrieved order facts. Give it only the verified customer’s records. The draft must preserve distinctions such as “label created”, “in transit” and “delivered”; uncertain evidence belongs in a review queue.

Where deterministic rules are better

Use rules for customer authorisation, order matching, shipment freshness, duplicate message IDs and case ownership. Refund eligibility, address changes and payment actions are not permissions the model can infer from a message.

States and human approval

1. Received: record a unique message ID and channel account.
2. Verified: establish which order records the requester may access.
3. Prepared: collect item-level fulfilment and timestamped tracking evidence.
4. Review required: hold contradictions, stale information and consequential requests.
5. Resolved or assigned: record the response or accountable case owner.

Refunds, address changes and disputed deliveries need approval. If tracking is stale or identity cannot be verified, route to a person instead of guessing.

Failure modes and recovery

Repeated webhook

Claim a unique event/action key before writing; repeated deliveries resolve to the same case.

Carrier API unavailable

Display the timestamp of the last known update and assign an exception. Do not turn a timeout into “not shipped”.

Reply timeout

Mark the send as uncertain and check the provider record before retrying.

Customer requests a refund

Suspend routine status replies and hand the source evidence to an authorised employee.

Security and privacy boundaries

Keep addresses and order details behind the identity check. Store message and order references rather than full customer records in broad staff channels. Agree who can inspect transcripts, which model provider may receive them and how long copies and logs remain.

What a pilot should prove

• A repeated inbound event creates one intended case.
• A partial shipment produces an item-level answer.
• An unverified requester receives no order details.
• A staff takeover prevents delayed AI drafts from being sent.
• A carrier outage produces an owned exception with source timestamps.

Intended operational effect

Customers get a useful next step. Agents spend their time resolving exceptions instead of reconstructing orders.

Measure a representative baseline, then compare the same scope during the pilot. Include review, exception handling and maintenance effort. Proposed measures: handling time per enquiry; repeat contacts per order; age of unresolved delivery cases.