A staff member at a Brisbane salvage operator had a job nobody should have in 2026: fill in a tow price for every suburb in Australia. All 15,319 of them.

The process was exactly what you'd picture. Look the suburb up on a map, work out the distance, do the mental arithmetic, type the price, next row. By the time I was brought in, 835 rows were done. That left more than 14,000 to go - weeks of work, with no consistency between entries, and every price already going stale because fuel costs don't sit still.

The insight that changed the job

Here's the thing that made this an afternoon's work instead of a six-week slog: the spreadsheet already contained the coordinates for every suburb.

Nobody needed to look anything up. The data was sitting in the file the whole time. This was never a data-entry problem - it was a calculation waiting to be automated. That one realisation is worth more than any tool, and it applies to more spreadsheets than you'd think.

What got built, in plain English

In one afternoon, I built a pricing engine that did the whole job properly:

Real road distances. Using free, open-source routing data (OpenStreetMap), the engine calculated the actual driving distance and drive time from the depot to every suburb - not straight-line guesses.
The business's own billing rules. Return trip, pick-up and drop-off allowances, and the 15-minute billing round-up, applied identically to every row.
True job costs, not just prices. Fuel by the truck's actual consumption, driver wages by the hour - so every suburb shows the profit margin, not just the charge. Below-cost jobs get caught before they're quoted, not after.
A control panel. Change the fuel price, the driver rate or the charge-out rate in one cell, and all 14,718 prices and margins reprice instantly.

The engine also did the data-quality work a human never would: it found 115 island localities and 486 rows that couldn't be sensibly priced, and cleared them out. Every remaining row has a real price behind it.

Software and API costs for all of this: zero dollars. It runs on open data.

The numbers

Doing the remaining 14,718 suburbs by hand, at roughly a minute each, works out to about 245 hours of staff time - call it $11,000 in wages at typical admin rates. And that buys you prices only: no margin visibility, no way to reprice, all of it obsolete the next time fuel moves.

The automated build took three hours end to end - a 30-minute discovery chat, a two-hour build, and 30 minutes of revisions - delivered the same day, for a $1,500 fixed fee. That's roughly a 6.3x return before you count the part manual work can never match: when fuel prices rise, repricing the entire national footprint is one cell edit, not another 245 hours.

To be straight about the maths: the 245-hour figure is an estimate at about a minute per suburb. If anything it's conservative - the staff member's real pace on the first 835 rows suggests longer.

Signs your spreadsheet should be a system

This wasn't a one-off. Most businesses have a version of the 15,000-row problem; they just haven't counted the hours. Three signs a spreadsheet is really a system in disguise:

Someone types the same calculation over and over. If a human is applying the same rule to row after row, that rule can be code.
The data to automate it already exists in the file. Coordinates, dates, rates, quantities - if the inputs are there, the lookups can go.
It goes stale when one input changes. If a fuel price rise means redoing the sheet, the sheet should be recalculating itself.

If any of those sound familiar, book a free chat and I'll tell you honestly whether your version is worth automating. If you'd like the full picture of where automation would earn its keep first, that's what my AI readiness audit is for.

Figures are from a real client project, anonymised. The manual-time estimate assumes about one minute per suburb - stated so you can judge it yourself. Routing data (c) OpenStreetMap contributors.