Field Note · Apr 25, 2026
Before the AI project starts.
Know which ledger the project belongs on before anyone starts admiring the demo.
Most AI projects enter a company through the cost ledger. A team is moving data between systems. A manager waits for a report. A service group is buried in inbox work. A finance team pays for software because nobody has replaced the workflow underneath it.
The first question is simple: can this become cheaper?
A second question shows up once the work gets closer to the business: what becomes possible if this constraint goes away?
Two ledgers
Make the work cheaper.
The project removes hours, handoffs, rework, licenses, or waiting. The math starts with today’s cost.
Make the business better.
The project changes throughput, decision speed, capacity, or control. The math starts with the constraint.
The demo is the cheapest part.
A working prototype can be built quickly now. That has confused people. The hard part is the material around it: system access, historical data, edge cases, permissions, security review, user trust, adoption, and the question of whether the result is worth changing the workflow.
A prototype can look good against five examples. A production workflow has to survive the thousandth example, the weird customer, the missing field in the export, and the vendor API that technically exists because a contract said it had to.
This is why we ask for the ROI case early. The project should earn real time before the team starts polishing the demo.
The worksheet.
Calculators assume the variables are standard. They are not. A worksheet is a better tool. It helps decide whether the next step is build, discovery, sharper ROI work, or waiting.
- 01
Business constraint
What workflow is worth changing? Who owns it? Why now?
- 02
Current baseline
How does the work happen today: volume, time, people, waits, rework?
- 03
Economic case
Which KPI should move? What is the baseline? What would a meaningful change be worth?
- 04
Data map
Which systems create the work, store the data, and hold the source of truth?
- 05
Access reality
Can the team get exports, API access, credentials, approvals, or examples before build?
- 06
Expected output
What should the system produce? Where should it appear? What needs human review?
- 07
Operating owner
Who can approve process changes, test early output, and drive adoption?
- 08
Readiness call
Build, discover, sharpen the ROI case, or wait.
A good answer is small enough to act on.
One recent pattern was a team spending 60 to 80 hours a week inside shared inboxes. The obvious case was time savings. The better case was capacity: could the same team support more locations without hiring at the old ratio?
Another pattern was document intake in a regulated workflow. The value was faster cycle time, fewer errors, and more reliable throughput. Same worksheet. Different ledger.