A consultant once told a 12-person logistics firm their digital transformation was 'on track'. The evidence: 94% of staff had logged into the new platform, and ticket volume was down 30%. Nobody asked what the firm was earning that it had not earned the year before. Fourteen months in, revenue was flat, headcount was flat, and the software bill was up £41,000.
Login rates are not returns. Ticket volume is not a return. The reason so many digital transformation programmes feel vague is that almost nobody defines, before starting, what number is supposed to move.
Here is a way to fix that in an afternoon.
Measure the hours, then price them
Every digital transformation claim eventually reduces to one of three things: the work takes less time, the work produces more revenue, or the work stops going wrong. Time is the easiest to measure, so start there.
Pick one process. Not 'marketing'. One process, with a start and an end. For example: publishing a weekly customer newsletter, from first draft to send.
Time it honestly for two weeks before you change anything. Not the ideal run. The real one, including the twenty minutes hunting for last quarter's figures and the Friday where you rewrote the subject line four times. Most operators discover the real number is two to three times their estimate.
Then multiply by what an hour of your time is worth. If you are a solo operator billing £90 an hour, and the newsletter takes 4.5 hours a week, that process costs £405 a week, or roughly £21,000 a year. Now you have a baseline that a tool has to beat.
This single step kills more bad software purchases than any procurement process. A £200-a-month tool that saves 40 minutes a week on a £21,000 process is a clear yes. The same tool applied to a process worth £1,800 a year is a clear no, no matter how good the demo was.
Four numbers, one scorecard
Once the baseline exists, judge every transformation initiative against four numbers. Together they form a scorecard you can update monthly in a spreadsheet.
1. Hours returned. Baseline hours minus current hours, per week. Track it for a full month after adoption, not the first week. The first week is always worse because you are learning.
2. Throughput. Units of output per week. Newsletters sent, proposals issued, support tickets closed, invoices raised. Automation often does not reduce your hours; it raises what those hours produce. If you still spend 4.5 hours on content but publish nine pieces instead of three, that is the return.
3. Error cost. How much rework, refunds, or apology emails the process generated. A B2B services firm found their proposal process took the same time after automation, but the rate of proposals containing wrong pricing dropped from one in six to one in forty. At an average deal size of £6,000, that was the whole business case on its own.
4. Total cost of the change. Subscription, plus setup hours, plus the ongoing hours you spend maintaining prompts, templates, and integrations. That last one is where honesty usually breaks down. Budget maintenance at 15% of the time the tool saves, and revisit after 90 days.
ROI is then simply: (value of hours returned + value of throughput gain + error cost avoided) minus total cost, divided by total cost.
Set the measurement window before you start
Two months is too short and two years is too long. Ninety days is the window that works for most SMB transformation projects, because it covers the adoption dip, the plateau, and one full cycle of whatever you produce monthly.
Write down the target before day one. Something like: 'By 31 March, the newsletter process takes under 90 minutes a week and output rises to two sends, at a total tool cost under £250 a month.' Then, on 31 March, you either hit it or you did not. No interpretation required.
The discipline here matters more than the precision. A rough number you committed to in advance beats an accurate number you calculated afterwards to justify a decision you had already made.
The metrics that lie
Some numbers look like progress and are not. Watch for these.
- Adoption rate. People logging in proves procurement worked, not that the business changed.
- Volume of automations built. A firm with 60 Zapier workflows and no change to margin has built a hobby, not a transformation.
- Time saved, self-reported. Ask ten people how much time a tool saved them and you will get ten optimistic guesses. Use timestamps, not opinions.
- Cost per unit, in isolation. Cutting your cost per blog post from £300 to £15 means nothing if none of those posts bring in customers. Pair every efficiency metric with an outcome metric.
The pattern is the same in each case: activity metrics are easy to collect, which is exactly why vendors and consultants lean on them.
A worked example
A solo consultant automated her content pipeline. Before: 6 hours a week on research, drafting, and scheduling across three channels, producing four pieces. After 90 days: 2 hours a week, producing eleven pieces.
Hours returned: 4 per week, at a £120 billable rate, or £480 a week. Throughput: up 175%, which produced 3 extra inbound enquiries a month at a 30% close rate and £4,000 average value, so roughly £3,600 a month in new pipeline value. Error cost: negligible either way. Total cost: £180 a month in tooling plus 3 setup hours plus about 35 minutes a week of maintenance, call it £500 a month all in.
Return: well over 10x. But note what made it defensible. She knew the 6 hours because she timed it. She knew the enquiry lift because she tagged the source. Neither number required software to collect.
The takeaway
Digital transformation is not a programme you complete, it is a series of bets you can price. Before you buy the next tool, time the process it replaces and write down the number it has to beat in 90 days. If you cannot name that number, you are not transforming anything. You are just shopping.