Start with a repeated process that has a clear owner, understandable rules, accessible information, and a measurable operational cost. A focused handoff is usually easier to evaluate than an attempt to automate an entire department.
List the recurring friction
Ask a team member to describe work completed during a normal week. Look for repeated entry, repeated requests for missing information, status chasing, report preparation, and approval coordination. Name the trigger and the final outcome of each process.
“Improve operations” is too broad. “Move an approved customer record from the CRM into the project setup process” is specific enough to examine.
Score the opportunity before choosing a tool
| Question | A useful sign |
|---|---|
| Does it repeat? | Enough comparable work to justify maintaining a workflow. |
| Are the rules clear? | The owner can describe the normal path and common exceptions. |
| Is the information accessible? | Required records can be accessed with appropriate permissions. |
| Can the result be measured? | A baseline exists for time, errors, waiting, or rework. |
| Can mistakes be contained? | A pilot can run with review and a recovery process. |
Separate effort from waiting
A process may take three days while requiring only twenty minutes of work. If the delay is an approval waiting for a busy manager, faster data entry may barely change the outcome. Measure both active handling time and elapsed time.
That distinction helps select the intervention. A clearer approval rule or visible queue may solve more than an AI component.
Use a transparent baseline
Suppose a team handles 40 similar requests per week and spends eight minutes copying information for each request. That is 320 minutes, or five hours and twenty minutes, of weekly handling time. This is a hypothetical baseline calculation, not a savings claim.
Any estimate of recovered capacity must subtract residual review, exception handling, and maintenance. Recovered time also does not automatically become cash savings; it may instead create capacity for other work.
Run a bounded pilot
Choose one process owner and one request type. Document test cases before building: normal records, missing fields, repeated submissions, failed connections, and unusual decisions. Agree on who can stop the workflow and how to recover unfinished work.
Compare a pilot against the baseline using similar work. Review whether employees can use the system and whether exceptions remain manageable. Expand only when the process works consistently enough for the intended use.
What to prepare for discovery
Collect five recent examples, approximate volume, the tools involved, required permissions, current handling time, and the most common exceptions. Those details are more useful than a long list of preferred automation platforms.
Common questions
Should the first project have the highest possible ROI?
Consider value alongside feasibility, operating risk, and the ability to test. A smaller measurable improvement may establish a stronger foundation than a broad project with uncertain assumptions.
What if the process changes every week?
Clarify which parts are stable and which require judgment. Automate the stable portion and preserve human review for changing or ambiguous decisions.
Sources & further reading
Microsoft Learn: Power Automate guidance ↗
Further reading on building, securing, monitoring, and governing automation. The prioritization framework above is Ecomssentials’ recommended approach.