Where AI actually saves a small business time
AI is good at jobs that are repetitive, text-shaped and currently done by a person reading something and typing somewhere else. Reading invoices, sorting enquiries, drafting a first version, pulling figures out of paperwork. It is bad at anything where being occasionally wrong is unacceptable and nobody is checking. Start with one job that costs a person several hours a week, and keep a human on the end of it.
Start with the hours, not the technology
Most AI projects that go nowhere started with the technology. Someone saw a demonstration, liked it, and went looking for somewhere to put it. Projects that work start from the opposite end, with a job somebody in the business does not enjoy and cannot get out of.
So the first question is not which model to use. It is: what does a person here spend hours on every week that involves reading something and typing it somewhere else? That is where the time is, and it is nearly always more mundane than anything in the demonstration.
Four jobs where it genuinely pays
Getting figures out of paperwork. Invoices, delivery notes, timesheets, receipts. A person opens the document, finds six numbers and types them into a system. This is the most reliable win we see, because the input is structured enough to check and the saving is measured in hours rather than minutes.
Sorting and routing what comes in. Enquiries, support messages, job requests. Reading each one, working out what it is about and sending it to the right person is a real job that nobody has as their job. Sorting is also a forgiving task: getting it wrong sends an email to the wrong colleague, not to a customer.
The first draft of something. A quote, a job description, a reply that follows a familiar shape. Not the finished article, the version that saves someone staring at an empty page. The person still edits and still signs it off, and that is the point.
Answering questions about your own documents. Contracts, manuals, policies, past projects. Instead of someone searching for the file, then searching inside the file, they ask a question and get the answer with a link to where it came from. That last part matters. An answer you cannot trace is not an answer.
Where it does not pay
We talk clients out of AI more often than they expect. The cases where we usually say no:
- The job happens twice a month. Automating it will cost more than it saves, forever. Some tasks are meant to stay manual.
- Being wrong is not survivable. Anything where a mistake reaches a customer or a regulator unchecked. You can still use AI there, but only with a person approving each output, which changes the economics.
- The underlying process is broken. Automating a bad process gives you a faster bad process. Fix the process first. This is dull advice and it is usually the right advice.
- A simple rule would do it. If the decision is genuinely "if the amount is over five hundred pounds, send it to Sarah", that is not a job for AI. It is an "if" statement, and it will be right every single time.
The question to ask before automating anything
Ask: if this gets it wrong one time in twenty, what happens?
If the answer is that somebody notices and fixes it in a minute, proceed. If the answer is that a customer is invoiced incorrectly, or a decision goes out under your company's name, then either a person checks every output or you do not automate that step at all.
This one question sorts most ideas into the right pile, and it does it before anyone has spent money.
Keep a person on the end of it
The systems that survive contact with a real business are the ones where a person stays in control. In practice that means three things: the output is a suggestion until somebody accepts it, every decision can be traced back to the document it came from, and there is an obvious way to say "that is wrong" that actually goes somewhere.
It sounds like a compromise. It is the opposite. Confidence is what makes people use the thing, and traceability is what earns confidence. A system nobody trusts gets quietly worked around within a month, and you have paid for it either way.
What it costs to find out
You do not have to commit to a platform to learn whether this is worth doing. Take one job. Time how long it takes now, over a fortnight, honestly. Run a small pilot on that single job with real documents and real awkward cases, not a tidy sample. Then compare.
We price pilots as a fixed piece of work with a defined scope, because the point is to answer a question, not to start something open-ended. If the pilot says the saving is not there, that is a useful answer and a cheap one. Better to spend a little proving it than a lot assuming it.
What happens to your data
This is the question every client asks, usually last and slightly apologetically, and it deserves to be asked first.
Know before you start: where your documents are processed, whether anything you send is used to train someone else's model, how long it is retained, and who at your supplier can see it. These are all answerable questions with contractual answers. If a supplier is vague about any of them, that vagueness is the answer.
Our position is that your data stays yours, and we will put the specifics in writing for the setup we propose rather than asking you to take a general assurance.
Common questions
The one that takes a person the most hours and involves reading something and typing it somewhere else. Getting figures out of invoices and delivery notes is the most common starting point, because the saving is easy to measure and a mistake is easy to spot. Avoid starting with anything customer-facing.
In the work we do, it removes tasks rather than roles, and the tasks it removes are the ones nobody wanted. The systems that last keep a person making the decision and use AI to do the reading and the first draft. If a supplier is selling headcount reduction, ask them who checks the output when it is wrong.
It depends entirely on the setup, which is why it is worth asking before you start rather than after. Establish where your documents are processed, whether anything is used to train someone else's model, how long it is kept, and who can see it. All four have contractual answers. We put ours in writing for the specific setup we propose.
We normally start with a pilot on a single job, priced as a fixed piece of work with a defined scope, so you find out whether the saving is real before committing further. The full build is quoted after that, with the price agreed in writing before it starts. Pricing a whole programme before anyone has proved the first step is how these projects go wrong.
Almost certainly not. Most useful business AI is built on existing models, with your own documents and your own rules around them. Training a model from scratch is expensive, rarely necessary, and usually a sign that somebody has misdiagnosed the problem.
Where to go next
If you want a straight answer about your own situation, tell us what you are trying to do and we will say what we would do, including when the answer is that you do not need us. Start a conversation.