Most AI proposals arrive with a demo and a number. The demo is impressive and the number is large. Neither tells you whether the project will survive contact with your operation.
There is a simpler test. Every process transformation worth funding should be able to say what it will do for four things: efficiency, cost, auditability and control. If a proposal is vague on any one of them, you have found the risk before you have paid for it.
Want to pressure-test this against your own process? A Process Assessment turns the idea into a mapped process, a baseline and a recommended first pilot.
Start with an assessment1. Efficiency — what gets faster, measured how?
Efficiency is the outcome most proposals lead with, and the one most often left unmeasured. "Faster" is not a result. "Cycle time from four days to one, measured on the same volume" is.
The question to ask: what is today’s baseline, and who captured it? If nobody has measured how long the process takes now, how many people touch it and how often it goes wrong, then nobody will be able to prove the improvement later. A credible proposal captures the baseline before anything is built.
A good answer sounds like: "Today, three people spend about two days on each batch. We will measure the same batch after the pilot."
2. Cost — is it a range your CFO can challenge?
The cost case should never be a single hero number. It should be a range built from assumptions your finance team can see and dispute: volume, minutes of manual handling, a fully loaded hourly rate, and the cost of delay and rework.
The question to ask: which costs are included, and which are not? Labor is the easy part. The larger costs usually sit elsewhere — shipments held for missing data, rework from overwritten records, penalties, or revenue lost because the operation could not execute on time. A proposal that ignores them undersells the opportunity; one that counts them without evidence oversells it.
A good answer sounds like: "Between X and Y a year, depending on these three assumptions — here is the model."
3. Auditability — could you reconstruct any decision?
This is where many AI projects quietly fail. The system works, but when someone asks who approved a payment, why a claim was rejected or which version of a document was used, nobody can say.
The question to ask: if an auditor picked one record at random six months from now, could we show who reviewed it, what they changed, what they approved and the original document it came from? If the answer is "the AI decided", you do not have an auditable process.
A good answer sounds like: "Every action is recorded against the user and the record, and the original document is attached."
4. Control — who decides, and what happens when the AI is unsure?
AI should prepare the decision. Your people should make it. Control is the design that makes that true: which fields a person must check, which decisions require an approval, what happens to low-confidence results, and who sees the exceptions.
The question to ask: show me, on paper, where a human is in the loop and what they see. If the vendor cannot draw it, the control does not exist yet.
A good answer sounds like: "Low-confidence fields are flagged for review, approvals are enforced by role, and exceptions go to a named owner every morning."
Putting it together
Score each outcome from zero to three. A proposal that scores well on efficiency and cost but poorly on auditability and control is a pilot that will stall when the risk owner reads it. One that scores well on all four is a project you can defend to your board.
If you want a quick read on where your own organization stands before you fund anything, the AI Readiness Assessment takes about three minutes and scores process, data, governance and people.
