AI AI agents small business SME process automation

How to train an AI agent on how your business actually works

You pasted your process document into an AI tool and asked it to handle a job your team does every day.

What came back was almost right. The shape was there. The tone was close. And then it did something no member of your staff would ever do, because everyone who works for you knows that this particular customer gets invoiced differently, and that rule is written down precisely nowhere.

That gap between almost right and right is not a small final step. It is the entire job. And it is the reason most businesses conclude that AI can’t handle their work, when what actually happened is that nobody ever told the AI how the work is done. If you’re still deciding what an agent is and where one fits, start with AI agents for business and come back here for the part that decides whether it works.

”Training” is the wrong word, and the wrong word costs you months

When owners say “train the AI on our business”, they usually picture something like teaching a new starter. Weeks of absorbing how things run, after which it just knows.

That isn’t what happens, and expecting it sets you up to be disappointed twice: first when the quick version doesn’t work, then again when somebody quotes you for an enormous data project to fix it.

Here is what the job really is. You’re giving the agent three things:

  • Context. The facts about your business it can look up. Your price list, your customers, your products, last month’s orders, the standard terms.
  • Rules. What to do in which situation, including what it must never do on its own.
  • Worked examples. Real jobs from your business, with the real answers, so it can see what good looks like rather than being told.

None of that requires a data science project. All of it requires somebody to sit down and write what is currently in your team’s heads. That is the work. It is unglamorous, it is mostly conversation, and it is the difference between an agent that runs for 2 years and a demo that gets quietly switched off in March.

Your business is not documented. It’s remembered.

Ask most owners where the process lives and you get pointed at a folder.

Open the folder and you find a document written 3 years ago by somebody who has left, describing a system you no longer use, approved by nobody, followed by no one. It describes the process as management wished it worked.

The real process is split across four places, and only one of them is written down.

The system of record. Your CRM, your accounts package, your inbox, your job management tool. This part is genuine and current, because the business would stop without it. It tells you what happened, though rarely why.

The documents. The SOP folder, the onboarding pack, the pricing sheet. Treat these as a claim to be checked rather than the truth. Some of it is accurate. The useful move is finding out which parts.

Your team’s heads. How you decide which supplier to use when both can deliver. Which customers get chased on day 3 and which get left until day 14. Which quotes need your eyes before they go out. Nobody hid this from you. Nobody ever asked them to write it down, and they don’t think of it as knowledge. They think of it as just doing the job.

The exceptions nobody logs. The reason your team can do the job and the AI can’t. More on this below, because this is where the money is.

An agent can read the first two in an afternoon. The second two are why you need a person involved, and why “just point it at our Google Drive” produces a confident, plausible, wrong machine.

What the agent actually needs, in the order you should collect it

Work through one process at a time, and in this order. Skipping ahead is how people end up rebuilding.

1. The trigger. What starts this job? An email arriving, a form submitted, a date passing, somebody noticing something. Be precise. “When an enquiry comes in” hides the fact that 4 of them arrive by phone.

2. The inputs. What does a person need in front of them to do this job properly? Name the systems and the fields. If the answer includes “then I check with Sarah”, Sarah is an input and you need to know what she’s checking.

3. The decisions. Every point where the job forks. For each one, the rule, and the threshold in numbers where a number exists. “Large orders get approved” is not a rule. “Orders above £2,000, or any order from a customer with an overdue invoice, go to Priya” is a rule.

4. The output. What does done look like, exactly? Which system holds the result, what state is it in, who gets told.

5. The escalation line. What the agent must hand to a person, always. This is the most important line in the document and it goes in from the start, not after something goes wrong. We build agents to handle the repetitive half and route judgement to a human, and that line is where you draw it.

Write this for one process. It takes an hour or two with the right person, not a quarter. Then stop and build that one, because the second process teaches you far more once the first is live.

Sit next to the person doing the job. Don’t interview them.

