_ai_in_practice

Where should a small business actually start with AI?

An evaluation you can run in an afternoon. Where AI genuinely helps, where ordinary software or a process change is the better answer, how to pick one first project, and what being in control means in practice.

Start with the work, not the technology. Write down the processes your business runs every week, find the steps that are repetitive, the information that lives in too many places and the decisions that wait on someone being free, and pick one of those. That is the whole method. The rest of this article is how to do it in an afternoon without a consultant, and how to spot the cases where AI is the wrong answer.

The second thing to say is that “start with AI” is the wrong framing, and most owners sense it. Nobody needs AI. They need the renewals chased, the enquiries answered the same day and the month-end report done without losing a morning. AI is one of three ways to get there, alongside ordinary software and a change to the process itself, and it is often not the cheapest of the three.

An afternoon, a list and three highlighters

Block out three hours. Not a workshop, not a strategy day. Sit with whoever runs operations and write down the processes that happen more than once a week: taking an enquiry, quoting, onboarding a customer, chasing an invoice, producing the weekly numbers, answering the same questions by email. Aim for ten to fifteen. One line each, in plain language.

Then, for each one, mark three things.

  • Repetitive steps. The same action done by hand, over and over, where the only reason it needs a person is that nobody has connected the two systems involved. Copying details from an email into the CRM. Renaming and filing documents. Typing the same reply with two words changed.
  • Scattered information. The answer exists, but in four places: a shared drive, an inbox, a spreadsheet and someone’s head. Staff spend time finding it, or guess, or ask the one person who knows.
  • Slow decisions. Work that waits for a judgement, where the judgement is routine most of the time. Which of today’s enquiries deserve a call back. Whether a supplier invoice matches the order. Which jobs to schedule first.

You will end up with a list where some processes have no marks, most have one and a few have all three. The few with all three are where to look.

Where AI genuinely helps

AI earns its place where the work involves language, judgement on messy input, or finding the right thing in a pile. Those are the tasks ordinary software has always been bad at, because ordinary software needs every case spelled out in advance.

Drafting is the clearest example. A first draft of a reply, a quote cover note, a job advert, a summary of a long email thread. A person still reads and sends it, but the blank page is gone.

Classifying and routing is the second. Reading an inbound message and deciding whether it is a sales enquiry, a complaint, a supplier query or junk, then putting it in front of the right person with the key facts pulled out.

Answering from approved documents is the third. A member of staff asks a question in plain English and gets an answer drawn from your own policies, price lists or product sheets, with the source shown, rather than from the open internet.

Notice what these have in common. A person is still in the loop, the model is working from your information rather than its own, and the cost of a wrong suggestion is low because somebody checks it before it matters. Those three properties are what make a first project safe.

Where AI is the wrong answer

This is the section most AI vendors leave out, so it is worth reading twice.

If the rule can be written down, write it in software. “Invoices over a threshold need a second approver” is not an AI problem. It is a line of code, or a setting in a tool you already own. Using a model to apply a rule you can state exactly makes the result slower, dearer and less predictable.

If two systems need to talk, integrate them. Re-keying data between your accounts package and your CRM is tedious, but the fix is a connection between the two, not a model reading one screen and typing into another. Integration is boring and it works every time.

If the process is the problem, fix the process. When the weekly report takes a morning because four people submit figures in four formats, the answer is one format and one place to put it. Automating a bad process gets you the same mess faster.

If the data is not there, nothing clever can use it. A model answering questions about your stock needs a record of your stock that is accurate today. If that lives in someone’s head, the first project is the record, not the assistant.

We say this to clients regularly, and it sometimes means we build something plainer than they came in asking for. Outgrown your spreadsheets? is about exactly that situation: most of the operational problems people bring us are solved by a well-built system, with AI as a feature inside it where it helps.

How to pick one first project

Take the processes with the most marks and ask four questions of each.

  1. Is a person still checking the result before it matters? For a first project, the answer should be yes. A draft that someone reads is a safe start. An action nobody reviews is not.
  2. Can we tell whether it is working? You need a plain measure: enquiries answered the same day, hours spent on the report, replies corrected before sending. If you cannot say what good looks like, pick something else.
  3. Does the information it needs already exist in a usable form? Documents in a shared drive, records in a system with a login. If the input is a filing cabinet, that is a different project, and it comes first.
  4. Would anyone notice if it worked? Small enough to deliver in weeks, useful enough that the team would miss it. Avoid the clever idea nobody asked for.

One project. Not a platform, not a roadmap. The point of the first one is to learn how your business and a model get on, with low stakes, before deciding anything bigger.

What control means in practice

“We’ll keep you in control” is a line every agency uses. Here is what it should mean when you ask for the detail.

Permissions. The system can see only what it needs and do only what it is allowed to. An assistant that drafts replies does not need the ability to send them, delete records or read the HR folder. These limits are set in the design of the system, not in the instructions given to the model, because instructions can be argued with and permissions cannot.

Review. Every output a person sees should be easy to accept, correct or reject, and the corrections should be kept. That interface is where most of the value of a first project comes from, because the corrections tell you where the system is weak.

Evaluation. Before anything goes live, it is tested against a set of real examples with known good answers, and that test is run again whenever something changes. Without it, “it seems fine” is the only evidence you have.

Knowing which provider processes what. Most useful AI today runs on a model hosted by a third party. That is not a problem in itself, but you should know which provider, what they receive, where it is processed and under what terms, and it should be written down for your project. Be wary of anyone who promises your data never leaves your business without explaining the architecture that makes it true, because for most cloud services it is not.

An audit trail. What was asked, what was answered, what was changed and by whom. If something goes wrong in six months, this is how you find out why.

None of this is exotic. It is the same discipline as any other business system, applied to a component that is less predictable than the ones we are used to. We go through the full list in what a bespoke AI project involves, beyond the model.

What to do next

Run the afternoon. If you come out of it with one process that has all three marks, information that already exists, a person who would check the result and a way to measure it, you have a first project. If you come out of it with a list of processes that need rules, integrations or tidying, you have something just as useful: a plan that does not involve AI yet, and a reason to be sceptical of the next tool that promises otherwise.

Either way, if you want a second opinion on the list, talk to us about AI development. We’ll tell you which of the three answers it is, including when the honest answer is ordinary software or no change at all.

_written_by Ryan Byrne Co-founder and lead developer

Ryan leads development at One Size Media. He designs the systems, writes and reviews the code, and looks after the platforms clients rely on every day.

Want to talk this through for your business?

Tell us what you're trying to achieve and we'll help work out the next step.