Where to automate first: picking the workflow that pays for itself

The instinct is to automate whatever feels most visible or most impressive to show off — a customer-facing process, say. The workflow that actually pays for itself fastest is usually less glamorous: repetitive, high-volume, and rules-based, with a clear before-and-after number attached to it.

Finding the process worth automating

Map every manual touchpoint across the business and ask a few direct questions of each: which process consumes the most hours from the team every week? Which one generates the most rework or complaints when it goes wrong? Which one, if it stalls, actually affects a customer or revenue? A simple 2×2 — impact against complexity — sorts candidates fast: high impact and low complexity is your quick win; high impact and high complexity is worth planning for later; low impact and low complexity can wait.

What makes a process a good first candidate

The best first automation is a process with clear inputs and outputs, available data, and a workflow where human judgement drives fewer than roughly 30% of decisions. A process requiring constant human judgement calls tends to need frequent intervention once automated, which undermines the whole point and pushes staff back to doing it manually anyway.

Working out the ROI before you build anything

A rough estimate is enough to start: monthly task volume, multiplied by manual minutes per task, multiplied by the loaded hourly cost of the person doing it — then weighed against what building, running, and maintaining the automation will cost. That simple sum is usually enough to decide whether a process is worth automating at all before any development work begins.

What a realistic timeline looks like

Structured automation projects commonly show measurable efficiency gains within three to six months, not years. A useful discipline is a 90-day review checkpoint: track hours saved, error rate, and cycle time before and after, and if savings are running well below what was projected, that's the signal to investigate exceptions and integration issues before automating the next process rather than assuming the first one simply failed.

The mistakes worth avoiding

Automating a process nobody has properly mapped yet, automating something highly exception-driven, and choosing the most visible process over the one actually consuming the most internal hours are the three failure modes that show up again and again. Fix the underlying workflow first — automating a broken process just makes the mess move faster.