Every few weeks an owner tells me a system "paid for itself" or "was a waste of money," and when I ask how they know, the answer is a feeling. Not a number, a feeling. That is the core problem with how most businesses judge software: they never wrote down what the situation was before they spent the money, so they can never honestly say what changed.
Technology investment roi is not mysterious and it is not only for big companies with finance teams. It is measurable, but only if you do one unglamorous thing first: baseline the current process before you build anything. Skip that step and every later claim about value is a guess dressed up as a fact.
This piece gives you a simple model you can run yourself, on a page, before you approve any build. The goal is not academic precision. It is to stop approving projects on hope and to stop killing good ones on vibes.
Baseline before you build, or you cannot measure anything
Here is the trap. You buy a system, six months pass, business is a bit better, and you credit the software. But business also got busier, you hired someone, and a competitor closed. Which change caused what? Without a baseline, nobody can say, and the vendor will happily take the credit.
So before the project starts, measure the process the system will replace. Concretely, capture the current state in numbers:
- How many hours per week does this task consume, across which people?
- How many errors happen, and what does each error cost to fix?
- How much revenue is lost or delayed because the current process is slow?
- What are we paying today in tools, overtime, or workarounds?
Write these down and date them. This single page becomes the thing you compare against later. It is the most valuable half hour in the whole project, and almost nobody spends it.
The three places real technology investment roi comes from
Value from a system shows up in three buckets. Naming them keeps you honest, because vague benefits like "better efficiency" are where bad projects hide.
1. Hours saved
The most concrete bucket. If a task takes two people ten hours a week, and after the system it takes one person two hours, you saved eighteen hours a week. Convert to money at a real loaded cost per hour. Eighteen hours a week at a modest rate is well over a hundred million rupiah a year of freed capacity. That number is defensible because it started from a measured baseline.
2. Errors avoided
Every manual process leaks. Wrong stock counts, double entries, mispriced invoices. Each has a cost: the rework, the refund, the angry customer. If you counted these in your baseline, you can now count the reduction. Avoided errors are often the quietest and largest source of return, precisely because they were never on anyone's report before.
3. Revenue enabled
The hardest to measure and the easiest to overclaim, so treat it strictly. Did the system let you serve customers you genuinely could not before? Faster quotes that won deals you can name? Be conservative here. Count revenue you can trace, not revenue you hope for.
A worksheet you can run in an afternoon
Put the numbers into a simple frame. Here is the shape, with plausible figures for a mid-sized Indonesian SME automating an order and inventory process.
| Line | Amount (per year) |
|---|---|
| Cost of the current process (hours + errors + workarounds) | Rp 180,000,000 |
| One-time cost of the system (build, setup, training) | Rp 120,000,000 |
| Ongoing cost of the system (hosting, maintenance, support) | Rp 40,000,000 |
| Annual value returned (hours saved + errors avoided + revenue enabled) | Rp 150,000,000 |
From those lines you get the two numbers that matter:
- Payback period: one-time cost divided by annual net benefit. Here, 120M divided by (150M minus 40M) is roughly 13 months.
- Ongoing return: after payback, the system nets about 110M a year against 40M of running cost.
A 13-month payback with a solid ongoing return is a good investment. But notice you can only produce these numbers because the baseline existed. Without the first row measured up front, this whole table is fiction.
Beware the soft-benefit-only justification
The most dangerous pitch, and the one I push back on hardest, is a project justified entirely by soft benefits. "It will improve morale." "It positions us for the future." "Everyone else is doing it." These may be true, but they are unfalsifiable, and unfalsifiable justifications are how budgets disappear.
My rule is simple: a technology investment needs at least one hard, measured benefit as its spine. Soft benefits are welcome as bonus reasons on top. They are not allowed to be the whole case. If a project cannot point to hours saved, errors avoided, or revenue enabled, that is a signal to shrink it, delay it, or drop it, not to approve it on faith.
This discipline is the same reason I argue that a business needs a real technology strategy, not just a website. Strategy is what keeps your spending pointed at measurable outcomes instead of shiny objects. It also pairs naturally with setting technology goals for the new year that actually stick.
Practical takeaway
Technology investment roi becomes real the moment you commit to measuring the before, not just admiring the after.
- Baseline first. Measure current hours, errors, and lost revenue, and date the page. No baseline, no ROI, only stories.
- Attribute value to three buckets. Hours saved, errors avoided, revenue enabled. Count each conservatively.
- Compute payback and ongoing return. A clear payback period beats a hundred slides of vision.
- Demand one hard benefit. Soft benefits ride along; they never drive.
Run that worksheet before you sign, and you will approve fewer projects but win far more of the ones you do. If you want a second pair of eyes on the numbers before committing, that is exactly the kind of review I do as a technology partner.