What Not to Automate in Your Business - The Five Jobs to Leave Alone

What should you not automate?

Do not automate anything that reaches a customer without review, anything that moves money, any process nobody in your business can describe end to end, anything that happens only a handful of times a month, and the specific work your customers actually pay you for. Those five categories cover almost every automation that gets built, quietly fails, and costs more to unpick than it ever saved. Everything else is fair game, and most businesses have plenty left over once the five are off the table.

This is worth settling before you build rather than after. Automation failures are rarely dramatic. The workflow keeps running, the dashboard stays green, and the damage is a slow drip of slightly wrong outputs that nobody is checking because checking was the thing you removed. By the time it surfaces it is a customer complaint or a reconciliation problem, not an error log.

What is the Veto Test?

The Veto Test is our three-question filter for any proposed automation. Ask them in order and stop at the first no. It takes under a minute and it kills most bad builds before anyone opens an editor, which is the cheapest possible moment to kill them.

1. Can I describe this process end to end, in order, without checking? If not, you do not have a process. You have a habit, and automating a habit hardcodes whatever it does wrong.
2. If it gets this wrong, will I find out, and can I undo it? A mistake that is visible and reversible is a bug. A mistake that reaches a customer or a bank account is an incident.
3. Does this happen often enough that the time saved beats the time to build and maintain it? Maintenance is the part people forget, and it never goes to zero.

The second question is the one that does the most work. It is deliberately about visibility rather than importance, because you can live with an automation that gets an important thing wrong if you notice within an hour. You cannot live with one that gets a small thing wrong for four months. Sort your candidates by whether the error surfaces, not by how much the task matters.

Do not automate anything that reaches a customer unreviewed

Drafting is safe, sending is not. An automation that writes the reply and leaves it waiting for a human is almost always worth building. The same automation with the send step attached is a different risk category entirely, because every error it makes is now witnessed by the person you least want to witness it.

The argument against always sounds like a time argument: approving drafts is slow, so why not just send. In practice the approval step is a few seconds per item and the thing it prevents is the one failure a small business cannot absorb, which is a customer receiving something confidently wrong with your name on it. Keep the draft, cut the send.

There is a narrow exception: genuinely transactional confirmations with no judgment in them, such as an order receipt or a booking confirmation. Those have been automated for decades and are not what this is about. [How to automate customer support with AI](/blog/how-to-automate-customer-support-with-ai) covers where the reviewed line sits once volume is high.

Do not automate a process nobody can describe

If two people in your business describe the process differently, it is not ready to automate. Automation does not clean up a messy process. It takes whatever the process currently does, including the undocumented exceptions and the bit that only works because someone senior quietly fixes it on Fridays, and it repeats that at speed with nobody watching.

The tell is the conversation you have while scoping it. Every second sentence starts with 'usually' or 'it depends'. Those are not details to handle later. They are the actual process, and they are living in one person's head. Write it down first, run it manually for two weeks against what you wrote, and fix the description where reality disagreed.

• Two people describe the steps in a different order. The order matters and nobody has decided it.
• The process has exceptions nobody has counted. Undocumented exceptions become silent wrong outputs.
• One person is the only one who can do it. You are about to encode their judgment without capturing it.
• Nobody can say what a correct result looks like. Then nothing you build can be tested.

Writing it down is not a delay, it is the cheapest part of the build. [How to write standard operating procedures with AI](/blog/how-to-write-standard-operating-procedures-with-ai) covers getting the description out of people's heads quickly, and the document you end up with is what you would have had to write for the automation anyway.

Do not automate money movement

Keep payments, refunds, price changes, and payouts as human actions. Preparing them is fine and genuinely useful. Executing them is where an automation error stops being a support ticket and becomes a reconciliation problem, a chargeback, or a conversation with your accountant about a month you cannot fully explain.

• Safe: matching invoices to payments, flagging anomalies, drafting the chase email, preparing a refund for approval.
• Safe: assembling the numbers for a payment run and telling you what looks unusual before you approve it.
• Not safe: issuing refunds without approval, changing a live price, releasing a payout, cancelling a subscription automatically.
• Not safe: anything that can act in a loop against money. A retry bug in a workflow that only drafts is an annoyance. In one that pays, it is an incident.

