How to choose your first workflow to automate.

1. List the work people keep repeating

Ask the people doing the work to name three recurring tasks. Good candidates might include transferring enquiry details, chasing an approval or preparing a standard document. For each, record how often it happens, who does it and where the information starts and ends.

Watch a recent example from beginning to end. The written procedure may miss a spreadsheet check, an informal message or a decision only one colleague knows how to make. These details affect what you can automate.

2. Compare effort with readiness

Frequency and effort show where an improvement might matter. Readiness shows whether the process is a sensible first project. Use the questions below to compare your candidates; treat unknown answers as things to investigate.

• Does the task happen often enough to justify building and maintaining a workflow?
• Can someone explain the normal steps and the common exceptions?
• Is the required information accessible and consistent?
• Can a person review the result and recover from a mistake?
• Is someone responsible for keeping the process working?

A frequent task with changing rules may need process clarification first. A less ambitious task with stable inputs can be a better place to learn.

3. Estimate the opportunity honestly

Multiply the number of times a task happens each week by the hands-on minutes it takes. For example, 30 requests taking six minutes each represent three hours of weekly effort. If two minutes of review remain per request, the theoretical reduction is two hours before allowing for exceptions and upkeep.

This is an illustrative calculation, not a promised saving. Record waiting time separately: an approval can spend a day in an inbox while requiring only a few minutes of actual work.

4. Write a one-page pilot brief

Give the workflow a start and a finish. For an enquiry process, that might be a form arriving through to an owner accepting the request. Write down:

• The trigger, required information and expected result.
• The systems involved and who can grant appropriate access.
• The decisions that need a person's review.
• What happens with duplicates, missing details or a failed connection.
• The owner, test examples and measures of improvement.

Keep connected tasks outside this boundary on a separate list. They can be considered after the pilot is understood.

5. Test the awkward cases before expanding

Try a normal request, incomplete information and a repeated submission. Check whether someone can see a failure, correct the problem and continue without creating duplicate work. Then run a limited pilot with the people who own the process and compare effort, errors and waiting time.

If Microsoft tools are involved, Microsoft's Power Automate training offers further background. For help applying this exercise to your business, bring your pilot brief to Launch Interest.