Identifying processes suitable for automation

Many automation ideas begin with a reasonable wish: less copying, fewer clarification requests and shorter waiting times. That wish does not yet define a suitable process. If nobody knows when the task begins, what information is missing or who decides in unusual cases, implementation will inherit the same uncertainty.

This guide provides a selection method for small and medium-sized organisations. A fictional technical service company preparing maintenance enquiries supplies the running example. All cases, tables and rules are editorial examples rather than invented savings evidence or a recommendation for a paid product.

1. Define the problem before choosing a tool

“We want an AI agent” describes a possible solution. The real task may be: “Our team has to ask for the location and equipment type before it can identify the responsible department.” That formulation also reveals simpler options, such as a better form or clearer enquiry instructions.

The GOV.UK discovery guidance places understanding the problem before building a solution. The principle is useful for business selection. Its specific UK public-service procedures are not binding project rules for German companies.

First record who is trying to complete the task, what prevents them and how improvement could be observed. “Process the enquiry faster” is broad. “The responsible team receives the location and equipment type without another clarification request” provides something concrete to test.

A good problem statement identifies what must remain intact. In our example, qualified staff should still assess unfamiliar equipment. Preparation can be supported without automatically transferring that professional decision to an untested system.

2. Describe a beginning, steps and outcome

A process needs a boundary. For the service company, the task starts with an incoming enquiry and ends with a complete internal handover. Appointment booking and maintenance work are initially outside that boundary. This makes the first experiment easier to understand and evaluate.

Record what actually happens, including clarification and waiting. A polished description of the intended workflow has limited value if daily work consistently differs. Involve the people doing the task. They often know exceptions absent from formal procedures.

A common notation can help with more extensive relationships. The Object Management Group's BPMN specification provides a standardised modelling approach. An initial investigation may only need a clear table, provided triggers, responsibility and decisions remain unambiguous.

Enquiry received
  → Check required information
  → Associate details with the existing request
  → Flag unclear or contradictory cases
  → Suggest the responsible team
  → Review the internal handover
  → Approve the handover or process manually

This sequence is a simplified editorial model rather than a complete BPMN diagram or a description of an application already running. It makes the boundary between automated preparation and professional decision-making visible.

3. Assess repetition and stability separately

A task can occur frequently while requiring different judgements each time. Repetition makes it interesting, but does not make it technically manageable by itself. Assess whether inputs and rules are sufficiently stable as well.

The company may receive many maintenance enquiries needing the same core details. Mapping an approved postal area to an internal team can be described clearly when the source data is maintained. Assessing an unclear fault description may require substantially more professional context.

Stability does not mean nothing ever changes. Changes need an understandable process. Who maintains the area table? When does a new responsibility take effect? What happens to enquiries already being processed? These questions belong in selection rather than waiting until an incident occurs.

Rare but consequential exceptions need attention. Limited automation may be appropriate if those cases can be identified and handed over reliably. If they can silently enter the normal route, the proposed solution may need a narrower scope.

4. Investigate the actual quality of inputs

Automation processes the data available to it. Missing information does not become a complete record by passing through software. An enquiry without a location should be recognised as incomplete. A plausible guess based on the sender's email domain is not reliable replacement information.

Review formats, required fields and identifiers. Are customers or equipment identified by a stable ID? Can different spellings be reconciled? Are dates and units unambiguous? Small improvements to input quality can sometimes improve the overall workflow more than additional technical complexity.

Input assessment should reflect genuine variation. Use suitable synthetic examples or data explicitly approved for technical development. Do not transfer confidential information into additional services without checking the purpose and permissions first.

5. Allocate rules, AI assistance and human judgement

A fixed rule can often be implemented directly. If an approved area table provides a unique responsible team, that lookup does not need generated prose. AI may help structure enquiries written in different ways, provided its output can be meaningfully checked.

The task determines the approach. The presence of free text does not automatically mean every processing step needs a large language model. Forms, word lists or existing interfaces may also work. Conversely, a collection of rigid rules can become difficult to maintain when the wording varies widely.

