When not to automate yet

I like automating things. The best moment in this kind of work is when a task someone has done by hand for years simply stops needing them. That is exactly why it is worth being clear about when not to automate. Most of the reasons below do not mean "never". They mean "not yet".

An automation is something you keep

An automation is not a one-time purchase. It runs every day, never asks questions and never notices when the world changes around it. It depends on systems that get updated, credentials that expire, an upstream API that renames a field, and assumptions that were true on the first day and quietly stop being true later.

Manual work fails loudly: a person falls behind, complains, asks for help. Automation fails quietly: it keeps running, confidently, doing the wrong thing until someone downstream notices the damage. So next to "is this task annoying?" there is a second question: who will own this system for the next two years?

Not while the rules are unclear

Automation multiplies whatever it is pointed at. Point it at a process that works, and you get more of a good thing. Point it at a process that is unclear or disputed, and you get the confusion faster, with code wrapped around it that makes it harder to change.

Lead assignment is a common example. Ask how leads are assigned and the answer is often a chain of exceptions: whoever is free, unless it is a large company, unless someone has already spoken to them, unless it is a returning customer. That is a person using judgement and calling it a rule. Automating it would freeze one version of a decision nobody has actually agreed on, and every wrong assignment would start an argument about what the system should have done. The first step is to get the people involved to write the rule down and agree on it. After that, automating it is often an afternoon's work.

Not while the process is still changing

Automation pays back over many runs of a stable process. If the steps change every few weeks, because the product is young, because the team is still learning what customers need, or because the workflow itself is an experiment, anything you automate is out of date before it has paid for itself.

Onboarding new customers in a young company is a typical case: this month's steps are not last month's. Hard-coding them adds a rewrite to every change instead of saving work. A checklist and a clear document are the right tools for a process that is still finding its shape. Automate the parts that have stopped changing, and leave the rest to people until they settle.

Not when judgement is the job

Some work looks like data entry and is really a series of decisions. Refund requests are a good example. Most are trivial and could be approved by a few rules, but the reason a person handles them is the rest: a large customer just outside the refund window, a pattern that looks like fraud, a complaint that is really a bug report. Here the right tool assists instead of replacing: it clears the obvious cases and hands the rest to a person with the context attached.

Not without someone who will notice it breaking

One question settles many of these cases: what happens if this runs wrong in the middle of the night, with nobody watching?

If the answer is a wrong number on an internal chart that someone will question over coffee, automate it and move on. If the answer is money sent, customer data deleted, an email to every customer or something approved that should not have been, it can still be automated, but only with guardrails a simple script does not have: a dry-run mode, hard limits, a person confirming the irreversible step, and an alert that someone will actually see. How to build those is in From a one-off script to a tool people can rely on.

def should_automate(task):
    if not task.rules_agreed:      return "agree on the rules first"
    if task.still_changing:        return "wait until it settles"
    if task.judgement_is_the_job:  return "assist, don't replace"
    if not task.has_owner:         return "find an owner first"
    return "automate, with guardrails sized to the damage"

Whether a task is worth automating at all, given how often it runs and how much each run differs, is the subject of The manual-work audit.

In short: agree on the rules, wait for the process to settle, keep people on the decisions that are the job itself, and give every automation an owner and an alarm. Then automate.