How to calculate the ROI of an implementation without inventing figures

The ROI of an implementation is not demonstrated by counting automations, agents, integrations or screens. It is demonstrated by comparing a measurable operating situation with the economic value that can be captured after changing it.

The most common mistake is to start with a promise of improvement: “we will save 40%”, “the team will gain many hours” or “AI will do the work”. A serious business case works the other way around. First measure the current process. Then identify how much of the cost can be reduced, what capacity can be freed up, and what full investment is required to achieve it.

1. Define the economic problem before defining the solution

A company does not obtain returns because a technology works. It obtains return when a relevant business variable changes: cost per operation, capacity, cycle time, error, conversion, risk, need for structure or response speed.

That is why it is advisable to write the investment case without mentioning tools. For example: “the team dedicates too much capacity to classifying and chasing documentation”, “the approval of offers generates waits that delay income” or “growth forces people to be hired at the same rate as volume increases”. If the problem cannot be expressed operationally, it is still early to calculate ROI.

2. Build a verifiable baseline

Without a “before”, the “after” proves nothing. The baseline must be built with real process data, even if it is imperfect. If there is no formal analysis, you can start with a representative sample of recent cases.

It separately measures direct work and waiting. Ten minutes of human activity and three days waiting for approval are two different problems. One consumes capacity; the other lengthens the cycle and can affect customer experience or income.

Minimum useful data

• Cases per week, month or quarter.
• Direct human time per stage.
• Waiting time between stages.
• Percentage of cases with error or rework.
• Number of people involved.
• Necessary interruptions or internal consultations.
• Incidents, returns or associated losses.
• Expected volume if the company grows.

Hypothetical example: A company processes 1,000 applications per month. Each requires eight minutes of manual handling. There are about 133 hours of direct work per month. If a new architecture reduces manual work to four minutes, the theoretical savings are about 66 hours. That's not yet 66 hours of economic benefit: you have to determine how much of that capacity can be used productively.

3. Calculate the total cost of ownership, not just the development price

The ROI denominator should reflect the actual cost of implementing and operating the solution. A development budget is not the entire TCO.

Initial costs

• Analysis and design of the process.
• Development or configuration.
• Integrations and migrations.
• Cleaning or preparing data.
• Testing and validation.
• Training and operational change.
• Internal time dedicated by business managers.

Recurring costs

• Infrastructure and consumption.
• Licenses.
• Maintenance.
• Observability and support.
• Review of exceptions.
• Updates due to changes in systems or processes.
• Security and compliance controls where applicable.

If a system automates 80% of cases but the remaining 20% requires human review, that review is not a calculation failure: it is part of the system's operating cost. The financial model must include it.

4. Separate sources of value to avoid counting the same benefit twice

A. Recovered operating time

It is the time that is no longer consumed by copying, searching, classifying, reconciling, chasing statuses or redoing work. To economically value that time, avoid assuming that each hour saved is equivalent to one hour of payroll eliminated. In many companies, the real value is freed capacity to serve more volume, improve service or avoid future hiring.

B. Errors and rework avoided

It includes the cost of correcting data, repeating tasks, managing incidents, compensating clients, checking duplicates or resolving decisions made with incorrect information. Sometimes this category generates more value than saving time.

C. Additional capacity

A process improvement can allow more transactions to be absorbed without increasing structure at the same rate. It is important to differentiate this benefit from saving hours so as not to count it twice.

D. Recovered or accelerated income

Faster response to opportunities, lower churn, shorter sales or delivery cycles, fewer blocked orders or protected renewals. Attribution must be cautious: if an improvement helps close a sale, it does not mean that 100% of the revenue is due to the technology.

E. Reduced risk

Continuity, traceability, privacy, compliance, dependence on key people or the possibility of detecting errors before they escalate. Some risks are difficult to convert into euros; That does not require inventing a figure. They can be maintained as a separate dimension of decision.

A business case is more reliable when you distinguish what you know, what you estimate, and what you still need to validate.

5. Calculate captureable savings

The theoretical savings responds to “how much work would disappear.” Capturable savings respond to “what value the company can really take advantage of.” The difference is critical.

