01 · A request that repeats
Find several examples of the same need. “Refund a duplicate charge” is a useful starting point. “Handle everything” is not a flow.
Bring: anonymized examples, including an awkward one.
Before you automate
Start with one flow.Not a leap of faith.
You don't need a perfect help center or a large support team. You need a request worth repeating, a rule someone can approve, and a way to check whether the work got done.
A working checklist
Five things to bring.
02 · A rule with an owner
What is allowed? What are the exceptions? Who resolves a contradiction between the help center and what the team actually does?
Bring: the relevant policy and someone who can approve it.
03 · Information the agent can access
A refund policy is not a payment record. Identify where identity, charges, orders or account status can be checked.
Bring: the systems involved. No passwords or private customer data in a contact form.
04 · A bounded action
Agree exactly what can change, what needs approval and how success will be confirmed. Being able to read an order does not mean being allowed to edit it.
Bring: the action, its limits and the technical owner who can confirm access.
05 · A human handoff
Decide who gets the cases outside those limits, with what context. “Someone will look at it” needs a name.
Bring: the responsible team and the escalation rules.
Different starting points
Not ready for autonomy?There is useful work before that.
The rules and access are clear
Map the flow and run it in shadow mode. Review proposed actions before approving customer-facing work.
Quality is the first problem
Start with Scorecards for your existing conversations. Agree what good looks like before automating it.
The process is still tangled
Map the repeated requests, policy gaps and human decisions first. The notes are useful even if software isn't the answer.
If nearly every request needs a unique decision, start by helping the human team. An agent does not need to be the answer to every support problem.
What the website cannot tell us.
Public pages can explain what you sell and which policies you publish. They cannot reveal your actual ticket mix, account state, internal exceptions or permissions.
We work through those with you before a rollout. Timing depends on the flow and systems; approval follows reviewed results, not a fixed week on a sales slide.
Bring your version
Your rules. Your first flow.
Bring an anonymized ticket and the policy behind it. We'll work through the checks, access and handoffs with you.