Build the business case for an AI initiative.
Name one work area you are considering for AI, or have already bought a tool for. Answer what checks its output, what you own in the vendor contract, and what work would genuinely stop. You get back a one-page case you can take into a budget conversation.
It is built on the three questions that decide whether an AI initiative returns anything: whether the work is suited to AI at all, whether anything outside the model would catch it being wrong, and whether the value still holds once you count only the work that stops. Standard business-case templates ask for none of the three.
What you get back
The case for pursuing it
Whether this work is a fit for AI at all, and on what grounds.
What has to be true
The conditions the initiative depends on, stated so they can be checked.
What to insist on
The clauses and deliverables worth naming in the vendor contract.
What it's worth
A defensible range for the value, built only from work that stops.
Who it is for, and what it is not
It is written for the person who has to defend the spend: the executive sponsoring an AI initiative, sitting on a vendor proposal, or being asked by a CFO what last year's tool returned. It works before you buy and after.
It is not a maturity score, and it does not recommend a vendor. It also cannot check your answers, so the output is only as honest as the inputs. Where an answer is doubtful, say so in the tool and the case will mark it rather than quietly pricing it.
Estimates are fine throughout — the case reports ranges, not false precision, and marks anything you flag as uncertain. Nothing is sent to us until you submit your email on the final step.
What are you building the case for?
Pick one work area, not a department or a programme. The case gets sharper the narrower you go, and you can run the tool again for the next one.
This becomes the title of your case. Be specific enough that someone else in the building would recognize it on sight.
Transactions, documents, cases — whatever the countable unit is here. A round number is fine.
A few quick ones — these decide whether AI is even the right tool for this work, before anything gets priced.
Pick every one that's true here. The case at the end only shows what you select.
What this tool is, and what it tests.
What does this tool actually give me?
A one-page business case for a single AI work area, in four parts: whether the work suits AI at all, what has to be true for the initiative to pay off, what to insist on in the vendor contract, and a defensible value range built only from work that genuinely stops happening. It is written to be taken into a budget or board conversation, not to score your organisation.
How long does it take, and what do I need in front of me?
Ten to fifteen minutes, and nothing prepared. Rough numbers from memory are enough — the case reports ranges rather than false precision, and marks anything you tell it is uncertain instead of folding it into the total. There is no account, no data export, and no system access.
Do I need to have bought an AI tool already?
No. It works in both directions: before you buy, it tells you what to require of a vendor and whether the work suits AI at all; after you have bought, it tells you what the deployment is missing and whether the value you were promised was ever measurable. The questions about verification and contract ownership are the ones most useful before signing.
What happens to my answers and my email address?
Your answers are used to generate the case and send you a copy, and nothing else. The email is requested only at the final step, once the case has been built. We do not sell data, and nothing you enter trains any model. The full detail is in our privacy policy.
How do you check an AI initiative's output before trusting it?
With a check that fails differently than the model does. Asking the model if it's sure, or having a second model grade the first one's output, tests nothing — both share the same blind spot as the thing being checked. A real check is a deterministic recomputation, a fact the model didn't produce, or the same claim recovered a genuinely different way.
What should you own in an AI vendor contract?
The evaluation sets, labelled exceptions, and failure taxonomy your team generates during the engagement — named explicitly as your deliverables, not folded into generic "customer data" language. That's the artefact that's actually expensive to rebuild if you switch vendors. Also worth a direct answer from any vendor: name the data they have that you structurally cannot obtain yourself. If the answer is "we've learned from our customers," that's not a data asset, it's a description of what they're building out of your process.
How do you calculate ROI for an AI project honestly?
By counting what actually stopped happening, not what got faster. A step that runs quicker with a model attached and a step that gets deleted entirely produce the same demo and a completely different return. The honest number prices the deleted steps only, discounts the estimate because self-reported time typically runs high, and states plainly when the answer is zero rather than manufacturing one.
Is this AI initiative even the right problem for AI?
Only if there isn't one correct, computable answer sitting under it already. Work with a known formula, an optimization, or a physical control loop is a deterministic problem framed as an AI initiative — decades of control theory already solve it for less money and fewer surprises. AI earns its place on work that's genuinely judgment-based: extracting structure from messy documents, reasoning over incomplete information, work where there isn't only one right answer.