# How to build an automation business case finance will sign > Baseline the true cost of the work, separate hard from soft savings, count every cost including upkeep and usage fees, adjust for risk and time, and present it on one page. The method behind published total economic impact studies, scaled to one project. - Author: Pranav Mahaveer, Founder, SBD - Updated: 2026-10-28 - Level: Intermediate. Time to do: Two to four days - For: Anyone asking a finance director or owner to fund an automation or AI project - You will end with: A one-page, risk-adjusted business case with net present value, payback, a conservative scenario and the assumptions behind it - Canonical: https://smallbaydigital.com/guides/how-to-build-an-automation-business-case/ ## Steps 1. **Baseline the cost of the work today.** Measure volume and handling time, then cost it at the loaded hourly rate, not the wage. 2. **Separate hard savings from soft.** Decide which benefits change spending and which only free time, and count freed time at a realisation rate. 3. **Count every cost.** One-time build, internal project time, training, subscriptions, seats, usage fees, support and upkeep. 4. **Adjust for risk and time.** Ramp benefits over adoption, cut them for risk, add contingency to costs and discount to today. 5. **Run scenarios and sensitivity.** Show conservative, expected and optimistic cases, and which inputs move the answer most. 6. **Write the one-page case.** Lead with the decision and the conservative number, then the assumptions, risks and how success will be measured. > **The short answer.** Cost the work at the loaded rate, count only the share of freed time that becomes money, include every cost for three years including upkeep and usage fees, cut benefits for risk and discount everything to today. Show the conservative case first. If it is positive, the case is ready; if only the optimistic case works, it is not. Most automation business cases fail with finance for the same reasons: they cost labour at the wage, count every saved minute as cash, leave out running costs and present one optimistic number. Each of those is easy to fix. The structure below follows the Total Economic Impact method that Forrester uses in its published studies: benefits, costs and risk, discounted over the analysis period. It works as well for a $5,000 workflow as for a platform decision. ## 1. Baseline the cost of the work today You need three numbers for the process as it runs now. | Number | How to get it | | ---------------------- | ------------------------------------------------------------------ | | Volume a month | A system report: invoices posted, tickets closed, orders entered | | Handling time per item | A one-week time log or a work sample, including rework and chasing | | Loaded hourly cost | Wage plus benefits, payroll taxes, leave and insurance | The loaded rate matters more than people expect. In US private industry in December 2025, employers paid $46.15 an hour in total compensation, of which wages were $32.36 and benefits $13.79. Costing labour at the wage alone understates the work by about 30%. Add the cost of errors: take a sample of real mistakes and estimate staff time to fix each, plus any credits, late fees or refunds. In finance and customer-facing processes, errors can be worth as much as the time. ## 2. Separate hard savings from soft Finance will ask one question about every benefit: does it change what we spend? - **Hard savings** change spending: a hire you no longer need to make, agency or temp spend that stops, overtime that ends, late-payment fees avoided, licences retired. - **Soft savings** free time without changing spending. They are real capacity, but they reach the accounts only if the time goes to work that earns. Count soft savings at a stated realisation rate. Finance teams commonly use 60 to 80% of freed time. Use 100% only where a cost actually disappears, and say so. Leave strategic benefits, such as faster decisions or better retention, out of the numbers. List them beside the case. Forrester's method calls this flexibility: real, but too uncertain to price. ## 3. Count every cost The costs that get left out are the ones that sink a case later. | Cost | Notes | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | Build or set-up | The provider's fixed price, or your developers' time | | Your team's project time | Workshops, testing and sign-off, at the loaded rate | | Training | Hours per person times people, at the loaded rate | | Flat subscriptions | Automation platform, database, hosting, monitoring | | Seats | Per-user fees for internal apps and databases | | Usage | AI model tokens, API calls, OCR pages, messages, task or operation fees, per item handled | | Support | A support or care contract, if you buy one | | Upkeep | Fixes when connected systems change. Plan at least 15 to 20% of build cost a year for a stable system, and 30 to 40% where APIs or prompts change often | Usage pricing needs care. Multiply the cost per item by the items the automation will handle, add headroom for retries and longer inputs, and check the provider's current price list rather than last year's blog post. ## 4. Adjust for risk and time Four adjustments turn a hopeful estimate into one finance can defend. 1. **Ramp the benefits.** Teams take time to trust and adopt a new system. Spread full benefits over the first two to four months. 2. **Cut benefits for risk.** 10% where the process and data are well understood, 20 to 30% where something is new. 3. **Add contingency to costs.** 10% is common. 4. **Discount to today.** Convert each month's cash flow to present value at your cost of capital. Most published studies use three years at 10% a year. The headline numbers then follow standard definitions: - **Net present value** is discounted benefits minus discounted costs. - **ROI** is net present value divided by discounted costs. - **Payback** is the first month the running total turns positive. Show the discounted payback too. ## 5. Run scenarios and sensitivity One number invites one question: what if you are wrong? Answer it before it is asked. **Scenarios.** Show three columns. A sensible conservative case takes about 70% of the time saving you expect, a lower realisation rate, costs 25% higher and slower adoption. Lead with it. **Sensitivity.** Move each main input 20% up and down and see how far net present value moves. Usually two or three inputs dominate: handling time, volume and the share of work removed. Those are the ones to measure properly before signing. The free [ROI calculator](/tools/roi-calculator/) does all of this in the browser with any pricing model, and exports the cash flows to CSV for finance to check. ## 6. Write the one-page case Finance reads the first paragraph and the assumptions. Write for that. 1. **Decision.** What you are asking for, the amount and the date. 2. **Result.** Conservative net present value, ROI and payback, then the expected case. 3. **What changes.** The process, the hours and errors removed, and the approach. 4. **Costs.** One-time and annual, by line. 5. **Assumptions.** Every input with its source: system report, time log, quote, price list. 6. **Risks and mitigations.** Adoption, data quality, dependency on a vendor, upkeep. 7. **How success will be measured.** The baseline metric, the target and a review date 90 days after launch. Then measure. A case that is re-checked against real numbers after launch is the one that gets the next project funded. ## Checklist - [ ] Volume taken from a system report, handling time from a time log or sample - [ ] Labour costed at the loaded rate: wage plus benefits, payroll taxes and leave - [ ] Error and rework cost estimated from a sample of real cases - [ ] Each benefit labelled hard (changes spending) or soft (frees time) - [ ] Freed time counted at a stated realisation rate, not 100% - [ ] Internal project and training hours included as a cost - [ ] Usage-based fees modelled per item, with headroom for retries - [ ] Annual upkeep included, at least 15 to 20% of the build for a stable system - [ ] Benefits ramped over the adoption period - [ ] Benefit risk adjustment and cost contingency applied and stated - [ ] Cash flows discounted at the cost of capital over a stated period - [ ] Conservative scenario shown first, and still positive - [ ] Sensitivity shows the two or three inputs that matter most - [ ] Success measures and a review date agreed before work starts ## Sources - Forrester, [Total Economic Impact methodology](https://www.forrester.com/policies/tei/) - US Bureau of Labor Statistics, [Employer Costs for Employee Compensation, December 2025](https://www.bls.gov/news.release/ecec.htm) - Practitioner guidance, Maintenance planning figures for automation, 15 to 22% of build cost a year for stable systems, 30 to 40% where APIs or prompts change often ## Questions ### What discount rate should an automation business case use? Your company’s cost of capital if finance has one. Otherwise 10% a year is a common default: it is the rate most published total economic impact studies use. Higher rates make long paybacks look worse, which is usually the right bias for software. ### Over how many years should we model it? Three is standard and defensible. AI tools and the systems around them change quickly, so a five-year case rests on assumptions that are unlikely to hold. If the project only pays back in years four and five, rethink the scope. ### How much risk adjustment is enough? Cut benefits by 10% for a well-understood process with measured data, and 20 to 30% where the process, the data or the technology is new to you. Add 10% contingency to costs. State the figures so finance can change them. ### Should time saved count as money saved? Only when it changes spending: a hire not made, overtime or agency spend that stops, or time moved to work that earns. Otherwise count a share of it. Finance teams commonly use 60 to 80%, and label the rest as capacity.