There's a version of workflow automation that saves your team hours every week and a version that costs you three months of engineering time to replace a five-minute task. The difference usually isn't the technology — it's whether you picked the right process to automate in the first place.
Most businesses I work with have the opposite problem from what they expect. They think they don't know how to automate anything. In reality, they have a long list of things they could automate, and no clear way to decide which ones are actually worth the effort. This post gives you that framework.
The Core Question: Is the Pain Real?
Before you think about automation tools, ask whether the process is genuinely causing problems. This sounds obvious, but it's easy to automate something because it feels inefficient rather than because it's actually holding you back.
A good candidate for automation has at least one of these properties:
- It happens frequently (daily or multiple times per week)
- It takes meaningful time per occurrence (30+ minutes, or a lot of someone's attention even if it's fast)
- Errors in it have real consequences (lost revenue, compliance risk, customer complaints)
- It creates a bottleneck — other work waits on it to finish
A bad candidate looks like this: it happens once a month, takes twenty minutes, and the person doing it doesn't mind doing it. Automating that is a solution in search of a problem.
What Makes a Process Automatable
Not every painful process is a good automation target. The processes that automate well share a few characteristics.
The steps are consistent
Automation handles variation badly. If your process has fifteen steps and thirteen of them are always the same, that's automatable. If the steps change based on judgment calls — "it depends on what the client usually wants" or "sometimes we do it this way, sometimes that way" — you're going to spend most of your time writing exception-handling code or training an AI model to guess correctly.
Before you automate anything, document the process exactly as it happens today. If you can't write it down clearly, you can't automate it cleanly.
The inputs are digital and structured
Automation tools work with data. The easier that data is to read programmatically, the cheaper and more reliable the automation. A spreadsheet, a form submission, an API call — these are easy. A PDF invoice that different suppliers format differently, or a handwritten note someone has scanned — these are hard.
This doesn't mean messy inputs are impossible to handle. Optical character recognition and AI-based document parsing have come a long way. But "hard" here means "expensive to build, more likely to fail in production, requires ongoing maintenance." Factor that in.
The success criteria are clear
How do you know when the process has been done correctly? If the answer is subjective — "it looks right," "the client seems happy" — then you're looking at a process where human judgment is doing a lot of work, even if it doesn't feel that way. That judgment is hard to replicate.
If the success criteria are objective — the invoice was sent, the record was updated, the report was generated — automation is straightforward to verify.
Where to Start: The High-Value Targets
Based on what I see across the businesses I work with, a few categories of process almost always justify the investment.
Data entry and transfer between systems
Someone copies information from one system and pastes it into another. Every business has this. It's error-prone, time-consuming, and completely mechanical. This is often the highest-ROI automation you can do, and it doesn't require AI — a simple integration between your two systems, or a tool like Zapier or Make, is usually enough.
If your systems have APIs, the cost is low and the reliability is high. If they don't, you're looking at more work, but it's still often worth it.
Routine reporting and data collection
Weekly reports assembled by hand, dashboards that someone updates by pulling data from three places, status emails written from a template — these are good automation candidates. The key is that the data already exists somewhere in a readable format; you just need to collect and present it consistently.
Customer-facing notifications and follow-ups
Confirmation emails, appointment reminders, payment receipts, follow-up sequences after a trial period — if these are currently manual, they're leaving money on the table. The logic is usually simple enough that even a basic automation tool handles it well.
Routing and triage
Incoming requests (support tickets, lead inquiries, job applications) that need to be assigned to the right person or queue based on their content. Simple rules-based routing — if the subject contains "invoice", assign to accounts — is easy. If you need to understand the meaning of the message, that's where AI classification tools come in. Both work well when the categories are well-defined.
When AI Automation Makes Sense vs. Simple Automation
This is a distinction that matters and often gets glossed over. Most workflow automation does not require AI. If the logic is deterministic — if X then Y — a rules-based tool is cheaper, faster to build, easier to debug, and more reliable.
You need AI in the automation loop when:
- The input is unstructured text, images, or documents that vary in format
- The decision requires understanding meaning, not just matching patterns
- You're summarising or generating content as part of the workflow
- You're extracting information from sources that don't have a clean API
Even then, AI should handle one narrow step in the workflow, not the whole thing. A human-in-the-loop review step makes sense whenever an AI error would be costly. The goal is to reduce the manual work, not to eliminate oversight entirely.
The Processes That Look Automatable But Aren't
A few categories of process attract automation interest but consistently disappoint.
Anything requiring significant contextual judgment. If the process involves decisions that experienced staff make differently depending on factors that are hard to articulate — relationship history, tone of a conversation, strategic priorities — you're looking at tacit knowledge that automation can't replicate cleanly. You can assist these workflows with AI, but you can't replace the judgment.
Processes that are broken. Automating a broken process doesn't fix it — it makes the problems happen faster and at scale. If people regularly skip steps, make unofficial exceptions, or disagree on what the correct output looks like, fix the process first, then automate it.
Processes that change frequently. If you're still figuring out how your business operates in a particular area, automation will require constant rework. It's often better to keep things manual until the process has stabilised.
A Simple Prioritisation Framework
When you're deciding which processes to automate first, score each one against these four factors:
- Frequency — How often does this happen?
- Time cost — How long does it take, multiplied by how many people are involved?
- Error cost — What's the consequence of a mistake?
- Consistency — How standard is the process?
The best automation targets score high on the first three and have a consistent, documentable process. Anything low-frequency with low error cost and high variability goes to the bottom of the list regardless of how annoying it feels to do manually.
Getting Started
If you've identified a process that scores well on the framework above, the next step is to document it in detail. Write down every step, every input, every decision point. This documentation becomes the spec for whatever tool or developer builds the automation.
Then start small. Automate one step, not the whole workflow. Verify it's working correctly in production before adding complexity. The goal for a first automation is to build confidence in the approach and identify integration issues early, not to solve the entire problem at once.
If you're not sure where to begin, or if you have a complex process that involves multiple systems, this is exactly the kind of problem a short advisory engagement can help with. I can usually tell within a conversation whether a process is a good automation candidate and what approach is likely to be cost-effective for your situation.
You can read more about how I approach this kind of work, or get in touch directly if you have a specific process in mind.