Why five separate models?

AI initiatives create value in fundamentally different ways depending on what they automate or augment. A copilot for knowledge workers, a customer service bot, a process automation, a forecasting model, and a model migration all have different value drivers, different cost structures, and different risk profiles. Applying one formula to all five produces meaningless numbers.

We built a separate calculation engine for each category: Copilots & Knowledge, Support Automation, Process Automation, Forecasting & Analytics, and AI Model & API Spend. Each has its own formula, its own realisation factor, its own cost structure, and its own sensitivity variables.

A month-by-month simulation, not a simple multiply

Every estimate runs a month-by-month simulation over your chosen time horizon (default: 3 years). This allows the model to reflect how AI projects actually behave: costs front-loaded, value building over time, and some categories subject to ramp-up, growth, or decay.

The cumulative value and cumulative cost lines are tracked monthly. ROI, payback, net value, and NPV are all derived from this simulation, not from a simplified annual average. This is why entering a 6-month rollout period produces a different result than entering 1 month. The ramp is reflected in the curve, not assumed away.

For Copilots & Knowledge specifically, adoption compounds across years in the simulation rather than staying flat. Year-1 uses your input directly; year-2 and beyond grow organically up to a ceiling. This means a 3-year estimate captures the compounding effect of increasing adoption, which a flat-rate model would miss.

Core metrics

ROI = (Cumulative Value − Total Cost) ÷ Total Cost

Net Value = Cumulative Value − Total Cost (over the full horizon)

Payback = First month where Cumulative Value ≥ Cumulative Cost

NPV = Σ (Annual Net Cash Flow ÷ (1 + 10%)^Year) (year-end convention)

The 10% discount rate is a standard enterprise hurdle rate. It reflects the opportunity cost of capital and the time value of money. All NPV calculations use year-end cash flow convention.

Category formulas

Each formula below is the gross value calculation before the realisation factor is applied. Costs are tracked separately on the cost side of the simulation.

01Copilots & Knowledge

Hourly rate × Hours saved/week × 52 × Users × Year-1 adoption × 50%

Hourly rate is derived from annual salary divided by 2,080 working hours.
Value ramps linearly over your stated rollout timeline: a 6-month rollout means roughly 75% of the theoretical year-1 value is captured, not 100%.
Adoption compounds automatically across years. Year-2 adoption = min(Y1 × 1.5, 85%). Year-3 and beyond = min(Y2 × 1.2, 90%). A 60% year-1 rate becomes 85% in year 2 and 90% from year 3 onward. This reflects observed organic maturation in enterprise copilot rollouts.
Costs: implementation and change management charged upfront; tool licences charged annually; training is a one-off year-1 cost.
Sensitivity is run on hours saved per week and year-1 adoption rate. These are the two inputs with the most leverage on outcome.

02Support Automation

Monthly tickets × Deflection rate × Containment rate × Cost per interaction × 85%

Containment rate is the fraction of deflected tickets that are truly resolved without re-escalation. Deflecting 30% but only containing 75% means the effective saving is 22.5% of total volume.
Ticket volume compounds annually by your stated growth rate, increasing the value of the same deflection rate over time.
Retention uplift (CSAT → churn reduction) is not included in this version. The correct formula requires a unique-customer count separate from interaction volume, a field we plan to add in a future update.
Sensitivity is run on deflection rate and monthly interaction volume.

03Process Automation

(Minutes saved per transaction × Volume/month ÷ 60) × Hourly cost × 75% + Errors avoided × Cost per error × 75%

Time saving and error reduction are calculated independently and summed. Both flow through the 75% realisation factor.
Transaction volume compounds annually. If you enter 10% growth, year-3 savings are 21% higher than year-1 savings in absolute terms.
Whether freed FTE capacity is redeployed or reduced affects the business case framing but not the financial calculation. ROI is identical either way.
Sensitivity is run on current minutes per transaction (the current baseline complexity) and transactions per month.

04Forecasting & Analytics

Decisions/year × Value per decision × (Expected accuracy − Current accuracy) × 50%

