How to choose your first automation

Choose the repeatable workflow with a clear owner, a reliable input, and a visible payoff. That sentence contains the whole method, but each part is worth unpacking, because most first automation projects fail on one of the three.

Repeatable means it happens often enough to matter

A task that runs twice a year is a bad first candidate, however annoying it is. You want something that occurs weekly at least, ideally daily, because frequency is what turns small savings into real ones and what gives you enough examples to see the edge cases within a few weeks rather than a few years.

Frequency also protects the project politically. A change people feel every Tuesday is remembered. A change people feel every June is forgotten before the next release.

A clear owner means one person can say yes

Automation projects stall when nobody can approve the small decisions. What should happen to a record with a missing reference? Should the system email the customer or the account manager? These questions arrive weekly, and if answering them requires a meeting, the project will take four times as long as it should.

Pick a workflow where one person already owns the outcome and can make those calls in a short conversation. That person is also the one who will notice when the automation starts behaving oddly, which matters more than any monitoring you set up.

A reliable input means the data arrives in a shape you can count on

The most common cause of a disappointing pilot is an input that is only mostly consistent. Files that arrive by email in three different formats, or a form that people fill in creatively, will absorb far more effort than the automation itself. If the input is messy, either fix the input first or choose a different workflow.

This is also the place to be honest about volume. Ten documents a day with predictable structure is a better starting point than four hundred a day in nine formats, even though the second looks more impressive in a business case.

A visible payoff means someone can see the difference

The result should be obvious without a report: a queue that is empty by lunchtime, an inbox that no longer needs triage, a weekly file that simply appears. When the benefit is visible, people defend the project. When it only shows up as a line in a savings calculation, it competes with everything else for attention.

What to do in the first four weeks

Map the workflow as it actually runs, not as the process document describes it. Agree what the system does when it is unsure, in one sentence. Build the smallest version that handles the common case, and route everything else to a person. Then watch it for two weeks and write down every exception.

That list of exceptions is the real deliverable of a first project. It tells you what the second version should handle, and it gives you an evidence-based answer to the question that always comes next: what should we automate after this one.