Power Apps ROI: the number you cannot recover

Read Microsoft’s guidance on measuring the business value of Power Platform solutions and one structural fact emerges from almost every measure it lists.

Time and cost savings: compare the time taken to complete a task before and after automation. Error reduction: track the number of errors before and after implementation. Productivity: compare output achieved before and after. Risk reduction: track incidents related to those risks before and after. Compliance, incident response time, efficiency, revenue, employee satisfaction. All of them, before and after.

Which means the hardest part of Power Apps ROI is not the arithmetic. It is that half the inputs describe a state that stops existing the moment you deploy. Miss the baseline and the step change from manual to automated is gone for good, and what most teams produce in its place is an estimate presented as a measurement.

There is a recoverable position, and it is further down. It is just not the one people reach for first, which is to reconstruct the past from memory.

The four value drivers

Microsoft groups the value a solution can deliver into four, and they are worth using as written because they map to different audiences and different evidence.

There is a separate set of benefits Microsoft attributes to IT rather than to any individual solution, and these are the ones most often left out of a business case: reduced development and maintenance costs, reduced non-Microsoft licence spend, and reduced technical debt. The middle one is worth pursuing explicitly, because displaced third-party licences are a real, invoiced number that finance can verify without any modelling.

Tangible, intangible, and why you need both

Microsoft draws the line clearly:

The temptation is to report only the left column, because it survives contact with a finance review. In our engagements that is a mistake, and a predictable one: a business case built solely on hours saved invites the response that the hours were not actually removed from anyone’s cost base, which is often true and always awkward.

The stronger position pairs them. Hours saved is the tangible claim; what the team did with the time is the intangible one, and Microsoft’s own suggested question is exactly that: what would you do with the time freed up? Asked before the build, it produces a much better answer than asked afterwards.

Beyond the main drivers there is a longer list worth knowing exists, because one of these is usually the thing a specific executive actually cares about: brand reputation, employee skills and capabilities, innovation, time to market, competitive advantage, employee satisfaction, diversity and inclusion, accessibility, and environmental sustainability.

The framework, and the step everyone inverts

Microsoft’s measurement framework has four steps: centralise objectives and goals, identify relevant metrics, collect and analyse data, then report and present.

The metric guidance is usefully concrete. Use metrics expressed as time, rate, scale, number or percentage, and Microsoft’s worked example is the right shape: *reduce health and safety incidents by 50% over the next twelve months*. A target, a magnitude and a period. Not “improve safety”.

Note where that sits in the sequence: objectives and metrics come before data collection, which comes before reporting. The adoption strategy guidance orders it the same way, putting define vision, metrics and goals at step two of six, ahead of everything about delivery.

Almost every organisation inverts this. The app gets built because someone had a problem, and the value conversation begins when a budget review asks what the platform has delivered. By then step one has been skipped, the metric was never defined, and nobody measured the before state because there was no metric to measure it against.

How often it actually happens, and what to do when it did not

The honest number: in our engagements fewer than 10% to 15% of Power Platform projects capture a rigorous baseline before development begins. Most teams start building as soon as the problem is identified, which is a reasonable instinct and an expensive one.

So the interesting question is not how to do it properly. It is what to do for the other 85%.

Do not reconstruct the past. Asking people to remember how long something used to take, or going digging through email archaeology for evidence of the old process, produces numbers that cannot be defended the first time anyone challenges them. They are recollections with decimal places, and a finance reviewer will treat them accordingly.

Measure forward instead. Where no baseline exists, establish a 30 day calibration window at initial rollout and capture the current operational velocity, error frequency and cycle times as a fixed benchmark. You are not measuring the old process, which is gone. You are measuring the new one at its starting point, before adoption matures and before anyone has optimised anything.

That window is a genuine recovery rather than a consolation prize. It gives you a defensible number with a date attached, and every subsequent improvement is measured against something that was observed rather than remembered. What it cannot tell you is the size of the initial step change from manual to automated, and that specific number is simply lost.

Different audiences want different numbers

The part of Microsoft’s guidance most likely to change how a Power Platform lead behaves is not about measurement at all. It is about who you are talking to.

• IT cares about cybersecurity, scalability and technology adoption
• Finance cares about cost savings, financial return and investment justification
• Marketing cares about customer engagement and brand reputation
• Operations cares about process efficiency, productivity and reduced downtime

One set of measurements, four presentations. The recommended approach is to analyse the audience first: who the stakeholders are, what is relevant to their role, how they prefer to receive information, what their interests and concerns are, and what level of technical detail matches their understanding.

This is why a single value dashboard rarely lands. It is usually built for the team that made it, which is IT, and then shown to finance, who want a different number expressed in a different unit.

The toolkit problem

Microsoft recommends a Business value toolkit for capturing and communicating solution value, and it is a genuinely well-designed thing: it lets you specify objectives and goals, then guides app owners through a structured process to analyse their solution’s impact against strategic objectives.

