The Five Questions to Ask Before You Automate Anything

Most failed automation projects fail before a single line of code is written — at the decision of what to automate. Five questions — frequency, consistency, consequence, judgement, and documentation — separate a process that's ready to automate from one that will waste your money. Hypajump runs this exact filter before quoting any build.

TL;DR

• Most failed automation projects fail before a single line of code is written — at the decision of what to automate
• The right question is never "should we use AI." It's "is this specific process worth automating right now."
• Five questions separate a process that's ready from one that will waste your money: frequency, consistency, consequence, judgement, and documentation
• A process that fails on any one of these is either not ready or not worth it yet
• You don't need to automate everything. You need to find the one process that passes all five — and start there.
• Hypajump runs this exact filter before quoting any build. If a process doesn't pass, we say so.

Why the Decision Matters More Than the Tool

The most expensive mistake in AI automation isn't choosing the wrong tool. It's building the right tool for the wrong process.

A tool can be swapped. But a process that changes constantly, depends on judgement at every step, or was never properly understood will produce an automation that breaks, needs constant maintenance, and gets abandoned within months. The money is gone. The problem is still there. And the team is now sceptical of automation altogether.

This is preventable. It comes down to five questions asked before anything gets built.

Question 1: How Often Does This Actually Happen?

Frequency is the multiplier on every automation. A process that happens once a month has limited return no matter how long it takes. A process that happens daily, per transaction, or per customer interaction compounds its value every single time it runs.

Ask: how many times a week or month does this task occur? If the answer is "a handful of times a year," it's probably not your starting point — regardless of how painful it is each time.

The best first automation is usually something unglamorous that happens constantly, not something dramatic that happens rarely.

Question 2: Do the Rules Stay the Same Every Time?

Automation depends on consistency. The same inputs need to reliably produce the same outputs, and where there's variation, the logic for handling that variation needs to be known and stable.

Ask: if two different people did this task, would they do it the same way? If the answer is "it depends who's doing it" or "it changes based on the situation," the process isn't rule-based enough yet.

A process where the rules shift constantly — new client requirements every week, changing internal preferences, evolving compliance — will produce an automation that's outdated before it's finished. Stabilise the process first.

Question 3: What Happens When It Goes Wrong?

Not every repetitive task is worth automating just because it's repetitive. The processes worth the investment are the ones where errors have real consequences — lost money, delayed work, damaged client relationships, or compliance risk.

Ask: when this task is done wrong, what does it cost? If the honest answer is "not much," the ROI case is weak even if the process is frequent and consistent.

Consequence is what turns a nice-to-have into a genuine business case. High-consequence processes are where automation earns its keep, because reliability matters most there.

Question 4: Does a Person Genuinely Need to Do This?

This is the most important question, and the one most businesses get wrong.

There's a difference between a step that requires human judgement — experience, context, a decision that varies based on things not captured in the inputs — and a step that just has a human doing it because it always has.

Ask, for each step: is a person genuinely required here, or is this mechanical transfer? Information moving from one format to another. Data entered from one system into another. Documents reformatted to meet a template. None of those need a person. They need consistency, which is exactly what software provides.

Most processes are a mix. The opportunity lives in separating the mechanical steps from the judgement steps — and automating only the mechanical ones.

Question 5: Can You Actually Write It Down?

The final test. If nobody can explain the process end to end in writing, it isn't ready to automate — because you can't build reliably against something that only exists in someone's head.

Ask the person who does the task to write out every step, including how they handle the three most common exceptions. If they can't, the process needs documentation before it needs automation.

This step surfaces surprises about 60% of the time — undocumented decision points, exceptions that happen more often than anyone realised, steps three different people do three different ways. Finding those before you build is the difference between an automation that works and one that constantly breaks.

What to Do With the Answers

A process that passes all five questions — frequent, consistent, consequential, mechanical, and documentable — is a strong automation candidate. Build it.

A process that fails on one is usually fixable. If it fails the documentation test, document it. If it fails the consistency test, stabilise it first.

A process that fails on several isn't ready, and no tool will change that.

Hypajump's recommendation: Run every candidate process through these five questions before you spend a dollar on a build. We do exactly this before quoting any project — and if a process doesn't pass, we tell the client it isn't ready rather than building something that won't hold up. The filter costs an afternoon. Skipping it costs multiples of the build.

Common Queries

How do I know which process to automate first in my business? Run your candidate processes through five questions: how often it happens, whether the rules stay consistent, what errors cost, whether a human is genuinely required, and whether it can be documented end to end. The process that passes all five with the highest frequency and consequence is your starting point.

What makes an automation project fail? Most failures trace back to the decision of what to automate, not how. Automating a process with too many exceptions, one that changes constantly, or one that was never properly documented produces a tool that breaks and gets abandoned. The five-question filter prevents this.

Should I automate my most complex process or my simplest one first? Neither extreme. Start with the process that has the highest frequency and clearest rules — not the most complex one, which adds build risk, and not the most trivial one, which delivers little return. The unglamorous, high-volume, rule-based process is almost always the highest-ROI starting point.

How long does it take to assess whether a process is ready to automate? For a single, well-understood process, an afternoon is usually enough to run the five questions and produce a process map. That map then becomes the specification for the build — so the time is never wasted, even if the answer turns out to be "not yet."