Most technology investments don't fail technically. They fail because no one clearly defined what success looks like before the project started, and no one measured what changed afterward. Six months after launch, someone asks whether the investment was worth it, and the honest answer is "we're not sure."
Measuring technology ROI is harder than measuring financial ROI because much of the value is indirect. Technology doesn't usually generate revenue directly. It reduces friction, speeds up processes, improves data quality, or enables something that was previously impossible. Quantifying those effects requires connecting technology capabilities to business outcomes, which requires some deliberate upfront work.
This framework covers that work: how to define success before you build, how to identify and track the right metrics, how to account for total cost, and how to communicate the result to stakeholders who don't think in technical terms.
Why Technology ROI Is Harder Than Financial ROI
Traditional return on investment is clean: you spend X and you get Y back. Technology investments are messier because the returns are usually a mix of hard and soft value. Hard value is measurable in dollars: reduced staff hours, lower infrastructure costs, fewer support tickets. Soft value is real but harder to quantify: better decisions from cleaner data, faster time-to-market, reduced risk.
The trap is to focus only on hard value because it's easier to measure, and miss the actual business case for the investment. Or to focus only on soft value because it sounds impressive, and produce numbers no one believes.
A useful technology ROI framework captures both types of value, distinguishes which parts can be measured directly and which require reasonable estimation, and is honest about the assumptions it makes.
Step 1: Define Success Before You Build
Before any technology investment, answer these questions in writing:
What specific business problem does this solve? Not "we need better data" or "we want to modernize," but something concrete: "We spend 12 hours per week manually reconciling these two systems, and errors cost us approximately $4,000 per incident."
Who bears the current cost? Name the departments, roles, and processes that carry the burden today. This identifies who will be affected by the change and who will be responsible for measuring the improvement.
What does measurable improvement look like? Define threshold numbers: this investment is a success if we reduce reconciliation time by 60% and eliminate error-related costs within six months of launch.
Writing these down before you start creates a measurement baseline and forces clarity on what you're actually buying. It also gives you a way to evaluate vendors: if a vendor can't articulate how their solution addresses your specific problem, that's useful information.
Photo by KATRIN BOLOVTSOVA on Pexels
Step 2: Identify Your Baseline Metrics
You can't measure improvement if you don't know where you started. Baseline metrics need to be gathered before the technology is deployed, not reconstructed afterward from imperfect memory.
Common baseline metrics for business technology:
Time metrics: Hours per week spent on a specific process, average time to complete a transaction, time from request to delivery.
Error metrics: Number of errors per period, cost per error (in staff time to fix, or in business impact), error rate as a percentage of total volume.
Cost metrics: Infrastructure costs, software licensing, staff time allocated to manual work that the technology will automate.
Volume metrics: Transactions per period, support tickets per period, data records processed per period. These provide context for efficiency metrics that would otherwise be hard to compare across different time periods.
For each metric, agree on the measurement method before deployment. If you're going to measure error rates, decide now how errors are defined and counted. If the definition changes after deployment, your before-and-after comparison loses its meaning.
Step 3: Map Technology Capabilities to Business Outcomes
Technology capabilities and business outcomes are different things. A capability is what the technology does: "automates the data validation step." A business outcome is what changes as a result: "reduces the time our operations team spends on data cleanup from 8 hours per week to under one hour."
Mapping capabilities to outcomes forces you to trace the causal chain and identify where assumptions live. If you claim the automation will reduce operational time by 87%, you're making assumptions about how the team currently spends that time, how much of it the automation will actually handle, and what they'll do with the freed capacity. Being explicit about those assumptions lets you track whether they were correct.
"The projects where we see the clearest ROI are the ones where the client came in knowing their baseline numbers. Not estimates, actual measurements. They knew what the process cost them before we started, and they had a plan to measure the same metrics after. That discipline makes everything downstream easier." - Dennis Traina, founder of 137Foundry
This mapping exercise also helps identify which investments are low-confidence vs. high-confidence. An outcome like "reduced manual processing time" is high-confidence because it's directly caused by the automation and easy to measure. An outcome like "improved customer retention" is lower-confidence because it's influenced by many factors besides the technology, and the causal link is harder to demonstrate.
Step 4: Track Both Hard and Soft Returns
Hard returns are value you can put a dollar figure on with reasonable confidence:
- Time saved x fully-loaded hourly cost of the person or team doing that work
- Reduced error costs (errors per period x cost per error)
- Infrastructure cost reductions
- Fewer support tickets x cost per ticket
- Faster delivery of revenue-generating work if time-to-market translates directly to revenue
Soft returns are real value that resists direct monetization but matters for the business case:
- Better decision-making from cleaner or faster data. You can estimate this if you have examples of poor decisions that came from bad data, but it's often approximate.
- Reduced risk. If the technology addresses a compliance gap or makes an outage less likely, the value is real but probabilistic.
- Employee satisfaction and retention. Automating tedious work has retention effects, but quantifying them requires making assumptions about what drives turnover.
- Strategic optionality. The data infrastructure you build today might enable a product capability next year that you can't fully envision now.
For a compelling ROI presentation, focus primarily on hard returns that you can defend with measured numbers, and present soft returns as additional upside with transparent assumptions. Stakeholders who trust your hard numbers are more likely to give weight to the soft ones.
Photo by www.kaboompics.com on Pexels
Step 5: Account for Total Cost of Ownership
Total cost of ownership for technology includes more than the initial build or license cost. Common underestimated costs:
Implementation costs: Development, integration, data migration, testing, and deployment. These are often estimated optimistically. Build in a buffer.
Transition costs: Staff training, process documentation, the productivity dip during the changeover period while people learn the new system.
Ongoing costs: Licensing, infrastructure, maintenance, support, and the staff time required to administer the system after launch. A system that costs $20,000 to build but $15,000 per year to maintain has a very different ROI profile than one that costs $40,000 to build and $2,000 per year to maintain.
Opportunity costs: What didn't you build because your team was building this? What else could that development capacity have done?
The ROI formula is straightforward once you have these numbers: (Total Value Returned - Total Cost of Ownership) / Total Cost of Ownership. Expressed as a percentage, it gives you a number you can compare across investment options or against a required return threshold.
For context on the net present value of returns that come over time rather than immediately, discounting future returns by a cost of capital is standard practice in capital budgeting and applies to technology investments the same way it applies to any other long-term investment.
Communicating ROI to Non-Technical Stakeholders
Technology ROI conversations often fail not because the numbers are wrong but because they're presented in ways that don't connect to how business stakeholders think about value.
Lead with the business problem, not the technology. Start with "we're losing 12 hours per week to manual reconciliation and it's causing $4,000 in errors" rather than "we're proposing a system integration." The technology is the solution, not the story.
Use the language of the person you're talking to. Finance wants to see a payback period: "This investment pays back in 14 months." Operations wants to know which process problems go away. Leadership wants to know what strategic options this opens up.
Show your assumptions explicitly. A number without assumptions looks like it came from thin air. A number with explicit assumptions can be challenged and refined, which builds more confidence in the result than a black box estimate.
Connect to key performance indicators the organization already tracks. If leadership reviews revenue per employee quarterly, connect your efficiency improvement to that metric. If they watch support ticket volumes, show them the expected reduction.
Photo by Nataliya Vaitkevich on Pexels
The technology ROI framework described here applies to almost any business technology investment: new software, automation projects, system integrations, or infrastructure upgrades. The specifics vary, but the discipline of defining success upfront, measuring a baseline, tracing capabilities to outcomes, accounting for full costs, and communicating in business terms stays consistent.
The 137Foundry services team works through this analysis with clients before scoping technology projects, because the clarity it produces improves both the investment decision and the implementation that follows. The AI automation service and data integration service pages cover specific types of technology investment where this framework applies directly.