If you ask somebody to describe their process, you get the version they’d tell a new starter. Tidy, linear, and missing most of what they really do.

Watch them do it live and narrate, and you get the real thing. You’ll hear “oh, I always check this first” and “that one’s a special case” 6 times in 20 minutes, and every one of those is a rule the tidy version left out.

Three things that get more out of an hour than any amount of documentation:

  • Have them do real work, not a demo. Pick jobs from this week’s actual queue.
  • Ask “when doesn’t that work?” after every step. The answer is always an exception, and exceptions are the ones you’re missing.
  • Ask what they’d never let an automated system do. Your team already knows where the risk sits. They will tell you plainly, and they’re usually right.

Then take the 20 most recent real cases, with the real outcomes, and keep them. Those are your worked examples, and they’re worth more than the document you just wrote.

The exceptions are the job, not the edge case

The happy path is the easy part. Any agent can handle the customer who fills the form in properly, pays on time and asks nothing unusual.

That customer is not why you’re still doing this work by hand.

You’re doing it by hand because of the client on legacy pricing, the supplier who invoices in a format nothing reads, the order that needs signing off if it comes in after the cutoff, and the 4 accounts that get treated differently for reasons that made sense in 2023. Your team absorbs all of it without comment. It has become invisible, so it never makes it into the brief.

So flip how you spend the effort. Half an hour on the happy path is plenty. Spend the rest of the session on the question “what makes this one different?”, and get the list.

Then sort that list into three piles:

  1. Rules the agent can follow. Most of them, once written down. Legacy pricing is a lookup, not a judgement call.
  2. Things that go to a person, every time. Anything involving a price you’d want to see, a relationship that matters, or a decision you’d be uncomfortable explaining to a customer afterwards.
  3. Things that shouldn’t exist. You’ll find these, and the list is usually longer than you expect. Exceptions carried for a customer who left, workarounds for a system you’ve replaced. Fixing the process beats teaching a machine to cope with it.

That third pile is the quiet payoff. Getting a business ready for an agent forces the first honest look at how it runs in years, and some of the value shows up before any software does. It’s the same reason what you get from an AI audit tends to be useful even to owners who don’t build anything straight after.

Show it the work. Don’t just describe it.

Instructions tell an agent what you think the rule is. Examples show it what the answer looks like when the rule meets a real customer.

You need both, and most people only supply the first.

Pull 20 to 30 real cases from the last few months. Include the awkward ones on purpose: the complaint, the half-completed form, the one that needed your sign-off, the one your team got wrong. For each, keep what came in and what went out, exactly as it was sent.

Two reasons this matters more than another page of rules. It carries your house style without anyone having to describe it, which is nearly impossible to write down and obvious to see. And it gives you something to test against, which is the next section and the step most people skip.

If every example you keep is a clean one, you’ve built an agent that handles the cases you were never struggling with.

Check it against last month before you let it near a customer

Nobody should launch an agent on a hunch. You already own the test.

Take real work the business has already completed, run the agent over it, and compare its answer with what your team actually did. Same inputs, known outcomes, no customer exposed. You find out how close it is on cases where you know the right answer.

Read the disagreements one by one, and expect three kinds:

  • The agent got it wrong. A missing rule. Add it, run it again.
  • The agent was right and your team wasn’t. This happens more than owners expect, and it’s worth knowing either way.
  • It’s a judgement call. Then it belongs on the escalation line, not in the rules.

Then run it alongside your team for a fortnight before it runs alone. The agent drafts, a person checks and sends. You’ll fix more in those 2 weeks than in a month of planning, and nothing reaches a customer unseen. Once the corrections become boring, let it go.

Set what you’re measuring before you start. How often it needs correcting, how many cases it hands over, and the hours it takes off your team. Without a number from before, you’ll be arguing about whether it’s working for the next 6 months. That baseline is why the cost of the manual work is worth counting first.

It will drift, and that’s a maintenance job

An agent taught how your business worked in September is slightly wrong by March, and quite wrong by the following September.

