When high volume hides a poor choice
A team spends hours every week moving information between emails, spreadsheets and internal systems. The activity is repetitive, so automating it seems obvious. After implementation, however, exceptions continue to require manual handling, incomplete records stop the workflow and employees create parallel controls to understand what happened. The automation is running, but rework has only changed places.
The first process should not be chosen by volume alone. It needs a stable enough path, accessible data, manageable exceptions and a result that can be verified. For leaders, a good pilot is not the process that looks most impressive. It is the one that produces reliable evidence about value, limitations and operating effort.
Observe the real process before designing the automated one
Start by following actual cases from beginning to end. Identify where requests enter, which decisions are made, which systems are consulted and how the team resolves missing information. Workshops are useful, but they often describe the expected process rather than all the variations that occur in practice.
Microsoft's documentation explains that process and task mining can reveal actual steps, compare paths, find mistakes and identify where problems occur. A specialized tool is not mandatory for every project. The underlying principle is what matters: use event records, samples and conversations with the people who perform the work to distinguish the common path from the exceptions.
Five criteria for choosing the first workflow
The first criterion is repetition with reasonable stability. The task should happen often enough to justify the effort, but its rules cannot change every week. Google's SRE guidance describes toil as work that tends to be manual, repetitive, automatable and without enduring value. This is a useful signal, but repetition alone is not a business case.
The second criterion is data readiness. Required fields need a known source, an owner and minimum quality. If the team cannot determine which customer, product or request a record belongs to, automation will reproduce the ambiguity faster.
The third criterion is exception density. List the reasons a case leaves the standard path and estimate how often each one occurs. A process with many undocumented variations may need simplification before automation. Exceptions that remain should have a visible queue, a responsible person and a way to resume the original case.
The fourth criterion is reversibility and risk. Prefer an initial flow in which an incorrect action can be detected and corrected without major impact. Financial, legal, privacy-related or irreversible decisions require narrower limits and stronger approval. The fifth criterion is measurable outcome. Define the baseline and the evidence of completion, such as accepted requests, lead time, corrections and pending cases.
A hypothetical example: internal purchase requests
Imagine a service company that receives internal purchase requests by email. This is a hypothetical example, not an NM Solutions customer case. Employees send different descriptions, managers ask for missing cost centers and the purchasing team copies approved information into an internal system.
Instead of automating every variation, the company begins with requests for standard catalog items below a defined approval limit. A structured form checks required fields, validates the cost center and creates the record. Requests outside the catalog, with inconsistent values or involving restricted categories are routed for review with the reason recorded.
The team compares the pilot with its baseline: how many eligible requests were accepted without correction, how long they remained pending, how many exceptions returned to the flow and how much human effort was still required. If a system is unavailable, the request remains traceable and can be resumed. Only after stable results does the company consider adding other categories.
Choose the simplest adequate mechanism
Not every step requires artificial intelligence. A required field can be handled by validation. A system update may need an API integration. A fixed calculation belongs in a rule. AI is more appropriate when the process contains relevant unstructured information or interpretation that deterministic logic cannot handle well.
When AI is included, document its intended purpose, usage limits, human oversight and expected costs. The NIST AI Risk Management Framework recommends defining business value, targeted scope, potential benefits, costs and risk tolerance before deployment. Also compare the AI option with a simpler redesign or conventional automation.
Design the pilot to expose problems
A pilot should include failure scenarios, not only the ideal path. Test missing data, duplicate requests, delayed responses, unavailable systems and changes after submission. Record a unique case identifier, the current state, relevant decisions and the next responsible party. This makes recovery and investigation possible without relying on private messages between employees.
Define in advance what pauses the automation and what returns the task to manual operation. A fallback is not evidence of failure. It is part of a controlled design. Review results with business and technology together so that a technical success is not mistaken for an operational improvement.
Recognize limits before expanding
Historical samples may omit rare situations, employees may work around the official process and legacy systems may not provide reliable events or integrations. Privacy restrictions can limit the data used for analysis. A seasonal change can also alter volume and exception patterns. Document these constraints and revisit the decision when the context changes.
The best first workflow creates learning that can be reused. NM Solutions helps companies map the current process, prioritize bounded opportunities and structure automation with observability, clear ownership and safe expansion. A diagnostic conversation can identify which flow offers the strongest starting point.