Automation
What to automate first: a practical workflow audit
A practical method for choosing the first workflow to automate: map real work, screen readiness and risk, run a bounded pilot, and measure the outcome.
The short answer: start with a measurable workflow, not a tool
The best first candidate is rarely the loudest problem or the most impressive technology. It is usually a frequent, sufficiently stable workflow with digital inputs, a verifiable outcome, and a bounded cost of failure. The team should be able to show where it starts, where it ends, and how time, waiting, errors, and manual effort are measured today.
Automation does not need to cover the entire journey. The right first move may be removing duplicate data entry, assigning the next action automatically, or assembling a report from several systems. A pilot should prove a better business outcome, not merely demonstrate that a chosen tool can execute a scenario.
Map the real work from trigger to outcome
Start with recent real cases rather than the ideal procedure. For every step, record the trigger, input, owner, system, decision rule, output, and recipient. Mark waiting, returns, duplicate entry, manual reconciliation, exceptions, and activities that depend on one employee's memory.
This mirrors the logic of process mining: a map reveals actual workflow variants, their frequency, and their throughput time rather than one assumed path. If the team cannot describe the start, finish, and common variants, the next step is a short audit and simplification—not automation development.
Remove and simplify unnecessary work first
Automating a step simply because it exists is risky. Ask whether its output is needed, whether an approval can be removed, whether sources can be consolidated, whether required data can be made explicit, or whether an email thread can become a clear process state. A deleted step is cheaper, faster, and more reliable than any integration.
If three employees perform the same activity differently, define the acceptable primary path and list the exceptions. Not every case must be forced into one sequence, but transition rules, ownership, and mandatory data should be agreed before software begins enforcing them.
Screen the candidate for automation readiness
A strong candidate runs regularly, uses available digital data, and follows rules that can be tested. It has observable states before and after an action, a clear way to verify the result, and an owner responsible for change. The less ambiguous interpretation and unpredictable exception handling it requires, the easier it is to release safely.
Structured inputs and the number of workflow paths genuinely affect automation potential. UiPath, for example, uses the share of digital and structured input and the number of ways to complete an activity in its simulation. High technical potential still does not guarantee high priority: a workflow may be rare, inexpensive, or irrelevant to customers.
Score value, readiness, and risk separately
Value can be scored through frequency, manual handling time, customer delay, error volume, rework, and impact on revenue or service. Readiness covers rule stability, data quality, integration access, outcome observability, and ownership. Do not hide everything inside one attractive score: high value with low readiness means a preparation project, not immediate automation.
Risk should remain a separate gate. Record the maximum harm of an incorrect action, reversibility, data sensitivity, regulatory constraints, and the need for human judgement. Where failure is expensive, automation can prepare information, validate completeness, and recommend the next step while a person retains authority to approve the action.
Workflows that often make good first pilots
Good candidates often include transferring validated data between systems, creating a task after a clear event, routing requests through explicit rules, alerting on an SLA breach, reconciling shared identifiers, and preparing a recurring report. Their common feature is a result that can be verified automatically and an error that can be detected and corrected before major harm occurs.
Choose one complete slice rather than a collection of unrelated improvements. For example: a website enquiry arrives, required fields are checked, a record is created, an owner is assigned, and the next deadline is stored. This creates an observable outcome while leaving complex qualification to a person until enough evidence exists to automate it safely.
What not to automate first
Do not begin with a rare workflow, constantly changing rules, poor input data, or work without an owner. A broad end-to-end process spanning many teams and systems is also a weak first candidate when the company lacks event logs, a test environment, rollback, and an agreed exception path.
Decisions that materially affect a person, money, access, or safety require a separate review. NIST recommends clearly defining the human roles and responsibilities around AI systems. The principle remains useful even without AI: software should not silently replace accountable judgement, and an operator needs enough context to exercise meaningful control.
Design the pilot as a production workflow
Before development, define the trigger, required fields, systems of record, success condition, timeouts, retries, deduplication, exception queue, and manual fallback. Assign both a process owner and a technical operations owner. A demonstration without logs, alerts, and failure recovery does not prove readiness for real work.
Limit the pilot to one team, one input type, or a small share of cases. Use shadow mode first when the action is risky: the system produces an outcome while a person compares it with the current method. Enable execution only where accuracy, speed, and exception handling have been demonstrated on real data.
Measure the outcome before scaling
Capture a baseline before launch: case volume, active handling time, end-to-end throughput time, waiting, error rate, rework, and SLA performance. Microsoft Process Mining distinguishes variant frequency from throughput time, while UiPath models manual processing time and cost. The distinction matters: employee effort and customer waiting are different measures.
After the pilot, compare equivalent periods and equivalent case types. Include support cost, the number of manual exceptions, and recovery time after failure. Scale only when a business metric improves, the team understands the new workflow, and an owner can maintain its rules and data after the project ends.
The audit output is a short plan, not a tool list
A useful audit ends with a current-state map, baseline metrics, a candidate list, and a separate risk register. The first candidate should have pilot boundaries, integrations, exceptions, controls, measures, and owners. Only then should the implementation method be selected: configure an existing system, connect systems, use a workflow platform, or build a custom module.
When the process is stable, data is available, value is measurable, and risk is controlled, a pilot can be designed through a focused discovery and prototype. When one of those conditions is missing, the honest output is a preparation plan. That protects the budget better than automating for automation's sake.