By John Wheeler | Wheeler Intelligent Systems
The conversation often starts with a tool.
“Could we use AI to handle this?”
“This takes too much time. Could an agent do it?”
“Can we connect AI to our business software?”
Those are fair questions. But before choosing a tool, we need to understand the work we want it to do.
What starts the process? What information does it need? Who touches it? Where do decisions happen? What happens when something goes wrong? Which system holds the official record? Who is responsible for the result?
If we cannot answer those questions, our AI project still has a basic design problem.
I recently shared this thought on X:
Before proposing an AI project, map the current workflow: trigger, inputs, handoffs, decisions, exceptions, system of record, and owner. Then mark where AI may observe, draft, recommend, or act. That artifact turns a vague technology discussion into an operating design.
That is a useful starting point for almost any business considering AI. It gives people something concrete to discuss, question, and test.
Follow one piece of work
You do not need to map the entire company before trying AI.
Choose one process with a clear beginning and end. Follow one piece of work through it.
An overdue invoice. A customer quote. A new product request. A purchase order that needs approval. A product specification sheet.
Start with something people do often enough to understand, but narrow enough to describe.
Instead of saying, “We want AI in accounting,” say, “We want to improve how we review overdue invoices and prepare the next step.”
Instead of saying, “We need AI for product information,” say, “We want to identify what is missing before preparing a draft product specification sheet.”
That smaller statement gives the project a boundary. Now we can ask what actually happens inside it.
Map the seven parts of the workflow
A useful workflow map can fit on a page. It does not need special software. A table, a shared document, or a whiteboard can work.
What matters is whether it describes the real process.
A. Trigger: What starts the work?
A trigger could be a customer email, an invoice passing its due date, a new item being created, or a weekly review.
Be specific. “Someone checks it sometimes” is a clue that the starting point needs more attention.
B. Inputs: What facts are needed?
List the information people use to complete the task. Note where those facts come from and whether they are current.
For an overdue invoice, the inputs might include the amount due, payment terms, recent payments, customer contact details, and notes about disputes.
Also ask what people know that the system does not. A promise made during a phone call may change the next step, even if it never reached the accounting record.
C. Handoffs: Who passes work to whom?
Follow each transfer between people, departments, and systems.
Does accounting send a spreadsheet to sales? Does sales return an email? Does someone then type the answer into another system?
A handoff can be quick and clear. It can also leave work waiting without anyone knowing who should move it forward.
D. Decisions: Where is judgment needed?
Separate routine steps from choices.
Pulling an aging report is a step. Deciding whether to contact a customer with a disputed balance is a decision.
Write down who makes that choice and what evidence they use.
E. Exceptions: What changes the normal path?
Ask people about the last few cases that did not follow the usual process.
A missing document. A partial payment. Conflicting product details. A customer dispute. An approval that never arrived.
Exceptions show where a simple-looking task becomes difficult. They also help define when AI should stop and ask for help.
F. System of record: Where does the official answer live?
The system of record is the place the business treats as authoritative for a particular fact.
The ERP may hold the invoice balance. A customer system may hold contact details. An approved document may hold a product claim.
Different facts may have different official sources. Make those sources clear so an AI draft does not quietly become the business record.
G. Owner: Who is responsible for the outcome?
Name a role that owns the process.
Several people may contribute, but someone needs to resolve stalled work, approve changes, and decide whether the process is performing well.
Adding AI does not remove that responsibility.
A fictional example: Reviewing overdue invoices
Consider a fictional distributor called Harbor Supply. This example uses entirely synthetic information.
Each Monday, an accounting employee downloads an aging report. The employee reviews overdue balances, checks recent payments, and asks sales about certain accounts. Then the employee prepares customer follow-up messages for review.
“Automate collections” sounds like a project. But it leaves many questions unanswered.
Here is a more useful starting map:
| Workflow part | Harbor Supply’s current process |
|---|---|
| Trigger | Monday review of invoices more than 15 days overdue |
| Inputs | Aging report, payment records, account terms, dispute notes, and customer contacts |
| Handoffs | Accounting asks sales about selected accounts; sales returns context |
| Decisions | Determine whether to follow up, investigate a dispute, or wait on a documented payment promise |
| Exceptions | Partial payments, missing contacts, disputed invoices, and conflicting account notes |
| System of record | ERP for balances and payments; customer system for contacts and account notes |
| Owner | Accounts receivable manager |
Now the team has something it can review.
It may discover that sales answers are stored only in email. Or that the aging report is several hours old when messages are drafted. Or that no one has defined how long to wait for an answer.
Those findings matter before AI enters the process.
Mark what AI may do
Once the current workflow is clear, add another layer: the role AI may play at each step.
Four levels make this discussion easier.
A. Observe
AI may read approved information and point out facts or gaps.
In the fictional example, it might flag invoices that meet the review rules or identify accounts with missing contact details.
Observation still needs clear data access and source rules.
B. Draft
AI may prepare something for a person to review.
It might draft an internal account summary or a customer follow-up message using verified information.
A draft should make uncertainty visible. If the payment status is unclear, the draft should flag that gap instead of inventing an answer.
C. Recommend
AI may suggest a next step and explain its basis.
It might recommend checking a dispute with sales before preparing a reminder. The reviewer should be able to see the supporting facts and understand what remains uncertain.
D. Act
AI may perform a defined action within approved limits.
For an initial trial, that could mean creating an internal review task. Sending a customer message would require a separate, explicit decision about authority.
Permission to draft a message does not imply permission to send it.
The same distinction applies to changing a record, approving a credit, or making a commitment on behalf of the company.
Give each step a clear boundary
Different steps can have different levels of AI authority.
In Harbor Supply’s proposed trial, the design might look like this:
| Step | Proposed AI role | Human responsibility |
|---|---|---|
| Review approved overdue-invoice data | Observe | Confirm the data source and review rules |
| Prepare an account summary | Draft | Check balances, context, and missing facts |
| Suggest follow-up or dispute review | Recommend | Choose the next step |
| Create an internal review task | Act within a defined limit | Review task accuracy and resolve exceptions |
| Send a customer message | Draft only | Approve and send the message |
This is a proposed operating design, not evidence that a working agent has passed a test.
That difference matters. A clear map helps define what to build. Testing tells us whether the result behaves as intended.
Test the ordinary case—and the awkward one
Before expanding authority, test more than the normal path.
Use a routine case with complete information. Then try a case with a missing fact, conflicting records, or an exception that should require review.
For the overdue-invoice example, a recent payment that has not reached the report is a useful test. So is a disputed invoice with incomplete notes.
Does the AI identify the uncertainty? Does it pause at the right point? Can the reviewer see why it suggested a next step?
Also measure the work left for people. A draft produced in seconds may still take several minutes to check and repair.
Useful measures include completion time, correction rate, unresolved exceptions, and reviewer effort. Start with a small baseline so the trial has something meaningful to compare against.
Keep the map close to the work
A workflow map should help the people doing the job.
Review it with them. Ask where it is wrong. Walk through a recent case together.
If the documented process says one thing and daily practice says another, understand the difference before designing around either one.
As the trial changes, update the map. Record which tasks AI handles, which still require judgment, and who owns unresolved cases.
This makes the map useful beyond the first project meeting. It becomes a shared reference for the builder, the operator, and the person reviewing results.
Start with a page you can discuss
For manufacturers, distributors, and other established businesses, a useful first step is to choose one recurring task and map it.
Write down the trigger, inputs, handoffs, decisions, exceptions, official sources, and owner. Then mark where AI may observe, draft, recommend, or act.
You may find a sensible AI project. You may also find a missing rule, a weak handoff, or information that needs to be captured first.
Either result moves the discussion forward.
At Wheeler Intelligent Systems, this is the kind of practical AI work I want to explore: understanding the job, designing clear limits, and testing whether the result helps the business.
If you are a manufacturer or distributor considering AI, I would welcome a conversation about one workflow that causes repeated delays, rework, or uncertainty.
Bring the problem. We can start by mapping the work.