My LinkedIn headline says “You’re asking AI the wrong questions”. It is a slightly cheeky line, but I mean it. When I talk to business owners about AI, almost all of them are asking it to write emails, tidy up proposals and summarise documents. Those are reasonable requests. They are also the least valuable things you can do with the technology, and they steer you away from the question that actually matters: which of your processes should not involve a human at all?
I’m Wayne George, a software engineer in London. I have spent more than a decade building bespoke control systems for large corporate clients, and in 2024 I founded Frontier Consulting to build custom software and AI systems for UK businesses (some of it is on the work page). What follows is the reframing I would rather we started with.
The questions everyone asks
“Write me a follow-up email.” “Summarise this contract.” “Draft a job advert.”
There is nothing wrong with any of these. They save minutes, and minutes add up. But look at what they have in common. In every case a person opens a tool, types a request, reads the answer, edits it and does something with it. The person is still the engine. The work still happens at the speed of one human’s attention, and it stops when they go on holiday.
That is AI as a slightly better keyboard. It makes your existing process a bit faster without changing its shape. If you run a business, the shape is the problem.
The question worth asking
The question I would rather you asked is this: which of our processes should not involve a human at all?
Not “how can AI help my team with their work?” That framing assumes every task deserves a person and just needs a bit of help. Most businesses are full of tasks that do not deserve a person. They got one because, at the time, a person was the only option.
Think about what a human is genuinely for in a business. Judgement. Relationships. Noticing that something is off. Deciding what to do when the rules run out. Those things are worth a salary. Re-keying numbers from one system into another is not; nor is reading forty near-identical enquiries to work out which ones deserve a quote.
The real value of AI, used alongside ordinary software, is that it lets you take whole processes off people’s desks rather than shaving minutes off each step. That only happens if you go looking for processes instead of prompts.
Start from the outcome, not the tool
Here is how I reframe it in practice. It is deliberately unglamorous.
Find the Friday spreadsheet
Every business has one. It is the report somebody compiles every Friday afternoon by copying figures out of three places into a fourth. It is the quote that takes three days because it queues behind the one person who knows how to price it. It is the invoice chase, the timesheet reconciliation, the supplier order that starts as a photo of a whiteboard.
You are looking for work with three properties. It has the same shape every time. The information it needs already exists somewhere, usually in an email, a PDF or another spreadsheet. And it spends most of its life waiting for a person rather than being worked on.
Do not start with “what could AI do here?” Start with “what do we do that nobody would miss doing?” Ask your team. They know exactly which jobs they resent, and resentment is a surprisingly good signal.
Map the inputs and outputs
Take one candidate and write it down, in plain words, as it happens today.
Where does the information come from, and in what form? An email with a PDF attached. A phone call scribbled on a pad. What comes out the other end, and who consumes it? A quote as a PDF. A row in a spreadsheet. What does “done” look like, and how would you know if it had gone wrong?
Then, crucially, list the exceptions. The enquiry with no measurements. The customer on stop. The supplier price that has changed since the list was last updated. Exceptions are where the humans currently earn their keep, and they tell you precisely where a human should stay.
Most people skip this step because it feels like admin. It is the whole job. Once the process is on paper, the technology decisions become almost obvious.
Decide where a model belongs and where plain software belongs
This is the part that gets muddled, because “AI” has become shorthand for all software. It is not, and the distinction matters for cost, reliability and how far you can trust the result.
Plain software is deterministic. Given the same input it produces the same output every time. It is cheap to run, easy to test, and it does arithmetic without ever being confidently wrong. If the input is already structured and you can write the rule down, that is what you want. Pricing a job from a rate card. Moving a row from one system to another. Generating a PDF from a template. None of that needs a language model, and using one for it makes the process slower, dearer and less predictable.
A language model earns its place at the messy edges. When the input is free text, a scanned document, a photo or a voice note. When the task is to read something written by a human and work out what they meant. When the output needs to be written in sentences rather than filled into fields. That is the part plain software has never been able to do.
So the shape of almost every good automation is a pipeline. A model at the front, turning messy human input into structured data. Plain software in the middle, applying the rules and doing the sums. Plain software at the back, producing the document or the message. And a person at the exceptions, looking only at the cases where judgement is needed.
I used the same split when I compiled Grin: A Brief Story, a history of a cryptocurrency assembled from forum archives spanning 2018 to 2025 (I wrote up how). Pulling the posts out through the forum’s API and scoring the topics was ordinary scripting. Reading the ones that scored well and drafting chapters was where the model did work no script could. And the judgement about what the score had missed came from me, and then from the people who had lived through it once the draft was published.
A worked example
Let me make this concrete with an imaginary firm. None of the details are real; the pattern is.
Imagine a twelve-person joinery business in Kent that makes fitted wardrobes and kitchens. Enquiries arrive by email: a few paragraphs of description, some rough measurements and a handful of phone photos. The owner reads each one, works out what is being asked for, checks sheet material prices in a supplier spreadsheet, applies labour rates that mostly live in his head, and types up a quote in Word. Because he also runs the workshop, a quote takes about three days, and a fair number of customers have gone elsewhere by then.
Map it. The inputs are an email (free text and photos), a supplier price list (a spreadsheet), the firm’s labour rates (undocumented, so the first job is to write them down) and a folder of past quotes. The outputs are a PDF quote, a reply email and a new row in the jobs spreadsheet. The exceptions are enquiries with missing measurements, unusual materials, and anything structural that needs a site visit.
Now decide. Reading the email and photos and turning them into a structured job description, with rooms, dimensions, materials, finish and deadline, is model work; nothing else can do it. Pricing that structured job against the price list and the labour rates is arithmetic, so it is plain software, and it will be right every time. Producing the PDF and the covering email is templating, plain software again.
Spotting that measurements are missing is a simple check, and drafting the polite email that asks for them is a small model task. The one place a person stays is at the end, reviewing the priced quote for a minute before it goes out. Is this a job we want? Is the margin right? That minute of judgement is what the owner is actually for.
In our imaginary firm, a quote is ready for review within the hour instead of three days, and the owner’s involvement drops to a few minutes per enquiry. Nobody asked a chatbot to write anything. The process changed shape.
Where it goes wrong
Three mistakes come up again and again.
Asking the model to do the sums. Language models are not calculators, and using them as one is how you end up with a confident, plausible, wrong quote. Do the maths in code and let the model do the reading.
Automating something nobody has written down. If the process only exists in one person’s head, the first deliverable is a description of it, not software.
Removing the human from the judgement step first. It is tempting to start with the interesting bit, the decision. Do the opposite. Take away the re-keying and the reading and leave the person the decision, at least to begin with. Trust in a system is earned by watching it get the boring parts right.
What to bring
The three steps above are the whole conversation, and none of them need a laptop open. Come with a process rather than a tool. Not “we are thinking about AI”, but “every Friday somebody spends two hours copying figures out of three systems into a fourth, and here is how they do it, step by step, including the bit where they have to ring someone”.
Twenty minutes of that is enough to get somewhere useful. What you want at the end is a short list of candidate processes, a rough view of which parts are plain software and which genuinely need a model, and a sense of which one to do first. The first one is almost never the most exciting. It is the one with the clearest inputs and outputs and the most people quietly furious about it. That is the one that pays for the next.
If you run a UK business and you recognise your own Friday spreadsheet in any of this, you can book a free 20-minute strategy session with Frontier Consulting: no obligation and no sales pitch. If you would rather start smaller, the free discovery test on the Frontier Consulting site is three questions and takes about two minutes. Either way, bring the process, not the prompt.