What to Automate First in Your Company

Your team already knows what eats their day

Ask the person who issues invoices, the one who ships orders or the one who answers WhatsApp which task they would make disappear if they could. Almost always the answer comes in seconds: copying orders from chat to the dispatch sheet, assembling the same report every Monday, moving data from one system to another. That knowledge is worth more than any tool catalog because it points to where time is actually spent.

The hard part is not finding what to automate, but deciding the order. Starting with the wrong task wastes budget and patience, and leaves your team convinced that automation doesn't work.

Five criteria to order

Google's SRE book calls "toil" the manual, repetitive, automatable work that grows with volume and leaves no lasting value. It's a good definition to recognize candidates: if a task meets those characteristics, it's probably on your list.

Diagnosis: when not to automate yet

• When the process is unclear and each person does it differently: first agree on the process.
• When it happens a few times a month and doesn't cause costly errors.
• When it depends on a system you will change soon.
• When nobody will maintain the automation after it's created.

Procedure

1. Gather the people who execute the tasks and make a list of candidates.
2. For each candidate, describe the current steps in one or two lines.
3. Measure volume and time for two weeks.
4. Note known errors and their consequences.
5. List dependencies: systems, accesses, approvals.
6. Score each candidate in the matrix and rank them.
7. Choose a single one to start and define how you will know if it worked.

Applied example

The most forgotten criterion: dependencies

A task can be repetitive and frequent and still be a poor candidate if it depends on a system that has no way to connect, an access nobody has, or a human approval that cannot be removed. Before choosing, confirm that the data the automation needs is available and that someone can authorize the change. When the process involves several systems, drawing it—even on paper or with BPMN notation—helps see where they intersect.

Limits

The matrix ranks candidates, it does not calculate return. The real value of an automation is measured afterward, comparing against a baseline. It also does not replace a technical review of the systems involved.

Decision criteria in detail

A process with a high score for repetition and volume but with rules that change every week is still not ready: stabilize the rules first.

Complete synthetic example

Synthetic example. A fictional company lists six candidate tasks: sending quotes, logging requests, reconciling payments, generating weekly reports, reminding renewals and updating prices. When scored, payment reconciliation scores highest, but it depends on the bank and accounting. Request logging scores a bit lower, but it is resolved within a single flow.

The company starts with request logging, measures for a month and uses what it learned to prepare reconciliation, which requires agreements with accounting. Example invented.

How to use the downloadable matrix

1. List all candidate tasks without filtering.
2. Score each criterion from 1 to 3 with the person who does the task.
3. Add up by hand or in your spreadsheet; the file contains no formulas.
4. Review the dependencies of the top three.
5. Choose one to start and define how you'll measure whether it adds value.

Questions before buying a tool

• Is the process written down and the same for the whole team?
• Who will maintain the automation when rules change?
• What happens with cases the automation cannot resolve?
• How will you measure time and errors before and after?
• Does the tool connect to the systems you already use or does it require a new one?

How to know if it worked

• The chosen task has a baseline measured before automating.
• The team knows what to do with cases the automation doesn't resolve.
• There is a person responsible for maintaining the rules.
• After one month you can compare time and errors against the baseline.

Plan for the first four weeks

1. Week 1: list and score candidate tasks with the people who do them.
2. Week 2: write the rules for the chosen task and measure the baseline.
3. Week 3: test the automation with a small group of cases.
4. Week 4: compare against the baseline and decide whether to scale.

Diagnosis before starting

• Ask each area to list the three tasks that take the most time.
• Manually measure how long one of them takes for a week.
• Check whether those tasks have written rules.

A second example, in contrast

Synthetic example. A fictional company chooses to automate its weekly reports, which take four hours. When measured, they discover the report is read by two people and one no longer needs it. Instead of automating, they reduce the report to a table of five indicators assembled in half an hour. Contrary to the first example, the best decision was not to automate. Example invented.

What to do when something fails

• If the automation produces errors, revert temporarily to the manual process and correct the rules.
• If nobody uses it, ask why before adjusting.
• If it depends on a person who leaves, document before their departure.

Common mistakes

• Choosing the tool before the task.
• Automating a process that nobody has agreed on.
• Starting with the most complex task to "impress."
• Not measuring how it was done before.
• Not assigning anyone to maintain the automation.

Checklist

• I have a list of candidates made with the people who execute the tasks.
• I measured volume and time for at least two weeks.
• I noted errors and dependencies.
• I chose a single task to start.
• I defined how I will know if it worked.