The rule holds even when the amounts are small, because the cost is not the amount. It is the audit. Reconstructing what an automation did across three hundred transactions costs more staff hours than the automation saved in its entire life. [How to automate invoicing with AI](/blog/how-to-automate-invoicing-with-ai) covers the preparation half, which is where the real time savings sit anyway.

Do not automate genuinely low-volume work

If a task happens a few times a month and takes ten minutes, an automation will probably never pay you back. Do the arithmetic honestly before you build, and include the parts people leave out: the build time, the debugging, and the maintenance every time an upstream tool changes. Maintenance is the line that turns a good-looking case into a bad one.

Those figures are simple arithmetic on the frequency, not measured results, and they are the optimistic version because maintenance is excluded. There is one honest exception: a low-volume task with a high error cost, such as a monthly compliance check. You are buying reliability rather than time, and that is a legitimate reason to build. Just be clear which one you are buying. [How to measure the ROI of AI in your business](/blog/how-to-measure-the-roi-of-ai-in-your-business) covers holding yourself to the number afterwards.

Do not automate the thing customers actually pay you for

Automate around your differentiator, never through it. If people choose you because your advice is sharp, your photography has a look, or your service is unusually personal, that judgment is the product. Automating it does not scale the business, it removes the reason the business exists and leaves you competing on price with everyone else who automated the same thing.

The distinction is easy to apply in practice. Automate the work that surrounds the valuable work: scheduling, intake forms, note-taking, reminders, follow-ups, reporting, file handling. That gives you more hours to spend on the part they are paying for. The moment a customer could tell the difference in the thing they bought, you have crossed the line.

• A consultant should automate intake, notes, and scheduling. Not the recommendation.
• An agency should automate reporting and asset handling. Not the creative judgment on the work.
• A trades business should automate quoting admin and reminders. Not the site assessment.
• A coach should automate booking and session prep. Not the session.

This is also the answer to the anxiety underneath the question. The parts of your business that are hardest to automate are usually the parts that are hardest to compete with, so the correct move is to spend more of your time there, not less. Our [use cases](/use-cases) pages cover what the surrounding work looks like in different businesses.

How do I keep a Do Not Automate List?

Write one page, keep it where the team can see it, and put a reason next to every line. A list without reasons gets ignored the first time someone is in a hurry. A list with reasons survives, because the reason is what someone checks against when the situation is slightly different from the one you wrote down.

1. One line per item, with the reason in the same sentence. 'No automatic refunds - reconciliation cost is higher than the refund.'
2. Separate permanent vetoes from not-yet ones. Money movement is permanent. An undescribed process is temporary and becomes eligible once it is written down.
3. Name who can overturn a line. Usually the owner. Undocumented exceptions are how the list dies.
4. Review it when a tool changes, not on a schedule. New capability is what makes people reopen these decisions.
5. Log anything you took back off automation and why. That list teaches more than the successes do.

Pair it with the opposite list. A Do Not Automate List on its own reads as caution, and caution alone does not build anything. Next to a short list of the jobs you are actively automating this quarter, it reads as focus, which is what it is. [How to build your first automation](/blog/how-to-build-your-first-automation) covers picking the first item on that second list.

So what should you automate instead?

Automate high-volume, well-described work where a mistake is visible and reversible and no customer sees the output unreviewed. That is the whole positive rule and it is just the Veto Test inverted. It usually points at the unglamorous middle of the business rather than anything you would put in a case study.

Most of that list runs comfortably on a workflow tool rather than anything custom. [How to automate your business with n8n](/blog/how-to-automate-your-business-with-n8n) covers the unattended side, and it is the right place to start if your candidate cleared the Veto Test.

Write your Do Not Automate List this week

Take the five things you have been meaning to automate and run each through the Veto Test. Anything that fails goes on a one-page Do Not Automate List with the reason beside it. Anything that passes goes in a build queue, in order of how often it happens. That hour of sorting saves more than the first automation you would have built with it.