Is our software too old for AI? A 5-minute test.

“Everything here is ancient” — sound familiar?

It's the sentence we hear before almost anything else: the booking system went in over a decade ago, the accounts package looks like it did in 2008, half the real work happens in a spreadsheet someone built years ago and nobody dares touch. So the assumption follows naturally — AI is for companies with modern software, and we're not one of them.

It's a reasonable assumption. It's also usually wrong, and you can check it yourself right now. Pick one task in your business — invoicing, taking bookings, chasing paperwork, copying orders from one place to another — and run it through the five questions below. Each is a straight yes or no.

The 5-minute test: five yes/no questions

1. Can a person do this task just by reading what the system shows and typing into it?
This is the big one. If a member of staff can do the job with their eyes and a keyboard — read the screen, read the email, fill in the fields — then the task doesn't depend on any special connection to your software. It depends on reading and typing, and modern AI can do both. Notice what the question doesn't ask: when the software was installed.

2. Does the system produce anything — a printout, an export, an email, a report?
Anything at all. A daily report, a CSV export, a confirmation email, even a printed job sheet. If information comes out of the system in some form, AI has something to work from. Systems that produce nothing whatsoever are rare — most "ancient" software is actually generous with printouts and exports, because that's how people used it.

3. Could you describe the rules of the task to a new employee in an afternoon?
"If the customer asks for a price, look it up here. If the job is outside our area, say no. If the total is over this amount, check with the boss." If you can explain a task that way in an afternoon, it has rules — and a task with rules can be automated and, just as important, checked. If nobody in the building can explain the rules, that tells you something too. We'll come back to it.

4. Is there a repetitive task your team dreads?
This question isn't about feasibility — it's about whether it's worth doing. The tasks people dread are almost always the same ones: high volume, low variety, done under time pressure, easy to get slightly wrong at 5pm. Dread is a surprisingly good measure of value. If the answer is yes, automating it will be felt on day one.

5. Could the result be put back into the business the same way a person would do it?
When the task is done, where does the answer go? If a person would type it into the system, email it to a colleague, print it for the driver, or add it to the diary — then the result can be delivered the same way, without changing anything about how your business runs. The output doesn't need a special route in; it can use the route you already have.

How do you score it?

Mostly yes: AI can attach to what you run. Three or more yeses — and especially a yes on questions 1 and 2 — means the task is a genuine candidate, and your software is not the obstacle you thought it was.

Now look back at the five questions and notice what never came up: the age of your software. Not once. No question asked what year it was installed, whether it has an API, whether the vendor still exists, or whether it runs on a machine in the back office that nobody is allowed to switch off. That's the point of the test. The things that decide whether AI can help are about the task — can it be read, does it produce something, does it have rules, is it worth doing, can the result go back in. Old software passes those questions just as often as new software does. We've written more about why in our guide to AI automation on old systems.

Why are we comfortable around old kit?

Because we started there. Future Networks came from the hardware side — years spent building RTK networks, wireless systems, and dashcam, mapping and geolocation technology, long before we were an AI consultancy. That work is almost entirely about attaching modern software to equipment that was never designed for it, and making the join reliable enough to leave running. When we moved into AI, the habit came with us: don't demand that the client modernise first — build the new thing to fit what's already there.

What does this look like in real life?

Our clearest example is the taxi trade. Plenty of UK taxi operators run dispatch software that's been in place for years. We built DM Taxi Assistant, an AI booking assistant that works across the operator's website chat, WhatsApp and social channels — it quotes the fare, books the job, takes card payment through Stripe, and hands the confirmed booking to the operator's existing dispatch.

Here's the part that matters for this article: for version one we deliberately did not integrate with any dispatch system's API. The assistant captures and confirms the booking, then hands it off the way the operator already works. That one design decision meant any operator could go live no matter how old their dispatch software is — the dispatch system didn't change at all. Run that through the test: a person could take the booking by reading and typing (question 1), the result goes back into the business exactly the way a person would put it there (question 5). The age of the dispatch software never entered into it. If you're wondering how software connects to software without a formal integration, we've answered that in full in Does AI need an API?

One operator, Matthew McElhinney, put the effect plainly: “I can now do a week's worth of work in a day.”

The same thinking runs through Olly, our product for tradespeople: a WhatsApp voice note becomes a branded PDF quote or invoice, synced to Xero or QuickBooks. On the tradesman's side there's no API at all — his "system" is WhatsApp and his own voice. The only formal integration in the whole build is on the accounting side. His kit couldn't be less modern, and it makes no difference.

What honestly fails the test?

The test is only useful if some things fail it, so let's be straight about what does.

• A task nobody can describe the rules for. If question 3 gets a no — if the person who does the job can't explain how they decide, and neither can anyone else — the task isn't ready to automate. Not because the software is old, but because there's nothing written down to automate. Sometimes the fix is simply to write the rules down first; sometimes the "rules" turn out to be one person's accumulated judgement.
• A decision that is pure judgement. Whether to take on an awkward customer. How to handle a complaint from your biggest account. Whether a price feels right for a job you've never quoted before. These stay human, and they should. The honest goal of automation is to clear the repetitive work around those decisions so the person making them has time to make them well.

Notice that both failures are about the task, not the technology. Even here, the age of your software never comes up.

Where do you start?

If the test came back mostly yes for one or two tasks, the next step isn't a rebuild and it isn't a big project. It's an audit: we sit down with you, find what's worth automating in the systems you already run, and then our in-house developers build it — that's the whole model at Future Networks. Every automation is tested on your real cases before it goes live, decisions above a threshold you set wait for a human, and every action is logged. Bring the task your team dreads most — it's usually the right place to begin.