Most teams argue about software ROI with opinions instead of numbers. The feature list looks impressive, the invoice is real, and nobody can say what changed in the business.
This guide sets out a method that takes three steps and ninety days, with the research behind each step cited so you can check it yourself.
In this article
- What software ROI actually measures
- The 90-day method for measuring software ROI
- Which numbers to track
- What the research says about software value
- Why software ROI calculations go wrong
- Frequently asked questions
What software ROI actually measures
Software roi is the ratio between what a system returns and what it costs. The arithmetic is simple. The difficulty is that most companies measure only one side of it, and only once the money has already been spent.
The cost side is usually underestimated. Licence fees are visible, but three costs rarely make the spreadsheet: the hours your team spends learning the tool, the work of moving existing data into it, and the productivity dip during the first weeks.
The return side is usually unmeasured. If nobody wrote down the response time, the repeat purchase rate or the hours of manual entry before the project started, there is no way to prove a change afterwards.
The 90-day method for measuring software ROI
Step 1: Pick one number before you buy
One number, chosen because it sits close to revenue. Average time to respond to a new enquiry. Share of customers who buy again within six months. Hours per week spent re-entering data between systems. If a tool cannot be tied to a number like this, that is useful information in itself.
Step 2: Record the baseline
Measure the number as it stands today, before anything changes, and write it down with the date. A rough figure taken consistently beats a precise figure taken once. Without a baseline, every later discussion about value becomes a matter of opinion.
Step 3: Compare after 90 days
Ninety days is long enough for the team to pass the learning curve and short enough to stop a bad decision before it becomes a sunk cost. Compare the same number, measured the same way, and write down the difference in money terms.
A worked example: a distributor measures that quotes take 26 hours on average to reach the customer. After a quoting tool goes live, the figure is 4 hours. If faster quotes convert even two extra orders a month, the software ROI calculation is a straightforward comparison between those orders and the monthly cost of the tool.
Which numbers to track for software ROI
Five families of metrics cover most business software. Choose one, not five:
- Speed of response. Time from enquiry to first human reply.
- Retention. Share of customers who return within a defined window.
- Throughput. Orders, tickets or jobs completed per person per week.
- Manual effort. Hours per week spent on re-entry, reconciliation and chasing.
- Error cost. Money lost to wrong prices, wrong stock or missed appointments.
For a custom build rather than an off-the-shelf tool, the cost side of software ROI also depends on how the estimate was produced. Our guide to software project estimation explains where estimates usually go wrong.
What the research says about software value
The link between software capability and financial performance is well documented. McKinsey surveyed 440 large enterprises and found that companies in the top quartile of its Developer Velocity Index grew revenue four to five times faster than those in the bottom quartile between 2014 and 2018, with 60% higher total shareholder returns and 20% higher operating margins.
The cost of getting it wrong is documented too. Stripe’s Developer Coefficient report found that developers spend around 42% of their time on maintenance and dealing with bad code. The Standish Group’s CHAOS Report puts the share of software projects that succeed on time, on budget and to expectation at roughly 31%.
Speed of response is the mechanism with the clearest evidence. A study of 2.24 million leads published in Harvard Business Review found that companies responding within an hour were nearly seven times more likely to qualify the lead than those responding an hour later, and sixty times more likely than those waiting 24 hours.
Why software ROI calculations go wrong
Four failure patterns account for most disappointing results:
- No baseline. The number was never recorded before launch, so the comparison is guesswork.
- No owner. Nobody is responsible for keeping the data current, so the system drifts out of date.
- Double entry. The tool does not connect to existing systems, so staff maintain both and quietly abandon one.
- Measuring too early. A judgement made at week two captures the learning curve, not the result.
None of these are technical problems, which is why buying a better product rarely fixes them. The software ROI question is as much about operating discipline as it is about the system you choose.
Software roi for a custom build
Custom development changes the shape of the calculation, not the method. The cost is larger and arrives earlier, and the return depends on whether the process being automated is genuinely specific to your business.
A practical rule: buy when your process matches the market, build when your process is the advantage. If an off-the-shelf tool forces your team to work in a way that loses you customers, that loss belongs on the cost side of the comparison.
If you are pricing a build, our page on software outsourcing rates in Vietnam gives published starting rates you can use as a reference point before speaking to any vendor. For the broader business case, we also published a Vietnamese-language analysis of how software generates revenue for a business.
Who should own the measurement
A measurement without an owner quietly disappears. In a small company the owner is usually the person who feels the pain: the sales lead for response times, the operations manager for manual effort, the finance lead for error costs. In a larger organisation it is whoever already reports that number to the board.
The owner has three jobs, and none of them are technical. They record the baseline before launch. They keep the measurement method identical over the ninety days, because a change in how you count looks exactly like a change in performance. And they are allowed to call the project off, which is what makes the exercise honest rather than ceremonial.
It also helps to agree in advance what counts as success. A number that moves by two percent may be noise; a number that moves by a third is a result. Writing the threshold down before launch removes the temptation to rewrite the goal once the invoice has been paid.
A short worked example
A 40-person wholesaler receives enquiries by email, phone and chat. Nobody can say how many enquiries arrive each week, so the first measurement is simply a count: 120 enquiries, of which 31 never receive a reply.
The baseline is a 26% drop rate. The team adopts a shared inbox with assignment rules, costing a modest monthly fee plus two days of setup. After ninety days the drop rate is 9%, which is roughly 20 recovered enquiries a month. At their average order value and close rate, that is the equivalent of one and a half extra orders a month.
Notice what is absent from this example: a list of features, a comparison of vendors, and any claim that cannot be checked in the company’s own records. That is the whole point of the method.
Frequently asked questions
How do you calculate software ROI?
Pick one business number the software is meant to move, record its value before launch, then compare after 90 days. Divide the gain (extra revenue or saved cost) by the total cost of the software, including licence fees, training time and internal hours.
How long should you wait before measuring software ROI?
Ninety days is a practical window. The first weeks are a learning curve when output often drops, and anything beyond a quarter makes it hard to separate the software from other changes in the business.
Why do software investments fail to show a return?
Usually for organisational reasons rather than technical ones: no baseline was recorded, nobody owns the process, the tool was bought for a problem the business does not have, or staff keep entering the same data twice.
In short: software ROI becomes measurable the moment you pick one number, write down its value today, and agree to look again in ninety days. Which number would decide it for your team?
