The automation checklist I use before writing any code
Before I automate anything, I try to talk myself out of it. That sounds backwards, but it saves a lot of money.
A task can be annoying and still be a bad automation candidate. Maybe the inputs are different every time. Maybe nobody owns the exceptions. Maybe the real problem is a decision that has never been written down. Maybe AI would make it more expensive than a plain script.
The checklist below is not a build recipe. It is the test I use to decide whether the project is worth building at all.
1. Does it repeat?
Automation pays back through repetition. A painful task that happens once a year may still deserve a better checklist, but it probably does not deserve a custom workflow.
The best candidates happen daily, weekly, or monthly. Reports. Order entry. File cleanup. Invoice processing. Copying information from one system to another. Anything where the phrase "every time" shows up when someone explains the work.
2. Are the inputs stable?
If the work starts with a spreadsheet, a folder of PDFs, a standard email, a portal export, or a form response, good. If the work starts with "it depends what they send us," slow down.
Stable does not mean perfect. It means the input has a recognizable shape often enough that the workflow can make a reasonable first pass.
3. Can the rules be explained out loud?
This is the big one. If the person doing the task can explain the rules, the automation has a chance.
For example: "If the status is backordered, put it in this queue. If the order is over $5,000, send it to a manager. If the customer is tax-exempt, use this field instead."
If the explanation is mostly "I just know," you may still be able to automate part of it, but the first project is documenting the decision, not writing code.
4. Is the output clear?
A workflow needs a destination. A clean spreadsheet. A draft email. A PowerPoint deck. An import file. A list of exceptions. If nobody can say what "done" looks like, automation will just make the confusion faster.
This is where a lot of AI demos fall apart. The answer looks impressive, but nobody knows what should happen next.
5. Who owns the exceptions?
Every real workflow has exceptions. The question is not whether they exist. The question is where they go.
A good automation does not pretend exceptions disappear. It separates them. The routine cases go through. The weird cases land in a review list with enough context for a person to decide.
6. How will we catch it when it is wrong?
This question matters even more when AI is involved. A normal script usually fails loudly. AI can fail politely.
Before launch, decide what gets checked. Totals. Counts. Missing fields. Random samples. High-dollar records. Customer-facing messages. The verification step is part of the workflow, not an optional afterthought.
7. Does this need AI at all?
If the work has clear rules, start with a script. It is cheaper, faster, and more consistent. I wrote the longer version in no token tax.
Use AI where the input is messy: free-text notes, unstructured PDFs, emails, descriptions, categories that require judgment. Use ordinary code for exact arithmetic, field mapping, routing, formatting, and validation.
8. Is the value obvious enough to survive?
A tiny automation that saves two hours every week for one person is easier to keep alive than a vague "AI transformation" that nobody can measure.
Before you build, write the value in one sentence: "This saves the sales team two hours every Monday by generating the first draft of the prospect deck." If you cannot write that sentence, the project is not scoped yet.
The takeaway
A good automation candidate repeats, has stable inputs, has rules someone can explain, produces a clear output, routes exceptions, and has a verification step. If it cannot pass that test, building faster software just makes the messy process move faster.
Want me to run the checklist with you?
Bring one task your team hates. I will tell you honestly whether it is worth automating.