The automation mistakes that show up again and again

The short answer: six mistakes, in order of cost

Six mistakes account for most of the damage in AI automation projects, and here they are. Automating a process nobody has written down. Building a system that fails silently, so nothing tells you it stopped. Running everything on one person's personal accounts and logins.

Treating the instructions given to the model as wording rather than as code, so anyone edits them and nobody tests the result. Discovering the messaging platform's rules at launch instead of at design time. And automating the reply while leaving no record, so the business answers faster and still cannot follow anything up.

What they have in common is that each is nearly free to prevent at the start and expensive to correct once a system is live and people depend on it. None of them is a technology problem. They are all decisions that felt too small to discuss.

The first is covered thoroughly elsewhere, so here it is in one line: an undocumented process gives an automation nothing to be accurate against, so it will be confidently wrong in ways nobody notices for months. The other five are below.

Silence, which is the failure nobody sets an alarm for

Almost every business building one of these puts effort into what the system should do and none into what happens when it stops. So it stops, and nothing happens. No error appears, because from the outside a workflow that is not running looks exactly like a quiet afternoon.

The way this is usually discovered is a customer asking why nobody replied, three weeks after the last successful run. In between, enquiries have been arriving into a process that was not there. There is no way to recover those, because nobody knows which ones they were.

The prevention is small and specific. Alert on absence, not only on error: if the workflow has not run in a period longer than its normal gap, something should say so. Send that alert to a person on the channel they actually read rather than to a shared mailbox. Watch the successful runs too, since a workflow that is running but producing nothing is the same outage wearing a better costume. And test the alarm by deliberately breaking something, because an untested alarm is a belief rather than a control.

Personal accounts, and instructions nobody versions

The automation gets built quickly, so it gets built on whatever login was to hand. Somebody's personal email, somebody's phone number, a model provider key on a card belonging to whoever set it up. It works, so nobody revisits it. Then that person leaves, changes their password, or goes on leave with two factor authentication tied to their phone, and the system stops for reasons nobody can diagnose.

Give the automation its own accounts, in the company's name, billed to the company, with the permissions the job actually needs and no more. It takes an hour at the start. Reconstructing it after the fact means unpicking which of those logins are still live and which have quietly been powering something important for a year.

The related mistake is treating the instructions as wording. The prompt, the rules, the templates and the routing logic decide what the system says and does, which makes them the most consequential text in the build. In most businesses they get edited casually, by whoever is nearest, with no record of what changed or when, and no test run afterwards. So a small edit changes behaviour on a category of case nobody thought about, and there is no way to compare against last week.

Keep versions. Note what changed and why. Rerun a small set of real examples after any edit. And keep the list of people permitted to make those edits short and written down.

• Accounts and keys in the company's name, not a person's
• Permissions scoped to the job, checked against what they could do if misused
• A dated record of every change to instructions, rules and templates
• A short set of real cases rerun after each edit
• A written list of who may make those edits

Answering faster while recording nothing

This one is specific to how business happens here and it catches out good systems. A first response automation is installed, replies now arrive within a minute, and everyone is pleased. Underneath, the conversation is still just a chat thread. Nothing structured was captured, so there is no record of who asked, what they asked about, or what was promised.

The consequences arrive later. Nobody can follow up, because there is no list of people to follow up with. Nobody can tell which enquiries turned into orders. A colleague picking up the conversation has to read the whole thread, including the voice notes. And when a customer says they were quoted something different, there is no line for either side to point at.

Fix it by deciding, before building, the small number of fields that must exist for every enquiry: who, what they want, where it came from, what was promised, and what happens next. Then have the system fill them from the conversation and confirm anything it is not sure about with the customer. The reply is what the customer experiences. The record is what your business keeps, and only one of those still exists next month.

Platform rules found at launch instead of at design

This is the mistake with the most rework attached, because it invalidates a design rather than a detail. WhatsApp Business API operates under rules that shape what is possible: the customer must opt in, anything the business initiates has to use a template approved in advance, and there is a messaging window that closes after the customer's last reply.

