“Will it pay for itself?” is the right question to ask of any software project, and too often it is answered with optimism instead of arithmetic. Measuring the return on going digital does not need a finance degree or a consultant’s spreadsheet. It needs a clear baseline, an honest list of costs and a handful of benefits you can actually count. Here is the method we use.
Start with a baseline, before anything changes
You cannot measure improvement without knowing where you started. Before any work begins, spend two to four weeks recording how the current process performs. Keep it simple: a tally sheet, timestamps from your email or a quick export from your accounting system is usually enough.
- Time per task — how long it takes to raise an order, issue an invoice or approve a request.
- Volume — how many of those tasks happen each week or month.
- Error rate — corrections, credit notes, returns and rework caused by mistakes.
- Speed to cash — the average number of days between invoice and payment.
Agree these measures with your finance team before the project starts, and write them down. When everyone accepts the starting figures in advance, the conversation after launch is about results rather than arguments over whose numbers are right. It also stops the goalposts moving once the new system is live.
What to count on the benefit side
Benefits fall into a few buckets. Some are easy to put a number on, others need a conservative estimate. Count the hard ones in your main calculation and list the softer ones separately, so nobody can accuse the business case of wishful thinking.
Be careful with time savings. Hours saved only become money if they are used for something valuable, such as handling more orders without hiring, or moving someone to sales. Use a fully loaded hourly cost that includes salary, housing and visa costs, gratuity and benefits, not just basic pay.
Revenue benefits deserve the most caution. If a customer portal or online checkout lifts conversion, measure it against a clear before-and-after period and allow for seasonality, such as Ramadan, summer or year-end peaks. Where the link between the project and the extra sales is loose, leave the figure out of the headline and mention it as upside.
A business case built on hard numbers survives the first budget meeting. One built on hope rarely does.
Counting the costs honestly
The build or subscription price is only part of the picture. Include setup and data migration, integrations, staff time spent on workshops and testing, training, and a temporary productivity dip in the first month. Then add the running costs: licences, hosting, support and improvements, which in our experience come to roughly 15% to 20% of the build cost each year.
It is also worth costing the alternative of doing nothing. If order volumes are growing, the current process may soon need another hire at AED 8,000 to 12,000 a month in salary alone. Avoiding that hire is a legitimate benefit, provided growth is genuinely expected and not simply hoped for.
A worked example from a Dubai distributor
Take an illustrative distributor with three order coordinators retyping WhatsApp and email orders into their accounting system. A custom order portal connected to that system costs AED 110,000 to build and AED 20,000 a year to run. Each coordinator saves about ten hours a week, or 1,440 hours a year across the team, worth AED 86,400 at a loaded AED 60 an hour.
Credit notes caused by order errors fall from 40 to 10 a month. At an average cost of AED 150 each in staff time, goodwill and wasted delivery, that saves AED 54,000 a year. Total hard benefits come to AED 140,400 a year, against a first-year cost of AED 130,000.
So the project pays back in roughly eleven months. Over three years, benefits of AED 421,200 against total costs of AED 170,000 give a return of about 148%. Faster payments from customers ordering and paying online are a real extra benefit, but we would list them separately rather than inflate the headline figure.
Measuring again after launch
Repeat the baseline measurements three and six months after go-live, using exactly the same method. Expect a short dip in the first weeks while people adjust, then a steady climb. If the numbers fall short, look at adoption before blaming the software: workarounds and half-used features are the most common reasons a sound business case underdelivers.
The bottom line
Measuring ROI is less about formulas and more about discipline: honest baselines, conservative benefits and complete costs. Do it before you start to decide whether a project is worth it, and again after launch to prove it delivered. Projects that pass both tests earn the trust, and the budget, for the next step in your digital journey.
If you are weighing up a project now, start with the single process you suspect costs the most. Two weeks of measuring it will tell you whether a business case exists, roughly how large it is and how much you could sensibly spend to fix it, before a single line of code is written.
