Choose assistance before autonomy
Start with tasks that help a teammate: find an order, suggest an article, summarize a conversation, or draft a reply. Define a correct result and what to do when sources conflict or are missing. Show the source and review status because a polished draft can still be wrong.
Keep disputed payments, policy exceptions, and complex complaints with people who can see the full context. Shopify discusses automation for routine questions, but each merchant must define current policy and out-of-scope cases.
The UK ICO says meaningful human review can matter when assessing whether a decision is solely automated under UK data protection rules. For decisions with significant effects, ask the responsible legal or privacy specialist to assess the design; a checkbox alone is not review.
Design a handoff a person can use
A handoff should include the question, verified record, information checked, suggested next step, and reason it stopped. State what is unknown and send the case to an owner and monitored destination.
Synthetic example: a fictional shop's assistant reads an order status and drafts a reply to 'Where is my parcel?' A teammate checks the record and sends it. If the parcel is marked delivered but missing, the assistant routes the case and does not claim recovery or promise a refund.
Set review by action. A help article may be shown with a route to a person; a generated reply may need approval; a change to an order, refund, address, or account needs a stronger approval and record. Apply the store's policy and relevant law.
- Name the low-risk tasks the system may assist with and the cases it must route.
- Show the source record and uncertainty beside each generated suggestion.
- Set a real queue, owner, and response expectation for handoffs.
- Keep approval for consequential actions and a way to correct mistakes.
Ground answers in approved information
Use a maintained knowledge source with an owner, review date, and policy version. Keep old promotions and drafts distinguishable from current policy. Retrieve facts such as inventory or shipment status from the system that owns them.
Limit access to needed data. Decide what conversation details may be sent or logged, who may review logs, and how long they are kept under your rules. Avoid payment credentials and unrelated personal details. Document the data flow and applicable privacy and security needs.
If no reliable source is found, ask for clarification or hand off. Show the teammate which record or policy supports a draft so they can verify it.
Measure review quality and customer impact
Test ordinary messages, complaints, ambiguous wording, multiple questions, missing order details, and requests to change records. Define safe results. Record whether reviewers accept, edit, reject, or escalate drafts, and look for policy or retrieval gaps.
Measure review time, handoffs, corrections, repeat contacts, and access to a person, not only automated response count. Review these measures with the support team; a high count alone does not show a customer was helped.
Give staff a pause control and manual route. Recheck after policy, product, integration, or customer-question changes. Let reviewers report a bad draft and its likely source.
- Test edge cases using examples approved by support and policy owners.
- Track edits, escalations, repeat contacts, and reviewer effort.
- Tell customers when a person is available and keep a manual fallback.
- Pause or narrow the system when it uses stale information or misses its boundary.
Expand only after review
Begin with suggestions and drafts. After the team confirms accuracy and useful handoffs, consider a limited automated response for a routine case using approved content and an escape route. Keep exceptions and consequential decisions with an accountable person unless another design has been assessed and approved.
Make the assistant's role and limits visible. A person remains responsible for the customer outcome and can correct the process.