Your prices changed. You added a service. A supplier changed their format. The rule about orders after the cutoff got relaxed and nobody told the machine. None of this is a fault in the agent. The business moved and its instructions didn’t.

Three things keep it honest, and they’re small:

  • One named owner. A person, not a department. Someone whose job includes noticing when the agent is out of date.
  • A place to log corrections. Every time somebody overrides it, that’s a rule that’s wrong or missing. A shared sheet is enough. Reviewed monthly, that list is your improvement list, written for free by the people closest to the work.
  • A calendar reminder. Anything you change on a price list or a policy gets checked against the agent in the same week.

This is why our support line exists as its own service instead of a warranty. Agents need retraining as the business changes, and pretending otherwise is how businesses end up with automation nobody trusts.

What this looks like when it’s done properly

Both of our case studies came down to this step rather than the software around it.

Founderise worked because we sat with the delivery process as it really ran, exceptions included, before writing anything. 12 hours a week came back and margin went up 3.5x, and the reason wasn’t clever code. It was that the agent knew what the people knew.

MidShift has served more than 20,000 professionals with 92% faster progression. Career guidance is judgement-heavy work, which makes it exactly the case where you’d expect an agent to fall over. It holds up because the rules and the handover points were mapped in detail first, so the system knows which questions it answers and which ones a person owns.

Neither was a data project. Both started with 2 careful weeks of finding out how the work really gets done.

One more thing worth sorting while you’re doing it. Everything you write down here, the rules, the exceptions and the test cases, is the expensive part to rebuild, so make sure it belongs to you rather than to whoever helped you write it. Who owns the code and the data covers how to get that in writing.

Five ways this goes wrong

Worth knowing before you start, because all 5 are common and all 5 are avoidable.

Pointing it at everything you own. Dumping the whole shared drive in gives an agent your 2021 price list with equal weight to this year’s. Curate, don’t dump.

Writing the process you wish you ran. Teach it the aspirational version and it will be confidently wrong in exactly the places your team quietly works around. Document what happens, then improve the process separately.

One giant instruction document. 12 pages covering 6 processes produces an agent that is vague about all of them. One process, done properly, beats six done loosely. Which one first is its own question, and which processes to automate first is the answer. Our what to systematise first tool ranks them for you in a couple of minutes.

Letting it decide things it shouldn’t. If the output is a price, a refund, a hiring call or anything a customer could reasonably be upset about, a person approves it. The agent can produce an answer perfectly well. You just want a name attached to that answer.

Treating it as a launch instead of a system. Nobody owns it, corrections go nowhere, it drifts, trust goes, and 9 months later somebody says AI didn’t work here. The build is the cheap half. Keeping it accurate is the half that decides whether it pays.

The short version

You can’t train an agent on your business by handing it a document, because your business isn’t in the document. It’s in your systems, your team’s heads and a list of exceptions nobody has ever written down.

So do it in this order. Pick one process. Sit with the person who does it and watch them work. Get the trigger, the inputs, the decisions with real numbers, the output, and the line where it hands over to a human. Spend most of your time on the exceptions, because that’s the part your team is quietly carrying. Keep 20 real cases with real answers. Test it against work you’ve already done before any customer sees it. Give it an owner and a place to log corrections.

Do that and you get an agent that holds up. Skip it and you get a demo that works beautifully on the cases you were never worried about.

Want the process mapped properly before anything gets built?

That’s most of what an AI audit is. Two weeks, every repeatable process in your business mapped and costed in hours and pounds, ranked by what to automate first, with one working proof of concept at the end so you can see it running on your own work rather than a slide.

Fixed price, agreed in writing before anything starts. No day rates, no paid discovery phase. Credited in full against a build.

Book a free call and bring the process that annoys you most.

Want to see what this looks like for your business?

Book a free architecture audit. We'll map out where the bottlenecks are and what a custom platform could look like.

Book a free audit