What's the quickest way to tell if a process is a good automation candidate?

Check three things — is it repetitive and high-volume, is it judgment-light (rules-based rather than requiring deep expertise), and is the current cost of doing it manually measurable? If all three are true, it's usually a strong candidate.

Should small teams bother automating, or is it only worth it at scale?

Small teams often see the fastest relative payoff, because a few hours saved per week matters more against a small headcount. The absolute savings are smaller than at enterprise scale, but so is the cost of building a scoped automation — the ratio can still be very favorable.

How do you account for the cost of things the automation gets wrong?

Estimate an error rate based on a pilot or a sample of real cases run through the proposed automation, and multiply it by the cost of catching and fixing that kind of error. A credible ROI estimate always nets out this cost — an automation that saves time but silently introduces expensive errors isn't actually a win.

How to Estimate ROI Before You Build an AI Automation

Before committing engineering time to an AI automation, it's worth running the numbers — not because the answer is usually no, but because a rough estimate up front tells you which process to automate first, and stops you from building something that looks impressive but doesn't actually save meaningful time.

Step 1: Confirm it's a real automation candidate

Not every repetitive task is a good fit. The strongest candidates share three traits:

High volume. A task done twice a week doesn't justify much engineering investment, no matter how tedious it feels.
Judgment-light. The task follows rules or patterns rather than requiring deep, case-by-case expertise. Judgment-heavy tasks are usually better served by an AI assistant that speeds up a human, not a fully automated replacement.
Measurable current cost. If you can't estimate how many hours it currently takes, you won't be able to estimate the savings either.

Step 2: Estimate the current cost honestly

Multiply the time spent per instance by the volume per month, and by a realistic fully-loaded cost per hour for the person doing it. Include the indirect cost too — time spent double-checking, correcting mistakes, or covering for the person who normally does it when they're out. This is usually a bigger number than it first appears once the indirect cost is counted.

Step 3: Estimate the automation's error rate honestly

This is the step people skip, and it's the one that makes or breaks a credible ROI estimate. Run a pilot — even a small one, on real historical cases — and measure how often the proposed automation gets something wrong or needs human review. Multiply that error rate by the cost of catching and fixing that kind of mistake. An automation that saves ten hours a week but quietly introduces costly errors half the time isn't a net positive; it's a liability with good PR.

Step 4: Net it out

Savings = (current manual cost) − (automation error-correction cost) − (ongoing cost of running and monitoring the automation). If that number is comfortably positive and the volume is high enough to matter, it's worth building. If the margin is thin, it's worth either refining the scope — automating a narrower, higher-confidence slice of the process — or looking at a different candidate process first.

Step 5: Design for the exceptions from day one

The highest-ROI automations aren't the ones that try to handle every case autonomously — they're the ones that confidently automate the common cases and route the rest to a person, with a clear confidence threshold deciding which is which. Trying to force 100% automation on a process that has a long tail of edge cases usually costs more in engineering time than it saves, compared to automating the 80% of cases that are actually routine.

Why this matters more than the build itself

The engineering work to build an automation is usually the easy part. The expensive mistake is automating the wrong process — one that's low-volume, judgment-heavy, or has an error rate that quietly costs more than the manual process did. A rough ROI estimate before you start building is cheap insurance against that mistake.