Value ramps linearly from zero to full over your stated months to maturity. A 6-month ramp reduces year-1 value by roughly half.
Model accuracy decays at your stated annual rate unless retrained. A 10% annual decay means year-3 value is 80% of the peak, assuming no retraining.
The single "implementation + run cost (annual)" field is charged uniformly each year across the full horizon. There is no separate upfront lump sum. This reflects the reality that data projects blend build and operating cost without a clean separation.
Sensitivity is run on expected accuracy rate and decisions per year.

05AI Model & API Spend

(Current model monthly cost − New model monthly cost) × 12 × Years

Monthly cost is calculated from token counts: (input tokens × input price + output tokens × output price) ÷ 1,000,000 × monthly queries.
Tiering splits your query volume between a full-capability tier and an efficient tier. If 40% of queries are routed to the efficient tier, cost savings are calculated on that fraction only.
No realisation factor is applied. Model pricing is deterministic.
Confidence is always High because pricing is publicly listed and not subject to adoption or implementation risk.
Migration cost (re-prompting, integration, testing) is an upfront cost charged at month 0.
Sensitivity is run on monthly query volume and tiering split percentage.

Realisation factors

Not all theoretical value converts to real business output. Realisation factors are conservative haircuts applied to each category's gross value calculation. They reflect the gap between what is theoretically possible and what organisations actually achieve, based on published research, implementation post-mortems, and our own delivery experience.

Every realisation factor is shown explicitly in the Assumptions section of your report. They can be debated, adjusted in a detailed model, or replaced with actuals once you have pilot data.

Category	Factor	Rationale
Copilots & Knowledge	50%	Not all saved time converts to productive output. Managers need to redirect capacity deliberately. It does not happen automatically.
Support Automation	85%	Deflection value is relatively deterministic once you measure it. We apply a 15% haircut for partial-resolution edge cases.
Process Automation	75%	Time and error savings are reliable but exception handling and rework absorb some of the theoretical gain.
Forecasting & Analytics	50%	Model accuracy improvements translate indirectly to decision quality. Decision-makers often override recommendations, especially in year 1.
AI Model & API Spend	None	Cost savings from model switching are deterministic. No adoption haircut applies.

Sensitivity analysis

Every report includes a sensitivity table that shows what happens to ROI, payback, and net value when the two highest-leverage inputs move ±20%. The full formula is re-run for each scenario. It is not a linear approximation.

The variables chosen for sensitivity are those most likely to differ significantly from your estimate in practice. For example, year-1 adoption rate in a copilot deployment is notoriously hard to predict before launch. A ±20% swing around a 70% base takes you from 56% to 84% in year 1, with compounding effects flowing through years 2 and 3 as well.

For Process Automation, sensitivity runs on the current minutes per transaction (the baseline complexity), not the target. This is intentional: a higher current baseline means more savings potential, so +20% on the baseline correctly produces a higher ROI in the sensitivity table.

Confidence levels

Confidence (Low / Medium / High) reflects how reliable the estimate is, based on three factors: how many inputs you have provided, whether you are in pre-initiative (estimates) or in-flight mode (actuals), and the inherent uncertainty of the category.

HighIn-flight mode with complete inputs, or AI Model & API Spend (pricing is deterministic). Safe to present externally with standard forward-looking caveats.
MediumNew project with most inputs provided, or in-flight with some estimates remaining. Appropriate for internal planning; validate key assumptions before board presentation.
LowFew inputs provided, or Forecasting & Analytics with low-confidence accuracy estimates. Use for sizing and prioritisation only. Not for external presentation.

For Forecasting & Analytics specifically, if you signal low confidence in the accuracy estimate, the overall result is capped at Low regardless of how many other inputs you provide, because that variable drives the entire value calculation.

What this tool does not do

Account for organisation-specific constraints such as technical debt, regulatory restrictions, or cultural resistance to adoption.
Replace a detailed business case or financial model reviewed by your finance team. These are estimates based on benchmarks, not actuals.
Guarantee any specific outcome. AI projects carry implementation and adoption risk that no model can fully quantify.
Account for the cost of being slow. Competitive disadvantage from delayed AI adoption is real but outside the scope of a financial model.
Capture integration complexity, data quality remediation costs, or change management programmes beyond the default 15% factor.

How we estimate AI ROI