Free diagnostic

This belongs to Stage 4Acceleration

AI Automation

AI is being talked about everywhere, and you have probably been pitched it more than once. Meanwhile your team still spends the day on visibly repetitive things: copying WhatsApp orders into a spreadsheet, retyping invoice details, assembling the same weekly report by hand.

We look at the process first and then decide which part is genuinely suited to automation — repetition moves to the system, people move to judgement and relationships. Where AI is the wrong tool, we say so.

Two kinds of waste run at once. One is the repetitive work itself: headcount rises in step with revenue, and people doing the same thing for the twentieth time make mistakes. The other is quieter — AI tools adopted to keep up, which nobody ends up using. Money spent, meetings held, training done, and three months later everyone is back to the old way and has lost patience with the next “let's try AI” proposal.

The root cause is treating AI as the goal rather than the tool. “We should adopt AI” names no problem, so there is no way to tell whether it worked. The question that holds up runs the other way: in this process, which step is repetitive, rule-clear, high-volume enough to matter, and forgiving enough that an occasional error is survivable? That step is worth automating. A step failing those tests only becomes harder to debug with AI on top of it.

Which band is worth automatingThree kinds of work: judgement stays with people, an unsettled process should be left alone, and only the repetitive, rule-clear band is worth automating.JudgementCredit terms · exceptions · client relationshipsStays humanRepetitive, rule-clearCopying · converting · sorting · the same weekly reportWorth automatingA process not yet settledEveryone does it differently · no stateable ruleNot yetThe order cannot be skipped: settle the process, integrate, then automate.
The band worth automating is the middle one: repetitive, rule-clear, high-volume, and forgiving of error.

How the work runs

  1. Measure the repetition first

    What gets done daily, weekly, monthly; how long each takes; what happens when it goes wrong. Without this, every later discussion about whether something is worth automating is just an impression.

  2. Separate rules from judgement

    “Put the amount from this PDF into the sheet” is a rule — automate it. “Is this customer worth extending credit to” is judgement — keep it human. The middle ground is AI drafting and a person approving, and it is the layer most often skipped and most often the cause of trouble.

  3. Run one narrow case before widening

    Pick one process, run it for a period, compare against the old way. If it works, widen it; if it does not, stop. Stopping a small experiment costs nothing. Stopping a company-wide programme costs a great deal.

  4. Leave an audit trail

    What the automation ran, what the AI produced, where a person overrode it — all visible. When something goes wrong you can see what happened and why. Without that, the first error is usually enough to get the whole thing abandoned.

What changes for the business

Less of the same thing
Copying, converting, retyping, assembling the same weekly report. These move to a process that runs itself, and the team's hours move to the parts that need a person's judgement.
Growth without proportional headcount
Twice the orders should not mean twice the admin. That is the real value of automation, and a more useful thing to count than hours saved.
A clear map of where AI is used, and why
Every place AI is used has a reason you can say out loud and an effect you can check. Nothing sits there because everyone else is doing it.
Judgement stays with people
Where client relationships, exceptions and commercial judgement are involved, we recommend against automating and say why.

What's included

  • Workflow AutomationHanding repeated data entry, transfers and notifications to the system
  • Internal AI Assistant
  • Knowledge Base AISo the team can ask the knowledge base rather than a colleague
  • Document Automation
  • Business AI Integration

Ongoing

Ongoing: verifying together which manual work an automation actually removed, and adjusting on what we find.

This one is quoted individually

Website packages publish a floor because their scope is bounded. This does not, because the range is too wide for a figure to mean anything — a number in the middle deters the small project and over-promises on the large one. A free diagnostic settles the scope first, and the quotation follows from it.

See the published package prices, and why this is not one of them

When this isn't the right thing yet

Not yet: putting AI where human judgement and relationships belong. Automation handles repetition; it should not handle trust.

Common questions

Will AI replace my staff?
In an SME, usually not replacement but redeployment — moving people off the repetitive part. The real constraint is rarely too many people; it is too few, which is why the owner is doing the task personally. That is what automation addresses. On the larger question: AI will not replace businesses. Businesses that know how to use it will replace those that do not — and the difference is not speed, it is where they apply it.
We do not have much data. Does this still apply?
It depends what for. Process automation does not need volume, it needs clear rules — pulling an amount out of a PDF is worth automating at ten times a day. What needs volume is prediction, and for most SMEs that is not where the money should go yet. We will say so.
What happens when the AI gets it wrong?
Assume it will, then decide where to put it. Places where an error is cheap are fine — drafts, categorisation, first-pass tidying. Places where an error is expensive are not — payments, commitments to customers, legal documents. In between, AI drafts and a person approves. That line is part of the design, not something added after an incident.
Should we be doing AI now?
If the process is not settled yet, no. Automating a messy process produces a faster messy process that is also harder to debug. The order is: understand the process, integrate what should be integrated, then automate what is genuinely repetitive in what remains. Skipping the first two steps has been the most common and most expensive mistake of the past few years.