The most misleading number in any AI business case is the one that multiplies hours saved by an hourly rate and stops there. Twenty-five people saving 40 minutes a day at $65 an hour comes to $22,750 a month, $273,000 a year, and every finance director who has ever seen that calculation knows it is not true — because if it were, the department would have shrunk by four people, and it has not.
Two fields on this calculator exist to make that number honest. They are the only two that matter, and both of them are estimates you are responsible for defending.
Realisation: does the saved time become anything?
Realisation rate is the proportion of saved time that converts into other valuable work. Set it to 100% and you are claiming that every minute a tool gives back is immediately reinvested in billable, revenue-generating or otherwise useful output. No team achieves this, and the reason is arithmetic rather than laziness: time returns in fragments. Six minutes saved on a first draft, four on a summary, eleven on a code review. Fragments below about fifteen minutes mostly evaporate into context-switching, and even the ones that survive land on people whose workload was not the binding constraint on anything.
Realisation is highest where three conditions hold — the saved time lands in blocks, there is a visible queue of work waiting to fill it, and someone is measuring throughput. A support team with a backlog and a ticket counter realises far more of its saved time than a marketing team with no queue at all. Consultancies with billable-hour targets sit at the top of the range because unbilled hours are already tracked and the reinvestment path is explicit.
Sensible starting values run from 25% for diffuse knowledge work to 60% for queue-driven operational teams. The default here is 45%. If you cannot say which of those three conditions your team meets, use 30% and let the grid do the arguing.
Adoption: how many people actually use it?
Adoption rate is the share of licensed users who use the tool regularly enough for the time saving to apply. This is the field where business cases most often quietly cheat, because the licence count is a known number and the active count is not — until you look, at which point 60% to 75% is typical after a proper rollout with training, and 30% to 40% is typical after an announcement email.
Adoption and realisation multiply. At 70% adoption and 45% realisation you are keeping 31.5% of the headline saving, which is why the naive $22,750 above becomes something far smaller once both are applied.
Use fully loaded cost, not salary
The rate field asks for fully loaded hourly cost because that is what an hour of someone's time actually costs the organisation, and it is the rate a finance team will accept. Take a $95,000 salary:
- Employer taxes, pension and benefits, roughly 20%: $95,000 × 1.20 = $114,000
- Overhead — property, IT, management, recruitment, insurance — roughly 15%: $114,000 × 1.15 = $131,100
- Productive hours: 260 weekdays, less 25 days of leave and public holidays, less 5 days of sickness and training, is 230 days × 7.5 hours = 1,725 hours
$131,100 ÷ 1,725 = $76.00 an hour, against a raw salary rate of $95,000 ÷ 2,080 = $45.67. The loaded figure is 66% higher, and using the lower one understates your case by a third.
Do not use the client billing rate unless the saved time genuinely converts into more billed hours. If it does, use it and set realisation accordingly — that is a revenue argument, not a cost one, and it is far stronger.
Working the default through
Twenty-five people, 70% adoption, means 17.5 active users. Each saves 40 minutes across 21 working days: 40 × 21 ÷ 60 = 14 hours a month. Total 17.5 × 14 = 245 hours.
245 × $65 = $15,925 of raw time value. Apply 45% realisation: $7,166.25 a month of value that actually shows up somewhere.
Subtract $750 a month of tooling and the net is $6,416.25. Against $12,000 of setup and training, payback lands at 12,000 ÷ 6,416.25 = 1.9 months, and year one nets $64,995 against $21,000 of total cost — a 309% return.
Worth checking what that $750 tooling line contains, because the token cost is rarely the bulk of it. The same 25 people sending 35 messages a day at 1,800 input and 500 output tokens on Claude Sonnet 5 ($2.00 and $10.00 per million) costs 18,375 × $0.0086 = $158.03 a month. The other $592 is seats, interface and support — split it properly with the subscription versus API calculator before you defend the figure.
Reading the sensitivity grid
The grid recomputes monthly net benefit across five realisation rates and four adoption rates, so you can see the shape of the answer rather than one point on it. Read it three ways.
Look at the worst square first — 20% realisation, 40% adoption. On the defaults that is 10 active users saving 140 hours, worth $9,100 raw and $1,820 realised, netting $1,070 after tooling. Still positive. That is the strongest possible version of this business case, and it is the square to lead with: even if we are wrong about almost everything, we do not lose money.
Then find where the sign flips. On the defaults it never does, which tells you the case is robust. Change minutes saved from 40 to 10 and the same worst square becomes 35 hours, $2,275 raw, $455 realised, and a loss of $295 a month. Now you know exactly which assumption the programme depends on: not adoption, not realisation, but whether the tool really saves more than a quarter of an hour a day.
Third, ignore the bottom-right corner. If your case only works at 100% adoption and 100% realisation, it does not work.
Give finance the range
A single confident number invites a single arbitrary discount. Hand a CFO "$273,000 a year" and it becomes $100,000 in their head before you have finished the sentence, because they have seen that class of claim before and they have no way to interrogate it.
Hand them the grid instead, with the assumptions named, the losing squares visible and the worst case stated first, and something different happens: the conversation moves from whether to believe you to which square is right. That is a conversation you can win with evidence, and it is the reason the losing squares are worth showing rather than hiding.
The best version of this presentation carries a commitment attached. State the assumed adoption rate, say how you will measure it at 90 days, and agree in advance what happens if it comes in at 35% instead of 70%. Forecasting the spend that goes with it is covered in LLM cost forecasting, and the costs that never make it into the tooling line — review time, rework, integration maintenance — are in the hidden costs of AI. Put both on the same page as the grid.
Prices used by this calculator were last verified on 15 August 2026 from the vendors' own pricing pages. See the full price index for every figure and its source, the change log for what has moved recently, and the methodology for how the index is maintained and where its limits are.