How to Run an Automation Needs Analysis Before You Build

The most expensive automation in most companies is the one that took three weeks to build and saves eleven minutes a week. It works. Everyone praises it in the retro. Fourteen months later a field name changes upstream, it fails silently for a month, someone spends two days reconciling the damage, and the whole thing is quietly switched off. A proper automation needs analysis would have killed that project on day one, using nothing more sophisticated than multiplication.

That is the argument of this piece. An automation needs analysis is arithmetic with a few disqualifiers bolted on. Frequency times handling time times a loaded rate, plus the expected cost of the errors the process currently produces, minus the cost of keeping the automation alive forever. If the result is not comfortably positive, you have found a process to document, simplify, or delete, not one to automate.

What an automation needs analysis actually measures

The question people ask is "what could we automate?" That question has a boring answer: almost everything, eventually, badly. The useful question is "which processes to automate first, given that every automation we ship becomes a permanent liability against upstream change?"

So a process automation assessment measures four things, three on the benefit side and one on the cost side.

Recovered handling time. How many minutes of human attention the process consumes per year, multiplied by what those minutes cost. Not elapsed time. Touch time.

Avoided error cost. What it costs when the process goes wrong today, multiplied by how often that happens. This is where the real money usually hides, and it is the number most teams never write down.

Latency value. What it is worth to know something sooner. A failed payment caught in an hour instead of at month end has a value that has nothing to do with the minutes spent looking.

Lifetime maintenance. The hours per year someone will spend fixing this automation after an API version bumps, a form field is renamed, a person leaves, or a vendor deprecates an endpoint. This number is never zero and it never goes down on its own.

Most automation opportunity analysis templates you will find online stop after the first item. That is why so many automation programs produce a graveyard of tiny scripts that each save a few minutes and collectively consume an engineer.

The arithmetic: five numbers and one honest coverage factor

Write these down per candidate process. Use your own figures. Any article that hands you industry benchmarks for "average time spent on manual data entry" is selling something.

• F = runs per year. Count them from a system, not from memory. Memory inflates by a factor that is itself worth measuring.
• T = minutes of human touch time per run. Sit with the person and time it. Elapsed time is the wrong number, because a two-day approval cycle may contain four minutes of work.
• R = loaded hourly cost of the person doing it. Salary plus overhead, divided by working hours.
• E = annual error cost. Incidents per year times average cost per incident, including the rework, the credit issued, and the trust spent.
• M = annual maintenance cost. Expected fix hours per year times the loaded rate of whoever fixes it. If nobody is named, this number is infinite, see disqualifier four.

Then apply the factor that separates a serious automation needs assessment from a slide deck: C, the coverage fraction. C is the share of runs the automation handles end to end without a human touching it. For structured, high-volume, rules-based work, C might be high. For anything involving judgment, unstructured input, or exceptions that arrive by email, C is frequently under half, and the runs that fall out are the slow ones.

Net annual value looks like this:

(F x C x T x R / 60) + (E x error reduction) + latency value, minus M, minus (build cost / expected life in years)

Two adjustments that experienced teams make and everyone else discovers the hard way. First, exception handling is usually slower than the original manual process, because the human now has to work out what the machine did before deciding what to do. Budget exceptions at 1.5x the original handling time, not 1x. Second, expected life is rarely more than two to three years for anything wired into a SaaS tool you do not control. Amortize accordingly.

Worked shape, using round numbers you should replace with yours. A process runs 250 times a year, takes 12 minutes of touch time, done by someone at a loaded rate of 60 per hour. That is 250 x 12 / 60 x 60 = 3,000 per year of handling cost. At a coverage factor of 0.7, with the remaining 30 percent of runs costing 1.5x, the recovered amount is closer to 1,750. If maintenance runs one hour a month at the same rate, that is 720 gone. If the build took 30 hours of engineering time and lives two years, that is another 900 to 1,800 per year depending on your engineering rate. On handling time alone, this is a losing project. It only becomes a winner if E, the error cost, is meaningful, or if latency matters.

That is the whole insight. Most automations do not pay for themselves on time saved. They pay for themselves on errors avoided and on knowing sooner. Score accordingly.

The scoring sheet

Score every candidate on these eight dimensions. Multiply by the weight, sum, and rank. The weights below reflect the argument above: stability and ownership matter more than raw volume, because an unmaintained automation has negative value.

Maximum score is 105. In practice, treat the results as bands rather than a leaderboard.

The band boundaries are yours to move. What matters is that the sheet forces you to write numbers next to opinions, and that low standardization or missing ownership can sink a high-volume process. That is deliberate.

The four disqualifiers

Before the arithmetic runs, four conditions disqualify a candidate outright, regardless of how good the numbers look. A candidate that trips any of these should not be scored, it should be sent back.

