01 / 04
Follow the work, not the pitch
A team says it wants an AI assistant. That sounds like a starting point, but it is already a proposed solution. The useful questions come earlier: Which task is slow? Who does it? What information do they need? Where do mistakes show up, and who catches them?
Watch a few real cases travel from request to resolution. The detours matter: the spreadsheet someone keeps on their desktop, the approval that happens in a chat thread, the exception that gets quietly passed to the most experienced person on the team. Those details are often where the opportunity sits.
02 / 04
Write down a baseline
Before building anything, measure the current process in terms the people doing it recognise. Time per case is useful, but it is not enough. Record rework, handoffs, escalation frequency, and the kinds of errors that cause real harm.
A baseline keeps the project honest. If a new system saves two minutes on the easy cases but creates twenty minutes of review on the hard ones, it has not improved the workflow. The numbers should make that visible before rollout, not after.
03 / 04
Choose the smallest useful intervention
Sometimes the answer is a searchable knowledge base. Sometimes it is a rules engine, a better form, or a tighter handoff between existing systems. A model earns its place when the work genuinely needs interpretation, judgement under uncertainty, or flexible language.
Start with one narrow slice that can be tested on real examples. Agree what the system can decide, what it may suggest, and what must go to a person. Expansion is easier when the first slice has proven its value and its failure modes are understood.
04 / 04
A useful first workshop
Bring the operator, their manager, and someone who owns the underlying systems into the same room. Walk through five recent cases: two routine, two awkward, and one that went wrong. Map each decision and the information it required. Leave with a candidate workflow, a baseline, and a list of things the first version must never do.