Why this session exists
You have picked use-cases (a2), set the guardrails (a3), and thought about the team (a4). Now comes the question that unlocks budget or kills it: what is the return, and can you defend the number? The uncomfortable truth is that most AI value is claimed loosely and measured badly - which is exactly why finance leaders, of all people, should hold it to a higher standard. This session hands you an honest scorecard and a one-page business case, so your bet is credible in the room where money is decided.
Measuring value honestly 6 min live
There are real value levers, and there is theatre. The real levers are measurable and modest at first; the theatre is a headcount-reduction slide that never survives contact with reality. As a finance leader your credibility rests on counting only what you can defend, so let us name the levers that hold up.
LiveThe value levers that actually hold up3 min▶
Every credible AI return in finance traces back to one of a small set of levers. Learn to name them, and you can measure any use-case honestly.
- Time saved. Hours pulled out of recurring, low-judgement work - reconciliations, first-draft commentary, data cleanup. Count it as hours, then convert to cost cautiously.
- Cycle-time. How much faster something finishes - a close cut from ten days to eight, a board pack drafted in a morning not a week. Speed has real value even when hours are flat.
- Error and rework reduction. Fewer restatements, fewer missed accruals, more anomalies caught before they matter. Quality is money you never lose.
- Capacity redeployed. The honest version of "efficiency": the same people spend freed hours on analysis, business partnering, and judgement. This is the lever that survives scrutiny - a promise to cut heads usually does not.
LiveThe counterweight - why most pilots miss the P&L2 min▶
You should walk in clear-eyed. Independent evidence keeps finding that a large share of generative-AI pilots show no measurable P&L impact, and analysts expect a meaningful fraction of ambitious "agentic" projects to be scrapped before they scale. That is not a reason to avoid the bet - it is a map of the potholes.
- No baseline. The value was never measured before, so the "after" is a story, not a number. Fixable, and the reason Part 1 opens with the baseline rule.
- No adoption. The tool works in a demo and dies in the workflow, because no one changed how the team actually does the task. Value lives in adoption, not in the license.
- Wrong use-case. The pilot chased something flashy instead of something painful, high-volume, and low-risk. Your a2 scoring exists to stop exactly this.
The pilot that "worked" and delivered nothing. A team ran a slick forecasting-assistant pilot, declared success, and moved on. A year later the forecast still took the same number of days - because the tool never entered the monthly routine and no one had recorded the original cycle time to compare. The lesson: a demo is not a deployment, and a number you cannot compare is not a return.
Pilot to scale, and buy vs build 6 min live
Two decisions sit under every business case. First, how to run the pilot so it can prove something. Second, how to source the capability - do you buy a tool, build your own, or blend copilots into what you have? Get these right and scaling is a formality; get them wrong and you fund a demo.
LiveA pilot that can actually prove value3 min▶
A good pilot is small, measurable, and time-boxed - designed from day one to produce a decision, not just an experience.
- One measurable use-case. Pick a painful, high-volume, low-risk task from your a2 map. Narrow beats grand.
- A baseline, written down. Close days, hours per report, error rate - captured before you start, by a named person.
- Guardrails in place. The a3 rails apply from the first day: privacy, human sign-off, an audit trail. A pilot that skips governance cannot scale even if it "works".
- A decision gate. Set the date and the threshold now: "if we cut cycle time by X with adoption above Y, we scale; if not, we stop and learn." A pilot with no kill criterion never ends and never scales.
LiveBuy vs build vs blend - the three doors3 min▶
You rarely need to build. Most finance value today comes from buying governed tools or blending copilots into existing systems. The tradeoff is always the same three dials: cost, control, and speed.
| Door | What it is | Cost | Control | Speed | Best when |
|---|---|---|---|---|---|
| Buy | License an enterprise tool or finance-native platform | Predictable subscription | Vendor-set; read the terms | Fast to start | The need is common and a good tool exists |
| Build | Custom solution on an API or internal platform | High + ongoing upkeep | Full - your data, your rules | Slow; needs engineering | The workflow is a true differentiator or nothing fits |
| Blend | Embedded copilots inside Excel, ERP, or your FP&A tool | Often bundled with what you own | Shared with the vendor | Fastest - it is already there | You want value inside existing workflows now |
For most finance teams the honest answer is blend first, buy where a specialist tool clearly wins, and build only when you have proven the need and can fund the upkeep. "Build" is rarely the cheap or fast door it looks like in a vendor deck.
The business-case one-pager 4 min live
Everything so far collapses into a single page a finance committee can read in three minutes and act on. Keep it to one page on purpose - if the case does not fit, the thinking is not done. Six sections, in this order.
LiveThe six sections, in order3 min▶
- Problem. The painful, specific status quo - in numbers. "Month-end close takes ten working days; three of them are manual reconciliation."
- Use-case. What the AI will do, narrowly. "Draft reconciliation summaries and flag anomalies for review." Not "transform finance."
- Cost. Licenses, setup, training time, and any build effort. Total cost of ownership, not just the sticker.
- Expected value. The honest metric with its baseline: "cut close from ten days to eight, redeploying ~X hours to analysis." State the lever and the "before".
- Risk + guardrails. The a3 rails made concrete: privacy handling, human sign-off, audit trail, and what could go wrong plus how you contain it.
- The ask. The specific decision you want: budget, a named pilot, a decision gate date. Make it easy to say yes.
This one-pager is the seed of the a6 roadmap: a portfolio of these, sequenced over 24 months, is your strategy. Nail one, and the next four write themselves.
Self-studyPresenting it in the room2 min read▶
- Lead with the problem, not the technology. Committees fund pain relief, not novelty. The word "AI" should arrive after the problem, not before it.
- Show the baseline first. "Here is what this costs us today" earns the right to claim a saving.
- Under-promise the value. A modest number you hit beats a bold one you miss - and your credibility for the next four cases depends on this one landing.
- Name the guardrails unprompted. A finance audience trusts the leader who raised the risk before they had to ask.
Draft a mini business case ◐ 15 min · on paper
Take one use-case from your a2 map - ideally the highest-scoring, lowest-risk one - and draft its business case on a single page. You are not building anything; you are proving you can defend the value before you spend a dollar.
- Write the problem in numbers. What does the status quo cost in days, hours, or errors today?
- Define the baseline: the specific "before" figure you would measure, and who would record it before the pilot starts.
- State the success metric using an honest lever - capacity redeployed or cycle-time cut, never a headcount promise you would not keep.
- Sketch the cost (buy, build, or blend) and the guardrails from a3.
- Write the one-sentence ask: the exact decision and the decision-gate date.
Official sources covered
This session teaches from public finance-AI curricula and published industry evidence on AI returns. Certificates, graded assessments, and paid tooling stay with the official programs - noted honestly. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Which is the most defensible way to state the value of a close-automation pilot?
Honest value is measurable: cycle-time cut and capacity redeployed against a baseline. Headcount-cut promises rarely survive reality, and vague "more strategic" claims are theatre, not a number.
2 · A big share of AI pilots show no P&L impact. What is the most common avoidable cause?
Pilots miss the P&L mostly for process reasons: no baseline was recorded, and no one actually changed how the work gets done. Both are fixable, and both are why the baseline rule and adoption come first.
3 · For a common finance need where a good governed tool already exists, which door is usually right first?
Build is rarely the cheap or fast door it looks like; it carries high upkeep and an ownership question. When a governed tool fits a common need, buying or blending gets you to a measurable pilot fastest, at predictable cost.