A plan written without those in mind is a plan for a system that cannot be built. A follow-up sequence that sends whenever it likes, a re-engagement message going out to a list that never opted in, a helpful reply four days after the last customer message: each one runs into a rule, and each is discovered during launch week when the work is already done.

Read the rules of whichever channel you are building on before designing the flow, and design inside them. Ask a supplier to show you which parts of their proposal depend on templates, how long approval takes, and what the system does when the window has closed. A supplier who has not thought about the closed window has not run one of these in production.

Mistakes worth making anyway

Not every mistake on this list is worth avoiding at any price. Starting with something small and imperfect is better than spending a quarter designing something complete, because the first version teaches you things no amount of planning produces. Ship a narrow piece, watch it, and expect to rebuild part of it. The mistake is not the imperfection, it is refusing to look at what happened afterwards.

The same applies to over-caution. A system where a person approves everything is a safe starting point and a bad permanent state. If your reviewers have changed nothing for a month, either the threshold should move or the review has become theatre, and both are worth knowing.

There is one mistake this page cannot help with. If the work you are automating does not happen often, or nobody in the business is going to own the result, then avoiding all six of these will still leave you with something that quietly stops being used. In that case the mistake was the purchase, and no amount of careful building corrects it.

The seventh mistake, and the two that ownership prevents outright

There is a seventh worth adding at the top of the list: nobody decided what the system may never do alone. Money, pricing, anything published in your name and any serious complaint should wait for human approval, and a case outside the written rules should hand it to a person with the record attached. It belongs beside the silence mistake, because both are failures of what happens when the ordinary path runs out, and both are cheap to prevent and expensive to find out about.

Two of the six stop being possible once ownership is settled. Personal accounts and unversioned instructions are what happens when nothing was registered properly at the start. Register the accounts in the company's name on the first day, keep the workflow definitions and prompts somewhere they can be read and compared, and hand over the document listing every key and connection as each piece lands. You own the system, and the version history is part of what you own rather than a courtesy somebody extends.

The mistake worth making anyway is the argument for starting in-house. Something small and imperfect built by your own team this month teaches more than a quarter spent designing something complete, and where somebody inside already automates things, that is where the first one belongs. Ibrahim owns build and workflows at Wobble, and the published work is what the sixth mistake looks like when it is avoided: Quillon's delivery line as a single audited automation of 34 AI nodes, and three purpose built ERP systems live at RM Gulistan Engineers. Wobble works from Karachi, bills month to month, across 25 engagements in six countries.

Common questions

What is the most common AI automation mistake?

Automating a process that was never written down. Without a written standard the system has nothing to be accurate against, so it is not obviously wrong, only different from what the person used to do, and the difference goes unnoticed until somebody builds a manual workaround around it.

How do we know if an automation has stopped working?

Only if you alert on absence rather than on error. A workflow that is not running looks the same from outside as a quiet afternoon. Set an alert for when it has not run in longer than its normal gap, send it to a person on a channel they read, and test it by breaking something deliberately.

Why should an automation not use personal accounts?

Because it stops when that person leaves, changes a password, or travels with the phone holding the second factor. Accounts and model keys should be in the company's name with permissions scoped to the job. It takes an hour at the start and is genuinely painful to reconstruct afterwards.

Should we track changes to the prompt?

Yes. The instructions decide what the system says and does, which makes them the most consequential text in the build, yet they usually get edited casually with no record. Keep dated versions, note what changed and why, rerun a small set of real cases after each edit, and limit who may edit them.

What do people forget about WhatsApp automation?

The platform rules. WhatsApp Business API requires customer opt-in, requires pre-approved templates for anything the business initiates, and closes the messaging window after the customer's last reply. Designs written without those constraints have to be reworked during launch week, when the work is already done.

Is it a mistake to launch something imperfect?

No. A narrow first version teaches you things planning does not, and rebuilding part of it is expected. The mistake is refusing to look at what happened afterwards, or leaving a full human review in place permanently when reviewers have stopped changing anything.