What to automate first: a practical guide for scaling teams

Somewhere between twenty and fifty people, a company accumulates a layer of manual process that nobody designed. An onboarding checklist in a document. An approval that happens in direct messages. A weekly report someone rebuilds by hand every Monday morning. A reconciliation done in a spreadsheet that only one person fully understands.

None of it is hard. All of it is load-bearing. And none of it has an owner, because it grew rather than being built. This is where the highest-return automation almost always lives — and it is almost never the project anyone is excited about.

Four tests a candidate must pass

Before scoping anything, run the workflow through these. A process that fails two or more is usually a bad first project, however annoying it is.

1. Does it repeat on a predictable rhythm?

Weekly beats monthly; monthly beats quarterly. Frequency is what turns a fixed build cost into a return. Something that happens twice a year rarely justifies engineering, no matter how painful each occurrence is.

2. Can the rules be written down?

If an experienced person can describe the decision procedure — even a complicated one with many branches — it can be automated. If the honest answer is "you just get a feel for it after a few years," you are looking at judgement, and automating judgement is where projects fail.

3. Are the inputs structured, or at least consistent?

Files, forms, records, and even consistently-formatted PDFs are workable. Information that arrives only through conversation is not, until something upstream captures it.

4. Are mistakes detectable?

This one gets skipped and it matters most. If you cannot tell whether the output is right, you cannot tell whether the automation works — you have replaced a slow process with a fast process of unknown quality. Prefer workflows where correctness can be checked against something.

Where the money usually is

Across very different businesses, the same handful of processes come up as the best first projects. They share a property: they sit between systems rather than inside one, which is exactly where off-the-shelf tools stop helping.

• Intake and routing — leads, applications, service requests, or documents that arrive, get classified, get checked, and get sent to the right person. Usually the single highest-volume manual step in a company.
• Reconciliation — invoices against statements, usage against billing, records across two systems that are supposed to agree. Exact matching belongs in code; only genuine exceptions should reach a person.
• Recurring reports — the weekly or monthly numbers that currently live in someone's head and a fragile spreadsheet, rebuilt from source systems on a schedule with every figure traceable.
• Document extraction — bills of lading, contracts, invoices, forms. Almost none of it starts digital, and someone in an office is retyping all of it.
• Internal question answering — an assistant over your own approved documents, so "how do we handle this" stops depending on who happens to be available.

What looks automatable but usually isn't

Being straight about this saves money. These are the requests that most often should be declined, or reshaped before anyone builds anything:

• Anything whose rules change every time it runs — you will be maintaining the automation more than the manual process cost.
• Relationship work. Negotiation, judgement calls about people, and genuinely novel decisions do not compress into rules.
• A process that is broken rather than slow. Automating a bad process makes it fail faster and more consistently. Fix the process first.
• Anything where nobody can say what the correct output looks like. That is a specification problem wearing an automation costume.

How to de-risk the first one

Measure the current process before you change it: handling time per item, volume, error and rework rate. Without a baseline you cannot demonstrate a return, and "it feels faster" does not survive a budget conversation.

Then run the automation alongside the manual process on real work until the outputs agree. Cut over when the comparison says so, not when the calendar does. It is slower to start and dramatically cheaper than discovering a disagreement after the manual process has been dismantled.