The right order to automate a growing business with AI

Most founders meet AI as a demo. Someone shows you a chatbot that answers customer questions in your brand voice, or a tool that drafts marketing copy in seconds, and the instinct is to put that in front of customers as fast as possible. It feels like progress because it is visible.

It is also, more often than not, the wrong place to begin. The customer-facing showpiece is the part of your operation with the highest stakes, the most edge cases and the least tolerance for getting it wrong. Starting there means learning the hard lessons of automation in full view of the people whose goodwill you can least afford to spend.

There is a better sequence. It is less exciting to talk about at a dinner party, and it pays back faster and more reliably.

Why the s^hiny thing tempts everyone

The customer-facing project wins the internal argument for understandable reasons. It is the part of the business the founder thinks about most, it photographs well in a board update, and a vendor can demo it in ten minutes. Internal admin, by contrast, is invisible to everyone outside the company, so automating it never feels like a milestone worth announcing.

The problem is that visibility and return are not the same thing. A support bot that handles eight out of ten queries well still produces two failures that a customer remembers, screenshots and forwards. The two per cent that goes wrong defines the experience, and you have spent your first and most fragile attempt at automation on the work with the smallest margin for error.

Internal work is the opposite. When an automated process for reconciling invoices gets something wrong, a member of staff catches it, fixes it and tells you what broke. The feedback loop is fast, private and cheap. You learn how automation behaves in your business before you bet your reputation on it.

Automate the boring middle first

The higher return is almost always in the repetitive internal work nobody enjoys, namely the tasks that happen many times a day and rarely go wrong in interesting ways. Think about the things a member of staff does dozens of times a week that follow the same shape every time: copying figures from one system into another, sorting inbound enquiries by type, chasing the same three pieces of missing information, formatting a report that always looks the same.

These tasks share three useful properties. They are high frequency, so even a small saving compounds quickly. They are low stakes, so a mistake costs minutes rather than a customer. And they are well defined, so you can actually describe the rule, which is the part most people skip. If you cannot write down what the task involves in a few plain sentences, no tool will be able to do it reliably either.

A practical filter for the first wave of automation:

• It happens at least daily, ideally many times a day.
• A mistake is annoying, not expensive or public.
• You can describe the steps without using the word "depends" more than once.

Work that fails the third test is not ready to automate. It is ready to be understood better first, which is a different and cheaper project.

The build versus buy line for a small team

Once you know what to automate, the next decision is whether to build it or buy it. For a small team the honest default is buy. If a tool already exists that does eighty per cent of what you need, your own version will cost more than the licence, take longer than you think and become your problem to maintain forever. Software you build is not a one-off purchase, it is a pet that needs feeding.

Building earns its place in a narrow set of cases. The first is when the process is genuinely specific to how you make money, the thing a competitor could not simply copy off the shelf, because that is where a tailored tool creates an advantage rather than just replicating one. The second is when an off-the-shelf product would force you to hand sensitive data somewhere you are not comfortable with. The third is when you have already bought the cheap version, outgrown it, and can describe exactly where it falls short, which is very different from imagining requirements in advance.

For everyone else, the smart move is to buy the obvious parts, connect them well, and reserve your limited engineering attention for the one or two places where being different actually matters. This is also where specialist firms such as Aivy earn their fee, by telling you which of your problems is a solved one you should simply pay for and which is the rare case worth building, rather than selling you a bespoke project for both.

The trap of automating a broken process

The most expensive mistake is not choosing the wrong tool. It is pointing a good tool at a process that was already broken and assuming the automation will tidy it up. It will not. Automation is an amplifier. If your enquiry handling is inconsistent because nobody agreed what a "qualified lead" means, automating it gives you inconsistent handling at higher speed and larger volume. You have bought faster mistakes.

This is why the step everyone wants to skip, namely writing down how the process actually works today, is the one that determines whether the project succeeds. The act of describing a task in enough detail for a machine usually exposes the parts that were never really agreed: the exceptions one person handles by instinct, the step that exists only because someone left three years ago, the decision that depends on context nobody wrote down.

Fix the process on paper first. Quite often that exercise alone removes enough waste that the automation becomes simpler, cheaper and, occasionally, unnecessary. A process you cannot explain is not a candidate for automation. It is a candidate for a conversation.

When outside help pays for itself

Plenty of this you can do yourself, and for the first wave of simple, bought tools you probably should, because the learning is worth more than the time saved. Outside help earns its cost in three situations specifically.

The first is when you are about to build rather than buy, where an experienced pair of hands stops you constructing something you will regret maintaining. The second is when the pieces need to talk to each other and the integration, rather than any single tool, is the hard part. The third is the most valuable and the least sold: when you need someone honest to tell you a project is not worth doing at all. A good adviser is measured by the work they talk you out of, not the invoice they leave behind.

The order matters more than the tooling. Start with the dull, frequent, low-risk work where mistakes are cheap and lessons are fast. Buy before you build, and build only where being different earns its keep. Fix the process before you automate it, because speed applied to a mess simply makes a faster mess. Do that, and by the time you reach the customer-facing project everyone wanted to start with, you will know what you are doing, which is exactly when it is safe to be seen.