Why the demo is the wrong starting point
Demonstrations show the best case. The input is clean, the task is typical and the person presenting knows exactly what to ask. Nobody shows the email with three attachments in different formats, the customer who writes in a dialect, or the week when the supplier changes its model.
That is not dishonest. It is simply not the decision in front of the board. The decision is whether a change in an ordinary, messy process creates enough value to justify cost, risk and management attention. A demo can support that case. It cannot replace it.
If the benefit can only be explained by showing the tool, it probably has not been understood yet.
Start with the task, not the technology
Ask management to describe the work as it is done today, before any AI is involved.
How often is it done? Volume per week or month, and whether it is stable or seasonal.
How long does it take? Observed time, not an estimate from the project team. Include rework.
What does it cost? Internal time, external spend, delays and errors that reach customers.
What quality is required? What counts as a good result, and who decides?
Without this baseline, any improvement claim is a guess. With it, the board can compare the proposal with doing nothing, improving the process without AI, or using software the organisation already has.
Count the whole new process
New tools often make one step faster and quietly add work elsewhere. The board should see the full process after the change, not only the part that is automated.
Preparation. Data has to be found, cleaned and kept current. Someone owns that.
Review. Output must be checked, at least at first. Review time is real time.
Exceptions. The cases the tool cannot handle still need people, often the most experienced ones.
Running costs. Licences, usage fees, integration, monitoring, training and a realistic exit.
Fictional example. A team handles 1,000 enquiries a month at 12 minutes each. With an AI draft, writing takes 7 minutes, but every draft is reviewed for 2 minutes. The net saving is 3 minutes per enquiry: 50 hours a month, not the 83 hours the demo suggested. The difference is not a failure. It is the decision.
Released time is not money in the bank
This is where many business cases quietly go wrong. Fifty hours of released capacity has a value, but it only becomes a saving if something actually changes: fewer temporary staff, less overtime, lower external spend. Otherwise the time is absorbed, often usefully, but differently from what the case promised.
Ask management to separate four kinds of value and report them separately:
Cash savings that will appear in the accounts, with a named owner and a date.
Capacity that will be redeployed, and to what.
Quality improvements, measured against the baseline.
New revenue, with the assumptions behind it made explicit.
Mixing them in one figure makes the case look stronger and the follow-up impossible.
What a good business case looks like
A strong proposal is usually shorter than a weak one. It states the problem, the baseline, the full new process, total costs over a defined period and the benefits as ranges, not single numbers. It names the person accountable for realising the benefit. And it includes criteria for stopping: what would have to be true, by when, for the organisation to pause or change course.
Warning signs are equally recognisable: a single impressive number, benefits described only as "efficiency", no baseline, no mention of review time, and no exit cost.
Three questions for your next meeting
- What is the baseline, and how was it measured?
- What does the whole process cost after the change, including review and exceptions?
- Who is accountable for turning released time into the value we are approving, and when will we see it?
None of these questions requires technical knowledge. All of them change the quality of the conversation.