It is also a feature of the CoE Starter Kit, which Microsoft’s own documentation states is no longer actively maintained, with issues no longer reviewed or addressed.

The value page recommending it was updated on 29 August 2026. So this is the second place we have found Microsoft’s current guidance pointing at a retired component, after the governance guidance doing the same thing. It is not a criticism of the toolkit, which still works. It is a warning about building a permanent value-measurement process on top of something with no maintenance path, and it means the process matters more than the tool: capture the objectives, metrics and baseline somewhere you own, and treat the toolkit as a convenience rather than the system of record.

Our position: measure before you build, or do not claim a return

Our position is that the baseline is the deliverable, and it should be captured before the first screen is designed.

That is not a governance preference, it is arithmetic. Every measure in Microsoft’s own guidance is a comparison against a prior state, and the prior state is destroyed by the thing you are trying to evaluate. Nobody can reconstruct how long a process took last quarter once the process no longer exists in that form. What gets produced instead is an estimate presented as a measurement, and finance can usually tell the difference.

So we would not start a gated Power Platform build without a one-page answer to three questions: what is the objective, what is the metric expressed as a time, rate, number or percentage, and what is the current value of that metric. It takes an hour, and it is the difference between a demonstrated return and a claimed one.

And where that hour was never spent, the answer is the calibration window above rather than an apology. A benchmark observed 30 days after rollout is worth considerably more than a historical figure reconstructed from memory, even though it measures less.

The counterweight, in fairness: not everything needs this. A small app that removes an obvious annoyance does not warrant a measurement programme, and demanding one is how governance becomes the reason nothing gets built. The rule we apply is that anything you will later need to defend needs a baseline, and anything you would happily switch off without a business case does not. Those apps can be tracked by usage alone, although usage is not the same thing as effective adoption once you look across the whole estate.

The threshold, so this does not become bureaucracy

Baseline capture should strictly gate project kick-off, but only above a defined operational threshold. Gate every minor canvas app and governance becomes paralysing. Gate none of the business-critical ones and you have guaranteed an unprovable business case on exactly the work that will be questioned.

The line we use:

For anything on the right, the sprint does not start until the project team has documented three immutable numbers:

1. Current cycle time, in hours
2. Error and rework rate, as a percentage
3. Labour hours per week spent on the manual process

Three numbers, one page, before the first screen. That is the whole gate, and it is deliberately small enough that arguing about it costs more than doing it.

Where to start

Pick the Power Platform solution most likely to face a budget question in the next twelve months. Then write the three lines: objective, metric, current value.

If you cannot fill in the third line, you have found the work. Measure it now, before anything changes, because today is the earliest the baseline will ever be recoverable and it gets worse from here.

Then decide who the number is for, and express it in their unit rather than yours. The same discipline applies to how the platform itself is bought. A managed service has a before state too, and it stops existing the day the service starts.

Veratas runs Power Platform engagements and, for estates under managed services, value measurement is part of the operating rhythm rather than a report produced under pressure.

If you are being asked what the platform has returned and the honest answer is that nobody measured the before, talk to our team. That is a recoverable position, but only for the solutions you have not built yet.

Frequently asked questions

How do you calculate Power Apps ROI? By comparing a defined metric before and after implementation. Microsoft’s measures are all before-and-after comparisons: time and cost per task, error rates, output volumes, incident counts, compliance rates and response times.

What if we never captured a baseline? You cannot calculate a return for that solution, only estimate one, and it is worth saying so rather than presenting an estimate as a measurement. Capture baselines for everything not yet built, starting now.

What metrics does Microsoft recommend? Metrics expressed as time, rate, scale, number or percentage, with a target and a period. The worked example is reducing health and safety incidents by 50% over twelve months.

Which Power Platform projects actually need a baseline? Those crossing an operational threshold: 50 or more active users or crossing departmental boundaries, requiring premium licensing or a build budget over roughly $15,000 to $20,000, or replacing an auditable, regulated or revenue-impacting workflow. Personal productivity helpers and single-user automations under five developer days need only adoption counts.

What three numbers should a gated project document before starting? Current cycle time in hours, error and rework rate as a percentage, and labour hours per week spent on the manual process. One page, before the first screen.

Should we report intangible benefits? Yes, alongside tangible ones. A case built only on hours saved invites the objection that the hours were never removed from the cost base. Pair the hours with what the time was redirected to.

Why does our value dashboard not land with finance? Because it was probably built for IT. Microsoft’s guidance is to analyse the audience first: finance wants cost savings and investment justification, operations wants process efficiency and downtime, marketing wants engagement and brand.

Should we use the Business value toolkit? It works and it is well designed, but it is part of the CoE Starter Kit, which Microsoft states is no longer actively maintained. Keep your objectives, metrics and baselines somewhere you own and treat the toolkit as a convenience rather than the system of record.

Anuj Kumar Mishra

Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.