An AI benefit belongs in the deal model only when management can explain which work changes, how much capacity becomes usable, and what decision turns that capacity into a financial result. A faster task is a useful starting point. It is not an EBITDA bridge.
The distinction matters during diligence. A demonstration may show a support agent drafting a reply in less time. The investment case needs to account for cases the tool cannot handle, employees who do not use it, review work, and the cost of running the solution. Those are separate assumptions. Keep them visible.
Start with the workflow, not an AI savings percentage
Define the unit of work and measure the current process through completion. For customer support, that could be a resolved case rather than a drafted response. Include the search for information, supervisory escalation and repeat contacts. Otherwise the baseline and the proposed improvement are measuring different things.
There is credible evidence of productivity improvement, but it does not establish a target company's financial benefit. In Generative AI at Work, Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied 5,172 customer support agents. The November 2024 revision reports an average 15% improvement in issues resolved per hour, with substantial differences across workers. That is evidence from one setting, not a default assumption for every portfolio company.
Ask for a sample covering ordinary work and difficult exceptions. Check whether the information required to complete each case is accessible and usable. The UK Government Data Quality Framework distinguishes completeness from accuracy: a populated field can still be wrong. Apply the same distinction to a proposed AI knowledge source.
Calculate usable capacity before assigning a dollar value
Fictional planning example · not a benchmark or client result
A support team handles 6,000 cases per month at 20 minutes each: 2,000 hours. The proposed tool reduces handling time to 12 minutes on cases where it is used. Assume 80% of cases are eligible and employees use the tool on 75% of eligible cases.
| Step | Calculation | Result |
|---|---|---|
| Baseline workload | 6,000 × 20 ÷ 60 | 2,000 hours |
| Cases using AI | 6,000 × 80% × 75% | 3,600 cases |
| Potential time saved | 3,600 × 8 ÷ 60 | 480 hours |
| Additional review and rework | Fictional monthly estimate | 120 hours |
| Usable capacity | 480 − 120 | 360 hours; 18% of baseline |
The 40% task-time improvement becomes 18% usable capacity across the whole workload under these assumptions. No monetary benefit has been established.
Test adoption independently from technical eligibility. If adoption falls to 50% of eligible cases, potential savings fall to 320 hours before review and rework. Do not assume overhead remains fixed; measure how it changes with volume and case complexity.
Also check whether the released time can be used. Minutes scattered across shifts may not remove a staffed shift or cover peak demand. Management might use the capacity to reduce a backlog, absorb growth or improve service. Those can be valuable operating outcomes without reducing expense.
Identify the management decision behind the financial benefit
Document the action that changes the forecast. Examples include avoiding a planned hire, reducing paid overtime, or ending an external service contract. The CFO should validate the baseline cost, timing and constraints. Do not multiply every hour saved by a salary rate and call the answer cash savings.
Fictional cost bridge · management assumptions, not accounting advice
Suppose verified capacity lets management cancel a planned $90,000 annual fully loaded hire that would have started in month seven. First-year avoided cost is $45,000. Assume $30,000 of implementation cost and $12,000 of first-year running cost. The simplified first-year net benefit is $3,000 before any other costs.
If the hire is still required, avoided cost is zero and the project incurs $42,000. If the planned hire would start in month ten, only $22,500 is avoided in that year, producing a $19,500 negative net benefit under the same cost assumptions.
This is a planning illustration, not a conclusion about EBITDA treatment, enterprise value or a staffing decision. Separate one-time investment from recurring costs and have finance determine the appropriate treatment. Include the spend required to sustain the workflow. The AWS Cost Optimization Pillar treats cost management as an ongoing operating responsibility, not a one-time infrastructure estimate.
Test whether the workflow can operate in the target company
Before committing the benefit, ask for evidence on the constraints that would invalidate it:
- Data access: the system owner confirms permitted use, access scope and the ability to retrieve the necessary records.
- Integration: a bounded test reads the source, proposes a change and verifies the permitted write in the system of record. Test failed and duplicate requests too.
- Quality: a representative evaluation measures unacceptable answers, additional review time and escalation. Agree which mistakes make the workflow unsuitable.
- Operations: name the person responsible for monitoring, incident response and changes to the model or knowledge source.
- Economics: include implementation, usage, maintenance and human supervision. Show a downside case as well as the expected case.
An API's existence does not prove the integration can support the operating volume. For example, Microsoft Dataverse service protection guidance requires integration clients to handle throttling and retry behavior. That work consumes delivery capacity and belongs in the scope.
The NIST AI Risk Management Framework addresses trustworthiness across design, development, use and evaluation. It is a useful reference for deciding what evidence and ongoing controls the workflow needs. It does not certify an investment case.