1. The rules change faster than you can ship. If the logic behind the process is renegotiated monthly, by a person rather than a policy, you are automating a moving target. Every rule change becomes a change request, and the change request queue becomes the new bottleneck. The tell: nobody can write the rules down without saying "it depends who asks."

2. There is no clean system boundary. If the only way in is a browser session, a PDF, or a screen a vendor redesigns without notice, your automation is a robot pretending to be a person, and it will break on the first CSS change. Sometimes there is genuinely no alternative, in which case go in with open eyes and read Robotic Process Automation Companies: 2026 Landscape for how that market has actually settled. But treat "no API" as a two-point deduction on the whole project, not a technical detail.

3. Silent failure costs more than the process saves. Ask the failure question directly: if this runs wrong for thirty days and nobody notices, what happens? If the answer involves money leaving the company, a customer being told something untrue, or a filing being wrong, the automation needs monitoring, reconciliation, and an audit trail, and those cost more than the automation itself. That is not a reason never to build it. It is a reason to price it honestly, and to build the alert before you build the action.

4. No owner with capacity. Not a team, a person. Someone whose name goes on it, who will get paged when it breaks, and who has enough room in their week to fix it. Automations without owners do not get switched off when they go wrong, they get worked around, which is the worst of both worlds: the cost of running it plus the cost of the manual process someone quietly restarted.

There is a fifth condition worth naming even though it is not strictly a disqualifier: if the process exists only because two systems disagree about the same customer, the automation will faithfully propagate the disagreement. Fix identity first. This is also why the honest answer to some tooling questions is consolidation rather than automation, which is the argument in CRM vs Marketing Automation: Do You Really Need Both?.

When a scheduled brief beats an automation entirely

Here is the rule, and it is the most useful thing in this article.

Split the handling time into gathering and doing. If gathering is the larger share, and the right action varies case by case, build a scheduled brief instead of an automation.

Most knowledge work that feels automatable is not one process, it is a lookup followed by a judgment. Someone opens four tabs, assembles a picture, and then decides. The four tabs are mechanical. The decision is not, and it is the decision that carries the risk. Automate the tabs, keep the human.

A brief has three properties that a transactional automation does not:

It degrades gracefully. When a source goes down, a section of the brief is missing and a human notices immediately. When a transactional automation loses a source, it may post something wrong and stay quiet about it.

Maintenance is bounded. A brief that reads and summarizes has a small surface area. Nothing it does is irreversible, so a bad run costs attention, not money. M in the arithmetic above drops sharply.

It captures the latency value, which is where the money was. Going back to the numbers: latency and error avoidance usually beat time saved. A brief delivers both without taking on write access to anything.

The pattern in practice is unglamorous and reliable:

Answer-and-alert pattern: gather, flag, hand to a human

Weekday 07:00

Scheduled trigger, before the first meeting

Read billing

Failed charges, refunds, downgrades since last run

Read CRM

Owner, renewal date, stage changes

Read shared inbox

Threads mentioning the same accounts

Apply exception rules

Only surface what crosses a written threshold

Compose brief

Each item cites the source record it came from

Post to the owning channel

Human decides and acts; nothing is written back automatically

Run the brief for a quarter. Two things happen. Either the humans start acting on it, in which case you now have a measured record of how often each exception fires and what the right action was, which is exactly the specification you needed to automate the process properly. Or nobody acts on it, which tells you the process was never worth automating and you have learned that for the cost of a scheduled job. Both outcomes are wins. The same logic drives the alert-first approach in Retail Performance Monitoring Tools That Flag Problems.

Running your automation needs analysis in one week

You do not need a consulting engagement. You need five focused sessions.

Monday: inventory. List candidate processes at the level of "someone does X every Y." Aim for 20 to 40 lines. Sources: the recurring calendar entries with no attendees, the spreadsheets with a date in the filename, the checklist pinned in a channel, and the answer to "what did you do last Friday afternoon?"

Tuesday: count. For the top 15, get F from a system. Ticket counts, invoice counts, message counts, export counts. Guessing here corrupts everything downstream.

Wednesday: time it. Sit with people for the top 10 and time actual touch time on three real runs each. Ask what fraction of runs are exceptions and how long those take. This is the day the list reorders itself, because two of the processes everyone complains about turn out to be four minutes a week and one nobody mentions turns out to be six hours.

Thursday: score and disqualify. Run the sheet. Then run the four disqualifiers. Expect half your top candidates to fall out, most often on standardization and ownership.

Friday: choose three and write kill criteria. One to build, one to run as a brief, one process to simplify or delete. For each of the first two, write the condition under which you switch it off: a review date, a minimum number of runs, a maximum number of exceptions per month. An automation opportunity analysis without kill criteria produces the graveyard described at the top of this page.

