GaneevEcoThe gap between a hunch and a business case
Most AI ideas inside a company stay stuck at "this seems like it could help" because nobody attaches a specific, defensible number to the claim. A real business case needs a specific task, how often it happens, how long it currently takes measured rather than estimated, and a realistic, conservative estimate of the time or cost it would save — not a vague productivity claim that sounds good but can't survive a skeptical finance review.
The gap between these two states is smaller than it looks, and closing it usually just requires someone spending a few hours actually measuring instead of estimating. That relatively small upfront investment of time is what separates an idea that gets funded and taken seriously from one that stays permanently stuck as an interesting but unfunded suggestion in a meeting.
Building the case in practice
- Pick one specific, recurring task — not a whole function or department — since a narrower scope is both easier to measure accurately and easier to defend if questioned later.
- Get an honest current baseline from the people who actually do the task, not a guess from their manager who may not have hands-on visibility into how long it genuinely takes.
- State the expected improvement conservatively; overpromising in the business case is how pilots lose credibility later, even when the underlying use case genuinely had real merit.
Presenting it in a way leadership can actually act on
A business case built this way should fit on a single page: the task, the baseline, the proposed change, the conservative expected improvement, and how you'll measure whether it actually happened. That brevity isn't a limitation — it's precisely what makes the case easy for a busy executive to evaluate quickly and approve, compared to a lengthy document that buries the actual decision under pages of context nobody has time to fully absorb.
It's also worth explicitly stating what you'll do if the conservative estimate turns out to be wrong in either direction, since a business case that only describes the upside scenario reads as less credible to anyone who's reviewed enough of these to be appropriately skeptical of best-case projections presented as the expected outcome.
It's worth having someone outside the immediate team review the business case before it goes to leadership, specifically checking whether the claims would hold up to a skeptical read. A fresh, less invested set of eyes often catches an overstated claim or a missing caveat that the people closest to the proposal, understandably enthusiastic about their own idea, tend to miss entirely.
It's also worth building a simple template for this kind of business case that any department can reuse for their next proposal, rather than reconstructing the format from scratch every time a new idea comes up. A consistent template also makes it considerably easier for leadership to compare multiple proposals fairly against each other, since they're all structured the same way and cover the same core questions regardless of which department originated the specific idea.