Which business process should you automate first?

Define the result before the technology

Do not describe the objective only as processing invoices, requests or emails automatically. Name the result that the next person needs. For an enquiry, that might be a complete record containing a contact, a product choice and any outstanding information. An automatically created CRM record without these details merely moves the investigation elsewhere. Choose a recognisable starting event and an ending that can be checked objectively.

Also state what the first version excludes. Registering an enquiry differs from judging a quotation, promising a discount and scheduling delivery. Separating those decisions allows one useful handover to improve without changing the entire sales process. The boundary should make sense to the people who will depend on the output, including colleagues who were not involved in choosing the automation.

Measure the work that actually happens

Follow a series of recent cases and record active handling, waiting and correction time separately. An enquiry may remain open for two working days while requiring only six minutes of attention. Reducing waiting may have commercial value even when the labour saving is small. Conversely, a short overall turnaround can conceal repeated copying between screens. One average cannot represent all these effects.

Distinguish normal periods from peaks. Record incomplete cases, returned work and decisions requiring professional judgement. Do not adopt an assumed number of minutes per task simply because a platform displays that default. Ask the process owner to check whether the measurement matches experience and list information still missing. An approximate but defensible baseline is more useful than a precise result calculated from unverified assumptions.

Compare different kinds of opportunity

One opportunity is handover: staff re-enter information in a different system. Another is checking: people repeatedly inspect the same conditions. A third is follow-up: work remains untouched because nobody receives a signal. These need different designs. Handover needs stable identity and field ownership; checking needs explicit rules; follow-up needs a responsible person, a deadline and a meaningful status.

A fictional wholesaler has all three. Sales staff copy enquiries, finance checks customer numbers and planning waits for approval. Faster copying does little if customer numbers are routinely absent. The first version could collect more complete enquiries and present one review list. Improving a small part of the process before automating it can make the subsequent implementation both cheaper and more dependable.

Turn the selected process into a bounded trial with a measured baseline: Designing an automation pilot: evidence for the next decision.

Investigate exceptions before building

Ask staff for examples outside the normal route: an existing customer using another email address, a cancellation after processing, two requests for the same job or an unreadable attachment. For each exception, describe frequency, decision ownership and whether ordinary processing may continue. Unknown cases need a visible investigation route rather than an improvised guess by the workflow.

Not every exception needs an automated answer immediately. A manual queue can be appropriate when its owner, evidence and next action are clear. However, prevent that queue from quietly becoming most of the process. Measure how many cases enter it and how much checking they require. Exception handling belongs in the initial business case, not in an unexpected maintenance request after the attractive demonstration has been accepted.

Make a comparable assessment sheet

Evaluate candidates using the same questions: does the work recur, are inputs and outputs identifiable, can the rules be explained, and are the relevant systems accessible? Add the impact of mistakes, the ability to recover and the availability of maintenance. High volume does not make a process a good first choice when an incorrect change is difficult to reverse.

Use scores to support discussion rather than automatically select a winner. A large projected benefit should not cancel out missing permission or an unmanageable failure mode. Record evidence for each judgement: a measured weekly volume, an API test or a named reviewer. Unproven assumptions become investigation tasks. This shows whether the next assignment should be a small technical experiment, a process agreement or a complete implementation project.

Calculate a fictional enquiry route

Suppose a team processes 300 enquiries per month and spends four minutes registering and checking each one. That equals twenty hours of active work. A proposed workflow reduces ordinary handling to one minute, but fifteen percent of enquiries need five additional minutes of investigation. Remaining work is then five hours of ordinary handling plus 3.75 hours investigating exceptions.

The theoretical capacity released is 11.25 hours monthly before maintenance and additional quality checks. This is not automatically a cash saving: salaries do not fall merely because attention becomes available. Discuss a practical use for that capacity, such as reducing a backlog or responding sooner. Compare it with implementation cost, timing and uncertainty. You are then assessing a concrete change rather than presenting an attractive number without a credible operating plan.

Decide whether fixed rules are sufficient

A status notification, a field check or controlled synchronisation often does not require AI. If identical input should produce identical output under agreed rules, start with explainable logic. AI may help with variable text or classification, but adds another question: is the proposed interpretation supported well enough? Introduce that step only when it improves the actual work.

In the fictional enquiry route, a form can reliably identify missing required fields. A language model might help summarise a long explanation, but its summary should not replace the original request. Test difficult cases, contradictions and missing information. Decide which outputs are directly useful and which require review. This keeps the technology choice connected to the task instead of making AI a requirement before the process is understood.

Design a first experiment that enables a decision

Choose one team, one source and one clearly defined outcome. Agree which representative cases to use and who will assess errors. Where practical, begin with observation or draft output before allowing external changes. The experiment should demonstrate more than a successful normal route: it should expose missing input, duplicate events and an unavailable destination.

Set stopping conditions in advance. If checking consumes more time than the workflow releases, a required source is unavailable or the exception queue lacks staff, adjust the scope. A useful experiment enables a choice: build further, use a simpler solution or stop for now. That is more informative than a presentation consisting entirely of hand-picked examples that were known to work before the demonstration started.

n8n: Handle errors gracefully ↗

Include ownership in the selection

A candidate becomes practical only when someone can change its rules and someone can check its daily results. Record who receives an alert, who manages access and who covers absence. Discuss what happens when the automation is temporarily disabled. A familiar manual route protects continuity during maintenance but must avoid processing the same work twice when normal service resumes.

Before requesting a proposal, prepare a description of the trigger, output, volumes, exceptions, connected systems and measurement method. Add recent anonymised examples and name remaining uncertainties. A developer can then identify which assumptions require proof first. The best starting automation is usually a small improvement that completes a real handover, creates measurable value and remains understandable when events depart from the expected route.

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• n8n consulting ↗
• Business process automation ↗

Questions about this topic

Continue with a related question