This division avoids making one component responsible for every kind of work. A drafting system can support a reliable overall process when transitions between its components are defined. Record which output becomes which input and what must be checked at that boundary.

6. Assess error consequences before benefits

An incorrectly categorised internal draft has different consequences from an inaccurate binding promise to a customer. Selection should reflect that difference. For each step, identify who notices an error and whether its consequences can still be corrected in time.

A suggested team can be visibly confirmed before internal handover. Automatically sending a binding maintenance appointment adds requirements: actual availability, responsible staff and correct customer information must all match. That is a larger task than preparing an enquiry.

Document the recovery route. Can a wrongly processed case be returned? Is it uniquely identifiable? If processing stops, does it remain in an understandable queue? Without these properties, a faster normal route may be harder to control when something goes wrong.

A suitable initial candidate has a limited, observable effect. It can prepare the next step before performing a consequential action itself. This is a practical selection choice rather than a universal prohibition on automatic execution.

7. Treat exceptions as part of the task

Exceptions are part of the real work rather than mere interruptions to an ideal process. An enquiry may concern several machines, contain contradictory locations or be addressed to the wrong organisation. Include those cases explicitly in the selection discussion.

Define a signal and response for each recognisable exception. A missing location might produce a clarification draft. Several incompatible identifiers may require internal investigation. The appropriate response depends on whether the information should come from the customer or existing internal records.

The process also needs a state for situations it cannot classify. If no appropriate route is found, the record should not silently continue as an ordinary case. An explicit manual-review state can provide a more useful handover.

Organisational handling matters too. Who reads the exception queue? How are duplicate enquiries identified? What happens during absence? A technical flag does not resolve the task unless someone is responsible for acting on it.

8. Compare candidates with transparent criteria

The following matrix is an editorial decision aid, not a certified maturity framework or statistically validated scale. Record actual observations for each criterion. A neat aggregate score should not conceal a critical gap.

Compare a few specific candidates initially. Enquiry preparation, internal file renaming and producing a binding quotation differ considerably. Describing all three as having “high automation potential” does not provide enough detail for implementation decisions.

Keep assumptions visible. If a candidate depends on an interface that is currently inaccessible, that interface is a prerequisite rather than an already solved issue. The next useful action is to investigate it. Record what would happen if the assumption proves false.

9. Express a readiness gate as a checkable rule

Some selection criteria can become explicit checks. The following Python example does not calculate commercial value. It only checks whether the organisational prerequisites chosen for a small pilot have been confirmed. These are freely chosen rules for the fictional example.

def pilot_gate(candidate):
    required = (
        "process_owner_confirmed",
        "input_source_approved",
        "success_condition_defined",
        "exception_path_defined",
        "test_data_approved",
    )
    missing = [key for key in required if candidate.get(key) is not True]
    return {"ready_for_pilot": not missing, "missing": missing}

candidate = {
    "process_owner_confirmed": True,
    "input_source_approved": True,
    "success_condition_defined": True,
    "exception_path_defined": False,
    "test_data_approved": True,
}
print(pilot_gate(candidate))
# The pilot remains blocked because its exception route is undefined.

This rule does not replace professional assessment. It makes one important principle explicit: an unfulfilled prerequisite should not be cancelled out by an attractive hypothetical benefit. A real application should associate confirmations with responsible people and appropriate evidence.

“Approved” also needs a scope. Approval of test data does not authorise public publication. Permission to run a pilot does not automatically grant unrestricted write access to production systems. Identify the precise action and boundary each approval covers.

A readiness record should be revisited if those conditions change. If a new source is introduced, its previous approval status cannot simply be inherited from a different source. Clear identifiers make that distinction easier to maintain.

10. Define success before the pilot

A pilot needs an observable objective. For enquiry preparation, the question could be whether a complete and correct handover reaches the intended team. The number of records processed automatically does not by itself describe that quality.