If the survivors are shaped like connectors and branching logic, n8n Automation: 12 Workflow Examples Worth Copying is a good place to see what those builds look like in practice before you commit. For personal-scale processes that show up on the same inventory, Personal Knowledge Management System: A Setup That Lasts covers the version of this analysis that fits one person.

Where Skopx fits, and where it does not

We build Skopx, so treat this section as a disclosure rather than a recommendation.

Skopx is an AI workspace that connects to nearly 1,000 tools a company already uses, including Gmail, Slack, Stripe, HubSpot, QuickBooks and Google Analytics. It answers questions in chat with cited data from those tools, sends a morning brief, runs an insights engine that surfaces anomalies and risks, and lets you build workflows by describing them in chat. You bring your own AI key for any major model with zero markup. Solo is $5 per month and Team is $16 per seat per month, so you can see the pricing and the workflows before deciding whether it belongs anywhere near your shortlist.

Where it fits the analysis above: the answer-and-alert category. Processes that scored 60 to 79, where the gathering is mechanical and the deciding is not. Cross-tool lookups, scheduled briefs, exception flagging, "tell me when this crosses that." Those are cheap to stand up and cheap to maintain, which is precisely why they survive the maintenance term in the arithmetic.

Where it does not fit, stated plainly: Skopx is not a business intelligence or dashboard-building tool, not a data warehouse, not an ETL platform, and not a CRM. It is not the right answer for heavy transactional processing either. If your winning candidate is posting thousands of invoices to a ledger, running three-way matches at volume, or executing payroll, you want a purpose-built system with the reconciliation and audit trail that category has spent decades building. Start with Accounting Automation Software: What to Automate First and Invoice Automation Software: How to Choose and Roll Out instead. Using a conversational workspace for high-volume ledger writes would be a category error, and it is one we would rather you avoid than discover.

Common ways an automation needs analysis goes wrong

Counting elapsed time instead of touch time. A three-day process is not three days of work. This single mistake inflates business cases by an order of magnitude and is the most common flaw in a process automation assessment.

Automating the loudest complaint. Irritation and cost are uncorrelated. The task people complain about is often small and annoying. The task that is genuinely expensive is usually invisible because it has been absorbed into someone's normal week.

Ignoring the exception tail. If 20 percent of runs are exceptions and each takes 1.5x the original time, coverage of 80 percent recovers far less than 80 percent of the cost. Model it before you build it.

Skipping elimination. Ask why the process exists before asking how to automate the process. A surprising share of recurring work is a report nobody reads, a reconciliation between two systems that should be one, or a control that a policy change would remove. Deleting a process returns 100 percent of its cost with zero maintenance.

Letting a vendor scope it. Any assessment run by the party that profits from the build will find that a build is warranted. Do the arithmetic yourself first, then talk to vendors with numbers in hand.

No review date. Every shipped automation should have a calendar entry six months out that asks: is this still running, is it still right, and does anyone still need it? Half of them will fail at least one of those questions.

Frequently asked questions

How long should an automation needs analysis take?

A week for a department, using the five-day sequence above. Longer analyses are usually longer because they are gathering consensus rather than gathering numbers. If you are three weeks in and still building the inventory, the inventory has become the project. Cut to the top ten by volume and start timing.

What is the minimum volume worth automating?

There is no universal threshold, because error cost and latency value can carry a low-volume process. A quarterly filing that runs four times a year can absolutely justify automation if getting it wrong is expensive. Conversely, a daily task that takes ninety seconds and never causes harm probably should not be touched. Run the arithmetic rather than applying a rule of thumb.

Should we automate the process or fix it first?

Fix it first if standardization scored 1 or 2. Automating a process that three people perform three different ways forces you to pick one way, and that decision is a process change disguised as a technical project. Making the change first, on paper, with the people who do the work, means the automation is implementing an agreed process rather than imposing a new one under a deadline.

How do we estimate maintenance cost before we have built anything?

Count integration points and multiply. A rough starting heuristic that holds up reasonably well: budget two to four hours per external system per year for a stable, documented API, and considerably more for anything that goes through a UI or an undocumented endpoint. Then add the cost of the first breaking change, because there will be one. If you already run automations, look at your own history rather than any published figure.

Does cheaper tooling change the answer?

Less than people expect. Licence cost is rarely the deciding term in the arithmetic, because maintenance labour and error cost dominate it. This is worth remembering when a no-cost tier looks like it solves the problem: the limits usually bite exactly where the value was, a pattern covered in Free CRM Software: What You Get and Where the Limits Hit. Cheap tools change the build cost term, not the maintenance term, and the maintenance term is what kills automations.

What should we do with the processes that fail the analysis?

Document them, then revisit in two quarters. A process that fails today often passes later, because volume grew, the rules stabilized, or a vendor shipped an API. Keep the scored list as a living document rather than a one-off exercise, and rescore when something material changes. The analysis is cheap the second time, because you already know the numbers you need.