Describe a finished piece of work
“Automate operations” is too broad to compare with a budget. “Turn an approved order form into one complete draft order for an operator to check” gives you a beginning, an end and a person responsible for the result. Start by writing that sentence for two or three candidates.
Microsoft’s Power Automate planning guidance begins with the problem, the people using the process and their goals. Use that discipline before choosing a platform or an AI model. A step that feels repetitive may exist only because another team receives incomplete information. Removing the unnecessary step or fixing the input can be the better first move.
Gather representative completed cases with the people who do the work. Record active handling time separately from waiting time, the systems involved, missing inputs and the decisions people make. Include busy periods and exceptions. A handful of easy examples can help you map a process, but cannot establish its usual volume or exception rate.
Resolve these conditions before ranking candidates
A large projected saving cannot settle an undefined approval rule. Mark each candidate as ready to test, needing preparation or remaining manual for now. These are operating decisions, not scores to average away.
- An accountable owner can define the correct result and resolve exceptions.
- The trigger, required inputs and permitted actions can be described and demonstrated.
- The necessary data and system access are available through an approved integration method.
- The team can identify incomplete or duplicate work, stop the automation and continue safely.
- Someone has capacity to review exceptions and maintain the workflow when systems or rules change.
A hypothetical shortlist for a distributor
| Candidate | What the team finds | First decision |
|---|---|---|
| Create draft orders from approved forms | Recurring work, structured inputs, one order-desk owner and a draft that can be checked before release. | Test a limited set of order types after verifying access and duplicate handling. |
| Approve customer refunds | Frequent requests, but sales and finance disagree about exceptions and approval authority. | Agree the policy and owner first. Keep approval with people while that is unresolved. |
| Prepare a monthly internal summary | Clear inputs and low consequence, but only a small amount of manual work each month. | Compare a saved report or simpler configuration with building and supporting a new automation. |
Count the work that remains
Continue the hypothetical order example. Suppose the team handles 240 eligible orders a month at four active minutes each: 960 minutes. For a proposed pilot, assume 192 routine orders would take one minute each to review, while 48 exceptions would still take four minutes each. Add 120 minutes a month for monitoring and administration.
That leaves 504 minutes of recurring work: 192 for routine review, 192 for exceptions and 120 for monitoring. The difference is 456 minutes, or 7.6 hours of potential monthly capacity. These figures are planning assumptions to test, not a forecast or a client result. If exceptions take longer after automation, that extra work belongs in the calculation too.
Capacity is not automatically cash saved. Identify what the team would do with the recovered time. Compare implementation, licences, integration, training and ongoing support costs separately over a common planning period. Also track outcomes that matter beyond minutes, such as fewer incomplete orders or a shorter queue, without counting the same benefit twice.
Run the comparison again with a less favorable exception rate and more review time. If the case only works when almost everything succeeds without attention, narrow the scope or gather better evidence before committing.
Choose a small outcome with a complete recovery path
For the distributor, the first pilot could accept one approved form type, validate required fields and create a draft order. An operator still checks and releases it. Requests with missing information go to a visible queue with an owner. Refunds, stock promises and customer messages stay outside this pilot.
Before testing, agree how the team recognizes the same request twice and how it checks whether an order was already created after an uncertain response. A retry should not create a second order. Microsoft’s error-handling guidance describes failure paths, retries for temporary faults, stopping on critical errors and notifying the responsible people. The implementation must make those controls appropriate to the systems involved.
Check whether the existing platform can provide the workflow through configuration. Use an integration or a focused custom component where a verified gap remains. If reading unstructured requests requires AI, evaluate that step separately and keep its output subject to the agreed checks. The first workflow does not need an AI agent simply because AI is available.
Set the evidence for expanding, changing or stopping
Define a trial scope and observation period that include the variations you expect to operate. Record all eligible cases, including those sent to manual handling. Measure actual review time, exception time, monitoring effort, incomplete work and duplicates against the current process. A high completion rate among only the easiest cases would give the wrong picture.
Agree acceptance criteria before the trial. For example, the order pilot must preserve every eligible request, create no duplicate draft in the tested cases, expose failures to the owner and demonstrate safe manual continuation. These checks do not prove every future case will succeed. They establish whether the limited workflow is ready for the next decision.
If preparation remains unresolved, pause the affected scope. If the workflow works but does not improve the agreed outcome enough to justify its operating effort, revise it or stop. Expand only when the operating evidence supports it. A useful first automation gives the business both a completed task and a manageable responsibility.
Sources and further reading
Choose a useful first automation.
Bring two or three workflows, the systems they use and where the work gets stuck. We can help define a focused scope and the checks it needs.
Discuss your workflow


