Begin where preparation repeatedly gets in the way.
Look at work that requires somebody to read, search, reconcile or prepare information before another action can happen. Customer intake, proposal preparation, job handoffs and recurring operating reports can contain this kind of work.
These are candidates to examine. Their names do not establish that they should be automated. A proposal with reliable history and clear approval rules is a different problem from a proposal whose scope changes every time somebody speaks to the customer.
| Question | Why it matters |
|---|---|
| How often does it happen? | A recurring burden offers repeated opportunities to recover attention. Infrequent work may still matter when the consequence is substantial. |
| What is the current cost? | Count preparation, checking, waiting and rework. The most visible task may not be the constraint. |
| Can it get the information the task needs? | We need the relevant records, a way to tell which version is current and permission to use the information. |
| Can you define a good result? | You need an observable outcome and a person who can judge whether it is acceptable. |
| What happens when it is wrong? | We need checks and approval steps suited to the consequences, with someone responsible for an unusual or failed case. |
| Who will own it afterward? | Records, rules and models change. The workflow needs someone responsible for its continuing use. |
Which parts need AI, rules or a person?
A predictable calculation or a fixed handoff can often use conventional software and automation. Applying AI adds little when an explicit rule already solves the problem reliably.
AI may be useful when the work involves interpreting varied text, finding relevant context or preparing a draft. Its output still needs checks appropriate to the consequence. A person may approve a commitment, handle an unfamiliar exception or decide how competing priorities should be resolved.
One workflow can contain all of these. A signed agreement can trigger a rule-based handoff; AI can prepare a summary of unusual terms; a person can approve the obligations that affect delivery. See the architecture standard for how authority and completion are handled.
Count the work that remains.
Compare the current workflow with the full cost of operating the proposed one. Include review and correction, software subscriptions, maintenance and the time people need to learn the change. Account for the initial build separately so the ongoing benefit is visible.
A hypothetical example: fifty cases a month, with twelve minutes of preparation and review time released per case, would create ten hours of monthly capacity. If checking exceptions adds four hours elsewhere, the net capacity is six hours. Whether that time becomes savings or revenue depends on what the business does with it.
Ask what the business can actually do with the capacity. Can it handle another customer, shorten a meaningful delay or avoid a cost it would otherwise incur? If the answer is unclear, identify that as an assumption to test.
When should a workflow wait?
Defer the build if nobody can say which records are authoritative, the desired outcome is unresolved or there is no practical way to check the result. An unclear process can become harder to understand once software begins moving it faster.
Also pause when a plausible failure could create a commitment the business cannot tolerate. You may be able to redesign the workflow around a human approval step. That boundary belongs in the first design, along with a way to stop and recover.
Prove the change on representative work.
Choose examples of ordinary jobs and the unusual cases that matter. Measure the process before changing it, agree how to judge a good result and test the new version within a defined limit. Include the effort needed to keep using it.
The result may justify another change, a smaller build or stopping. I call the build-and-test work Prove because its job is to establish whether a change helps. The Read is the earlier paid assessment that recommends where to begin.
This is what I mean by closing the AI Gap: understanding the current process well enough to make a worthwhile improvement using software and AI.