Why good proposals get sent back
I have read maybe sixty of these, and the ones that fail rarely fail on the technology. They fail because they cannot answer three finance questions: compared to what, measured how, and what happens if it does not work. A proposal can be right about everything else and still be unfundable if those three are missing.
It also does not help that AI proposals arrive with an unusual amount of enthusiasm attached. A finance director who has approved four of these in eighteen months is not persuaded by the frontier; they are looking for the shape of an argument they recognise from every other investment on the list.
The baseline is the whole argument
If you cannot state what the current process costs, nothing downstream is credible. And the honest baseline is usually harder to get than the projection, because it means someone has to say out loud how long the existing workflow takes and how often it is redone.
Measure it before the build. Sample the work, time it, price it at loaded cost, and get the operations owner to agree the figure in writing. A baseline agreed after go-live is worthless — everyone involved now has an interest in its value, and any reviewer knows it.
A baseline established after the system is live is not evidence. It is a number produced by people who need it to look a certain way.
The four things finance is looking for
Structure the document around these and the conversation moves from whether to fund it to how much and when.
Include the stop condition, genuinely
This is the recommendation people resist most and it is the one that works. Writing down that you would stop if resolution rate stays below a stated figure after two quarters signals that the number will be honest. It converts the proposal from an ask into a controlled experiment with a budget.
One caveat from experience: only write a stop condition you would actually honour. A committee that discovers a breached threshold was quietly reinterpreted will apply that memory to every subsequent proposal from your team, and rightly.
Ask for the pilot and the decision gate, not the programme
Large multi-year AI programmes attract scrutiny in proportion to their size, and much of that scrutiny is warranted, because almost nobody can forecast month eighteen of one accurately. A smaller ask with a defined gate is easier to approve and easier to defend later.
The pattern that lands: fund the feasibility work and the first production slice, with a named decision point where the measured result determines scale-up. It costs less political capital, it produces real numbers instead of estimates, and it means the second conversation is about evidence rather than argument.
Ask for a gate, not a programme. The second conversation is then about measured results, which is a much easier meeting.
The one paragraph
Here is the baseline, measured this way, over this period. Here is what we expect to change and by how much. Here is how we will know we were wrong, and here is what we will stop doing if we are. A finance function will fund that paragraph long before it funds a capability narrative.
Work on the case with us