Is This Process Worth Automating? Here's How to Know.

It started with a spreadsheet.

A business owner I worked with — small operation, twelve employees, good at what they did — spent every Monday morning doing the same thing. Pulling numbers from three different systems, pasting them into a spreadsheet, doing a little math, formatting it, and emailing it to himself so he could review it before the week started.

Two and a half hours. Every single Monday. For four years.

When I pointed out that we could automate the whole thing in a week, he looked at me the way people look at someone who just told them their shoelace has been untied for years. A little embarrassed. A little relieved. Mostly just ready to fix it.

That's the easy case. The process is repetitive, the steps are clear, the data is structured, and the outcome is measurable. Automate it and move on.

But not every process is that obvious. And I've watched businesses spend serious money automating the wrong things — things that didn't actually need automation, or weren't ready for it, or had a human judgment call buried in the middle that no tool can replace.

So before you talk to a vendor, before you start a pilot, before you spend anything — here are five questions that will tell you whether a process is actually worth automating.

1. Does it happen often enough to matter?

   Automation has a setup cost. Time to design, build, test, and train. If the process only happens twice a month, the math rarely works in your favor — at least not as a starting point.

   The sweet spot is something that happens daily, or multiple times a week, or in bursts that predictably overwhelm your team. That's where the hours add up fast enough to justify the investment.

   Ask yourself: If I add up every hour spent on this process in a month, does it exceed the effort required to automate it? If yes, you have a candidate. If no, there's probably a higher-value target elsewhere.

2. Are the steps the same every time?

   This one trips people up. A process can feel repetitive without actually being consistent.

   "We process invoices every day" sounds automatable. But if every invoice requires a slightly different judgment call — this vendor gets net-30, this one gets a discount if paid early, this one goes to a different GL code based on context — you don't have a repeatable process. You have a repeatable starting point followed by human decision-making.

   Automation handles steps well. It handles decisions poorly — unless you can define the decision rules precisely enough to encode them.

   Ask yourself: Could I write out every step of this process as a numbered list, and would that list look the same every time? If the answer is yes, it's automatable. If "it depends" appears more than twice, you need to define the rules first.

3. Is the data already digital — and is it clean?

   This is the one nobody wants to hear.

   AI and automation run on data. If your data lives in a spreadsheet maintained by one person, or a system that only exports to PDF, or a combination of sources that don't agree with each other — automation won't fix that. It will break on it.

   I've seen automation projects stall for months not because the technology was wrong, but because the underlying data was too inconsistent to trust. Garbage in, garbage out is not a new concept, but it catches people off guard when they discover it mid-implementation.

   Ask yourself: Where does the data come from? Is it in a structured, queryable format? Is it consistent across records? If the answer is "mostly" or "we think so" — clean the data first. Automation second.

4. What does a mistake cost?

   Not all processes are equal when something goes wrong.

   A report with a wrong number that gets caught in review before it goes out? Low stakes. A customer-facing communication that goes out with incorrect information? Higher stakes. A financial transaction that processes incorrectly? Very high stakes.

   This doesn't mean you can't automate high-stakes processes — you can. But it means you need to design in a human review step before the output leaves the building. That changes the economics and the architecture.

   Ask yourself: If this process produces the wrong output, who finds out, when, and what's the cost? The answer tells you how much human oversight to build in — and whether this is a "automate with confidence" situation or an "automate with a safety net" one.

5. Is there a human who needs to own it after it's built?

   This one is almost never asked. It should be the first question.

   Every automated system breaks eventually. Data changes. Business rules change. Upstream systems get updated. When that happens, someone needs to notice, understand what went wrong, and know what to do about it.

   If no one inside your organization understands the automated process well enough to maintain it — or even to notice when it's producing bad output — you've traded one problem for another.

   The best implementations I've been part of always had one person inside the business who was curious, engaged, and took ownership. They weren't necessarily technical. They just cared whether the thing worked, and they were willing to learn the basics.

   Ask yourself: Who inside my business will own this after it's built? Not manage the vendor relationship — own the process. If you can't name that person, don't start yet.

Putting it together

Here's the short version. A process is worth automating when:

• It happens frequently enough that the time savings justify the setup cost

• The steps are consistent and the rules can be clearly defined

• The data is structured, accessible, and reliable

• The cost of errors is understood and human review is built in where needed

• Someone inside your business is ready to own it

Miss any one of these and you're not automating a process — you're accelerating a problem.

The business owner with the Monday morning spreadsheet? We had his report running automatically by Wednesday of the following week. He gets it in his inbox at 7:00 AM every Monday now, before he's even had coffee.

Two and a half hours back. Every week. He uses it to actually think about his business instead of assembling data about it.

That's what automation is supposed to do.

Jim Shelly is the founder of pokkit IT, a technology consulting practice that helps small and midsize businesses solve real operational problems. If you're trying to figure out where automation fits in your business, start with a 30-minute conversation.