Identify automation opportunities from real process work

You do not need a large software implementation to form an initial view. A small, representative case list can show what work actually occurs. Keep observations separate from assumptions. This guide provides a practical method, synthetic calculations and explicit selection criteria.

First define the beginning and end. “Automate email” is too broad. “Match a new service enquiry to the correct customer and hand it over as an actionable task” is specific enough to collect cases and compare results.

Follow ordinary and difficult cases. Four questions show where work is lost in a process:

• Where is information copied?
• Where do people wait for a response?
• Where is a customer identifier missing?
• Where is information requested again even though it has already been provided?

Include informal work, such as a clarification call or a handwritten note transferred later.

Distinguish active handling time from waiting time. A case can take three days while requiring only twelve minutes of actual work. Faster data entry may not affect the main delay. If approval takes two days, better ownership or reminders may matter more than faster summarisation.

A simple table for each automation candidate can capture seven observations and the purpose of each:

Period. Choose a period that reflects ordinary variation. A quiet week may understate a seasonal process; an exceptional incident may exaggerate it. Mark these conditions instead of smoothing them away.

Process mining. Where electronic event data exists, process mining can reveal process paths and variants. Microsoft describes the analysis of existing system events as a basis for improvement. For a small project, assess whether preparation and tool costs are justified. Such analysis also sees only the events actually recorded. Microsoft process mining overview, checked on 26 September 2026.

Data quality. Check data quality before trusting a diagram. If a status is updated only at the end of the week, its timestamp may describe administration rather than when the underlying work happened. Discuss these meanings with the people using the system.

Not every repetitive task needs AI. A required form field, an existing export feature or a clear assignment rule may resolve part of the problem more cheaply and transparently.

A rule-based workflow fits when a decision can be described explicitly: if a customer number is present, find the record; otherwise create a review case. AI may help interpret inconsistent text or propose information extracted from different layouts. The handling of uncertainty still needs to be designed.

A task is a poor initial candidate if its outcome cannot be checked, necessary information is inaccessible or nobody owns its rules. That is not a permanent rejection of automation. It identifies preparation: clean the data, resolve access or describe the decision with the business team.

Current effort. Consider an invented business receiving 300 enquiries each month. The current process takes an average of six active minutes per enquiry: 1,800 minutes, or 30 hours.

Proposed process. The proposed process still needs two minutes of review for every enquiry. Add three hours per month for maintenance and exception handling. New effort is therefore ten plus three hours, or 13 hours. The calculated capacity released is 17 hours per month.

Assumptions to verify. These are not measured results. The calculation identifies assumptions the pilot needs to verify. If review actually takes four minutes and maintenance requires six hours, 26 hours remain. The difference falls to four hours. Both versions could demonstrate the same technically successful workflow while producing very different economic outcomes.

The table compares both versions of this synthetic calculation for 300 monthly enquiries and a current effort of 30 hours:

Capacity, not cash. Released hours are not automatically cash savings in payroll. Explain how the capacity could be used: reducing backlogs, responding sooner or handling additional work. A claimed increase in revenue needs separate evidence and should not simply be added to the calculation.

Uncertainty. Record uncertainty as a range when necessary. A process with an optimistic benefit of seventeen hours and a plausible benefit of four hours deserves a different decision from one with seventeen hours already observed. The next experiment should resolve that uncertainty.

These examples are also synthetic. A team considers enquiry matching, automatic quote approval and monthly reporting.

The table summarises the three synthetic candidates: what speaks for each, what remains open and which first step suits it.

Matching enquiries: Frequent cases, known customer identifiers and a controlled review path support a bounded pilot. Ambiguous matches stay with a person. Success means cases reach the correct owner sooner without changes to the wrong contacts.

Approving quotes: The apparent time saving is substantial, but pricing depends on exceptions and undocumented experience. Preparing a draft with missing information highlighted may be a better first step. Binding approval remains with the responsible team until rules and authority are established.

Producing a monthly report: Frequency is low, but collecting the information takes considerable time. If queries repeat and the result is easy to verify, this may still be worthwhile. An infrequent process is not automatically uneconomic; total effort, error consequences and ongoing changes matter.

Avoid a falsely precise score that trades away a missing prerequisite for high volume. Unresolved lawful access or unclear responsibility should first be treated as an open prerequisite. Compare benefit and effort among candidates that can actually be implemented.

Question. State a verifiable question in advance: “Can this process match approved enquiries correctly while routing uncertainty visibly to people?” Define the information used, the permitted action and the failures that require processing to stop.

Test cases. Choose ordinary and difficult cases. Include missing information, duplicate intake, conflicting values and an unavailable destination. Specify expected outcomes before seeing system output. Otherwise a plausible answer may be accepted as correct after the fact.

Value and consequences. Consider value and potential consequences together. The voluntary NIST AI Risk Management Framework connects context, measurement, responsibility and risk handling. It is not a DACH legal standard or an automatic project approval. NIST AI RMF.

Manual fallback. Arrange a manual fallback for the pilot. The business should know who handles an urgent case if processing pauses. This also reveals whether the supposed saving depends on silently moving unresolved work to someone else.

The result of the analysis can fit on one page with eight entries:

• task
• start and finish
• systems
• observed volume
• current effort
• important exceptions
• permitted changes
• owner

Add unresolved assumptions and the criterion for continuing or ending the pilot.

If the best next step is simply a clearer form, the analysis has still done its job. If a workflow is justified, you now have a useful basis for a comparable proposal. Begin with a specific case and a verifiable outcome; choose the tool from those requirements.

These guides cover the decisions that follow the assessment of an automation opportunity:

• AI automation: tasks, selection and implementation
• AI automation costs: a first-year budget for SMEs
• Introducing AI: software, an internal team or an agency?
• AI workflow approvals: who checks which action?

For a workflow review, start with the task, systems involved and typical exceptions. Discuss it with modernagents.