AI Support Workflow Exercise
I used a fictional company, Meridian, to work through a practical product question: if a support team wants AI help, where should AI actually participate, what should software enforce, and when should a person take over? The useful result was not the fictional pilot plan. It was seeing how quickly the workflow changed once discovery challenged the original assumptions.
In shortWorking through a fictional support team showed how quickly the AI boundaries, software rules and human handoffs changed once discovery challenged the first design.
I chose the scope, wrote the discovery questions, made the boundary and handoff decisions, and decided which simulated findings were strong enough to change the design. Claude helped generate early simulated stakeholder material and rendered the workflow from rules I specified. The company, interviews, and operating numbers are simulated; the product decisions and reasoning are mine.
What discovery changed
I started with a fairly generic idea: let AI draft support responses so reps can answer faster. The questions below changed the product more than prompt tuning would have.
Support workflow and AI boundaries
The resulting design is deliberately bounded. AI helps with interpretation and drafting only where being probabilistic is useful. Software owns the hard stops. People remain responsible for anything consequential and for every message that reaches a customer.
Classify standard tickets, retrieve relevant context, draft a response, and surface uncertainty.
Block high-risk categories from drafting and enforce explicit escalation conditions.
Approve or rewrite responses, handle high-risk work, and take over when a conversation escalates.
How the design changed
| Early assumption | After discovery |
|---|---|
| AI could draft nearly every support ticket for review. | Money, security, and account-access categories bypass drafting entirely. |
| Faster first response depended on a common “quick acknowledgment” workflow. | That workflow appeared uncommon, so expected gains became more modest and were not tied to it. |
| Billing context required a new AI-facing integration. | The data already existed. A view/configuration change solved the need more directly. |
| Bad AI answers would mainly be model-quality failures. | Stale or conflicting source material needed to be tracked as a separate failure class. |
| Success could be summarized with aggressive speed targets. | Mandatory human review limits the plausible efficiency gain. Quality, boundary adherence, and root cause matter separately. |
What I would measure in a real pilot
I would not carry the exercise's fictional target numbers forward. In a real team I would establish baselines first, then track response and handling time alongside draft acceptance/editing, escalation reasons, knowledge-source failures, boundary violations, and customer outcomes. A faster workflow would not count as a success if reps spend the saved time correcting bad drafts or if risky categories leak through the boundary.
What I took from the exercise: an AI workflow can change substantially before model selection or prompting becomes the important question. Several things that initially looked like AI problems turned out to be workflow, access, source-quality, or policy problems. Discovery is what exposed the difference. The limitation is equally important: simulated stakeholders can sharpen reasoning, but they cannot substitute for watching real people do the work.