If a team recovers 100 hours a month but the work is fragmented into small blocks and no one can reallocate that capacity, the direct economic value will be lower. If those 100 hours allow you to avoid a planned hire or handle more volume with the same team, the value can be much more tangible.

A prudent way to model this is to use an explicit capture factor and document why. There is no universal percentage. It must be justified with the company's real way of working.

6. Use ROI, net profit and payback together

Annual net profit = annual captureable value − annual operating cost.

ROI = (total profit − total investment) / total investment × 100.

Payback = time necessary for the accumulated benefits to recover the initial investment.

These metrics answer different questions. The ROI shows relative efficiency of the investment. The payback shows how long capital remains committed before being recovered. Two initiatives with similar ROI can be very different if one recovers the investment in months and another takes several years.

Hypothetical example: initial investment of €30,000, annual recurring cost of €12,000 and annual captureable value of €72,000. The annual net profit would be €60,000. But the analysis should not assume that that benefit begins on day one. Implementation, adoption and learning curve must be modeled.

7. Introduce an adoption ramp

Processes rarely go from “before” to “after” instantly. During the first few weeks there may be double trading, additional monitoring or some volume still in the old flow.

The financial model should reflect the percentage of volume that moves to the new system each month and when transition costs disappear. This avoids overestimating the first year.

8. Build scenarios, not a single figure

A defensible business case must survive reasonable changes in assumptions.

Conservative scenario

Lower adoption, more exceptions, higher operational cost and less captureable savings.

Probable scenario

Hypotheses supported by baseline and process evidence.

Favorable scenario

More volume or additional plausible improvement. It should never be the only scenario that makes the project viable.

Then it performs sensitivity on the variables that most influence: volume, time per case, automation percentage, infrastructure cost, exception rate, capture factor and expected growth.

9. Don't confuse savings, capacity and workforce reduction

This distinction prevents many bloated business cases. Recovering capacity does not necessarily mean reducing structure. It can mean producing more with the same equipment, absorbing growth, improving times or moving people to higher-value work.

That's why language matters. If the real benefit is “avoiding two future hires,” model that avoided cost. If the benefit is “reduce backlog”, measure backlog and cycle time. Don't artificially turn everything into salary reduction.

10. Include the cost of doing nothing

The correct comparison is not always “current situation vs. project.” If the volume grows, maintaining the current process also has a future cost. It can require more people, generate more errors or increase delays.

The base case should reflect what will reasonably happen if nothing is changed. This is especially important when the primary value of the implementation is to contain cost growth.

11. Turn ROI into a portfolio decision

The project with the highest ROI is not always the first one that should be executed. Hypothesis confidence, complexity, risk, dependence on other systems, time to value, reversibility and the learning it generates also matter.

A practical matrix can evaluate:

• Potential economic impact.
• Trust in data.
• Technical complexity.
• Organizational complexity.
• Operational risk.
• Time to first value.
• Reuse of created capacities.

A somewhat smaller initiative but with clear data and low risk may be a better first step than a huge transformation based on assumptions.

12. Design the measurement before implanting

ROI doesn't end when the budget is approved. You have to define how it will be checked later.

If the implementation saves time but increases errors, the net result may be negative. If it reduces errors but increases the cost of operation too much, it may have to be redesigned. Measuring a single metric produces incomplete decisions.

13. Practical template to build the business case

1. Describe the current process in one sentence.
2. Measure volume and time per stage.
3. Calculate cost of error and rework.
4. Project the scenario of doing nothing.
5. Defines what changes with the intervention.
6. Estimate theoretical savings and capture factor.
7. Calculate initial and recurring TCO.
8. Model adoption ramp.
9. Build conservative, probable and favorable scenarios.
10. Calculate ROI and payback.
11. Compare with other opportunities.
12. Define how you will check the actual result.

Conclusion

The goal of an ROI calculation is not to fabricate a compelling number. It is reducing uncertainty before committing capital and operation. A good business case makes the hypotheses visible, differentiates captureable benefits from theoretical benefits and allows the decision to be changed when new data appears.

When a company can clearly explain what problem costs money, how it is measured, what full investment it requires to solve, and what must happen to recover that investment, the conversation stops being technological and becomes a business decision.

If you need to structure this analysis on real processes in your company, you can see how ProjectCore works in our method.