The GOV.UK performance-metrics guidance relates measurement to the purpose of a service. For our example, metrics should answer business questions: are clarification requests reduced and are new errors or additional review tasks being introduced?

Observe the existing process as a baseline. Relevant information may include handling time, clarification, waiting and recurring errors where collection is appropriate and permitted. Compare similar cases. A quiet week should not be compared with an exceptional workload without context.

Include additional checking effort. An automatically prepared record that needs complete reworking may make one technical step look fast while extending the overall task. Evaluate the outcome of the bounded process rather than only the running time of a component.

Separate observations from explanations. A reduction in clarification may coincide with a better form introduced during the same pilot. The result can still be valuable, but attribution should reflect the changes actually made. Avoid presenting an unsupported percentage as an inherent property of AI.

11. Begin with a bounded experiment

The first experiment should address a manageable section. The service company could structure approved synthetic enquiries and produce internal handover drafts. This does not authorise contacting actual customers or making binding appointment commitments.

Include normal requests, missing fields and contradictory records. Check whether each case takes its expected route. One successful ordinary example does not establish that exception handling works. Document problems as specific cases and repeat them after relevant changes.

The result may support implementation, a narrower scope or a simpler solution. If improving a form resolves the original problem, that is a useful project outcome. Success lies in improving the task rather than maximising the number of automated steps.

Before operation, agree ownership, monitoring and recovery. Who notices failed cases? Who updates rules? Who decides whether the scope can expand? Those questions should be answered by the pilot's conclusion rather than after the first unhandled incident.

12. Produce a concise decision record

The selection process can often conclude with a short decision record. Describe the problem, boundary, expected benefit and main prerequisites. Add unresolved questions and the next limited investigation. Management can then decide without first reading a complete technical architecture.

For the fictional company, the record might say: “Pilot enquiry preparation. Structure location and equipment type from approved examples. Send ambiguous cases to internal review. No automatic appointment confirmation.” That is more actionable than a general instruction to introduce AI.

Distinguish established facts from expectations. “The area table is accessible” may be a verified finding. “We expect fewer clarification requests” is initially a hypothesis. Observed results can support a more grounded assessment later.

Update the decision when the conditions change. A new source or external action may alter the originally approved scope. This keeps the decision understandable and prevents the implementation from silently extending beyond tested boundaries.

An initial effort estimate should include preparation, implementation, checking, ongoing maintenance and exception handling. Potential benefits include avoided work or better completed tasks. Counting only minutes saved in the ordinary case can hide operational effort. Label early numbers as assumptions and replace them with observations after the experiment. The result becomes a traceable decision rather than an apparently precise promise.

A process-selection checklist

• The problem is described independently of a tool.
• Trigger, inputs and intended outcome have boundaries.
• The actual process and its exceptions are understood.
• Authoritative sources are available and suitable for use.
• Rules are distinguished from professional judgement.
• Error consequences and recovery have been examined.
• A responsible person handles unresolved cases.
• Success criteria and an appropriate baseline exist.
• The pilot uses approved data and limited permissions.
• Operation, rule maintenance and expansion have an owner.

Common questions about selecting automation

Does a process have to occur frequently?

Frequency can increase the value. Infrequent work can also be interesting when it is well-defined and demanding. Suitability additionally depends on data, rules and consequences.

When is AI needed?

AI can assist with variable language and drafting. Fixed rules and explicit lookups can often be implemented more directly. Evaluate the choice against the actual task.

Is manual approval always necessary?

It depends on the task and consequences. A tested internal format conversion needs different controls from a binding customer decision.

Sources and related reading

Sources checked on 9 November 2026: the linked GOV.UK guidance on discovery and measurement, plus OMG's BPMN publication. The selection method, technical service company and Python rule are original editorial examples rather than a universal certification standard.

For practical context, read AI for content and website maintenance in SMEs. The wider digital-service context is covered in What a professional business website needs to achieve.