How to choose your first workflow to automate

Ask a team what should be automated and you'll probably get a long list. Reports, invoices, customer messages, bookings, stock updates. Most of the suggestions will be reasonable. You still need somewhere to start.

Your first workflow should be useful enough to matter and small enough to understand. It should also teach you whether the systems, rules and people can support the change.

Set aside a short working session with the people doing the tasks. Bring examples from an ordinary week, including something that went wrong.

1. List the repeated work in plain language

Write down tasks such as “copy accepted quotes into the order system” or “prepare Monday's stock report.” Avoid starting with a tool or a technology. “Use AI” is not a workflow.

For each task, record the trigger and the finished state. An enquiry arriving is a trigger. An assigned follow-up with the customer's details attached is a finished state.

If a task has no clear end, narrow it until you can describe one.

2. Measure a sample week

Record frequency, typical time, people involved and systems touched. Note errors and waiting time separately. Ten minutes of typing and two days waiting for approval are different problems.

The worksheet below uses invented examples to show how a comparison might work. Its time totals describe current effort, not promised savings; review and maintenance would still take time.

Candidate	Current effort	What needs checking
Weekly stock report	1 run × 90 minutes = 90 minutes	Two stable exports; one report owner
Accepted quote handoff	30 quotes × 4 minutes = 120 minutes	Reliable product codes; supported order creation
Supplier exceptions	8 cases × 20 minutes = 160 minutes	Different decisions each time; rules unclear

The largest total isn't automatically the best first project. The supplier exceptions might need process clarification before automation. The report could be a good first pilot if it has reliable inputs and an easy way to compare the result.

3. Count the handoffs, not just the minutes

Ask how many people touch the work and where it waits. A task can be short but disruptive because it interrupts three teams or repeatedly loses context.

Look for a named owner who can make decisions about the process. If every question ends with “someone in another department will know,” bring that person into the conversation before estimating a build.

4. Check whether the systems can support it

Can you read the source record? Can the destination accept the update? Are customer and product references consistent? Does your subscription include the required access?

This is where a technical check earns its place. A business idea can be attractive and still need a different implementation because the existing tool only supports a nightly file import.

1. 01Useful repeated work
2. 02Clear rules and owner
3. 03Supported system access
4. 04A result you can compare

5. Choose one normal path and one exception

For the quote handoff, the normal path might be a known customer ordering standard products. A useful exception is an unknown product code that must stop the order and notify a person.

Write down what the pilot will do, what stays manual and how you'll tell whether it helped. Include who checks the results and who can pause the automation.

Don't make “automate sales” the first milestone. “Create one checked order from an accepted standard quote, with uncertain records held for review” is something you can test.

Take this into your first discussion

Bring three candidate tasks, your sample-week observations and one example of each task. Circle the process with clear inputs, an available owner and a result you can verify.

You may not have enough information to choose yet. That's fine. A short list of specific unknowns is a better starting point than a large automation wish list.