What to automate first: choose a workflow without expensive assumptions

1. Collect candidates from actual work

Ask the team to record repeated copying, status searches, file consolidation, reminders and reconciliations during an agreed period. Each entry needs a trigger, outcome, frequency and participant. “Lots of routine work” is not a candidate; manually matching payments to orders every day is an investigation starting point.

Distinguish repetitive work from difficult one-off decisions. An unusual commercial agreement may take substantial time but needs a different automation assessment from a stable directory transfer. Do not rank everything by minutes alone.

Gather examples from operators and recipients. A team can perform its own step quickly while handing over incomplete information that another department must reconstruct. Include those handovers in the scope. Otherwise you may optimize one station without improving the workflow that matters to the customer.

2. Check whether the activity is needed

Before speeding up a report, ask which decision it supports. If nobody reads it, automation preserves unnecessary work. But do not remove a control because its purpose is initially unclear: it may prevent an important error or satisfy an agreed requirement. Find its owner and reason.

Compare three responses: remove unnecessary work with approval, simplify the rule or automate necessary work. Duplicate status entry may disappear after designating one source, without building an integration. If an independent check is required, preserve its purpose while considering another method.

Describe the outcome from the user’s perspective. Instead of adding a bot, require visibility of untransferred orders without manually comparing lists. This supports comparison between solutions and avoids committing to a tool before the need is understood. A simpler process is a valid outcome even when no software is built.

3. Estimate effort without inflating benefits

Choose a comparable period and measure volume, active effort and rework. Ten minutes of action and an hour awaiting approval are different quantities. Automating entry may reduce the first without changing the second. Label recollections separately from direct observations.

Teaching calculation: sixty operations a week at four minutes each require 240 active minutes. If the new method retains one minute of checking per operation plus thirty weekly support minutes, it requires ninety minutes. The difference is 150 minutes, not the full original 240. These invented assumptions are not a customer forecast.

Released capacity is not automatically a cash saving. Understand whether the team can use the time elsewhere, whether throughput changes and whether paid effort actually disappears. Use agreed rates and assumptions for financial estimates. Avoid counting waiting time as recoverable labour merely because it appears in an elapsed-time measure.

4. Separate frequency from severity

Group recurring issues by frequency or time spent. ASQ describes Pareto charts as a way to show categories’ relative importance. Do not assume your dataset must follow an 80/20 split. Use observations rather than a universal-looking proportion.

A rare failure can matter more than a frequent inconvenience. Separately assess data loss, unauthorized financial action or interruption of operations. Such situations may first need containment and controls rather than fully automated execution.

Do not collapse different risks into a precise total without explaining the scale. Transparent categories and evidence are more useful: recurrence observed, consequence confirmed, recovery available or still unknown. They expose uncertainty instead of hiding it behind a score. Make clear who can accept the remaining risk and what must be resolved before a pilot starts.

5. Test rule and data readiness

Ask two operators to explain the same scenario. If they choose different outcomes under identical conditions, agree a rule first. Automation cannot resolve an undisclosed disagreement between departments; it merely makes one interpretation repeatable. Exceptions also need an owner and a condition for resuming.

Check required data, stable keys, status meanings and API capabilities. An export does not establish that relationships or history are included. If a critical prerequisite is unknown, a small technical investigation may be the first task.

Readiness does not require perfect data throughout the company. It requires sufficient control of the selected flow. Define accepted inputs, clarification cases and blocking conditions. Do not automatically guess ambiguous values simply to eliminate visible errors. A safe refusal may be the correct outcome until an owner resolves the uncertainty.

6. Compare candidates using the same questions

Create a short card for each task: problem, user, observed effort, sources, risk, dependencies and verification. Use the same comparison horizon. A small daily activity and a quarterly reconciliation need a common time basis when effort is compared.

Include implementation and ongoing maintenance separately. An unstable external format may be easy to automate initially but require continual repairs. Ready-made connectors also need testing; a service name in a catalogue does not establish every required operation.

The largest theoretical benefit need not win the first pilot. Controllability, a safe stopping point and reliable learning matter too. The worksheet below is an illustrative comparison, not a universal ranking. Replace its assumptions with your evidence and document why a candidate was selected or deferred so the decision remains explainable later.

7. Frame the pilot as a hypothesis test

Connect a change to an outcome: importing two stable sources should reduce consolidation effort without reducing report completeness. Bound the test to one report, period and user group. An unrestricted company-wide launch is not a pilot.

Agree acceptance and stopping conditions before starting. Include normal work, a missing source, a repeated record and recovery. When the output informs important decisions, show missing or stale data explicitly, not only the last execution time.

Compare with a verified baseline without silently changing it during the test. Preserve explanations for discrepancies. At the end, specify the conditions under which the result worked and the limitations remaining. A successful demonstration on perfect inputs is insufficient evidence for expanding to a flow with known exceptions and changing source formats.

8. Avoid moving manual work to another team

Measure the complete selected flow. If a salesperson stops copying data but an administrator repairs exchange daily, the apparent benefit may be inflated. Support and exception effort belong in the assessment rather than becoming a post-project surprise.

Ask the recipient to verify usefulness. A fast report may lose comments required for decisions. An automated task may exist but remain invisible to its operator. Test with their permissions and ordinary working environment, not only an administrator account.

Do not disable a necessary manual check to demonstrate savings. Establish what replaces its function and how that mechanism was tested. Transitional support can be justified when its scope, owners and exit condition are agreed. Make that effort visible so a temporary workaround does not quietly become permanent operating overhead.

9. Decide and update the backlog

After the pilot, choose expansion, revision or rejection and document the evidence. Expansion into another channel, larger volume or new exceptions can require another check. Success under one set of conditions does not establish universal readiness.

Preserve learning when a pilot disappoints. If approval rather than entry is the main delay, a workflow change may be needed. Effort already invested does not obligate continued implementation. Equally, one failed task does not invalidate all automation.

Return to the candidate list with updated assumptions about maintenance, readiness and effect. This creates a sequence of improvements grounded in evidence rather than a demand to automate every department immediately.

• Observed effort and a clear recipient exist.
• Rules, data and critical dependencies are checked.
• Support and exceptions are included in operating effort.
• The pilot has an owner, criteria and a safe stop.
• The decision reflects the full flow rather than one local saving.