Which business process should an SME automate first?

To choose the first process to automate, compare three things: the time people actually spend on it, the observable cost of mistakes and how easily you can check the result. Prefer a frequent workflow with stable rules, a named owner and a way to reverse changes. The most visible process is not necessarily the best candidate.

An SME may have a long list of frustrations: copying enquiries, matching contacts, preparing quotes or filing documents. Connecting everything at once quickly creates a project that is difficult to assess. A first automation should answer a narrower question: which problem can we reduce without simply moving the workload elsewhere?

Observe a real working week

Choose three recurring tasks and observe several examples of each. For every occurrence, record the trigger, the tools involved, active working time, checks and rework. A task described as taking “five minutes” may involve three people and spend two days waiting between their contributions.

Separate processing time from total elapsed time. Removing a few minutes of data entry will not necessarily fix an approval stuck in an inbox. Record exceptions as well: a missing attachment, an unknown contact or an inconsistent amount. These often determine how difficult the project will be.

Cost mistakes without inventing a return on investment

The current cost has two parts. The first is time spent on normal processing. The second includes corrections, duplicates, extra messages and delays directly attributable to the process. Use your observations rather than an attractive sales estimate.

Avoid double counting. If correction time is already included in your measurement, do not add it again. Also distinguish avoidable expenditure from released capacity: saving hours does not automatically reduce payroll. Those hours may instead help the team respond faster or handle more enquiries.

A lost opportunity may matter, but its value does not become a guaranteed saving. Keep documented impacts, plausible risks and benefits to be tested during the pilot separate from one another.

Rule out candidates that are difficult to control

Before ranking tasks, apply a few basic screening criteria. Is the necessary data accessible? Are the rules written down? Can you recognise a successful outcome? Who will handle a failure? An automation should not start by guessing what the team has never agreed.

Activities involving negotiation, sensitive judgement or numerous exceptions are rarely the simplest starting point. You can still automate their preparation: gather documents, check that they are present and create a task for the right person. The decision then remains with a human.

An assessment of use cases and priorities helps separate rules that can be automated from decisions that need to stay explicit.

Fictional example: comparing two projects

Imagine an SME that regularly copies incoming enquiries into its CRM. The task repeats throughout the day and sometimes requires corrections: incomplete contact details, incorrect assignment or missing information. The team wants to reduce this rework but still needs to measure its actual significance.

The other project involves preparing a less frequent report. Its data is clean and its rules are simple. Repeated data entry seems more frustrating in daily work; the reporting process may be easier to make reliable. This comparison is entirely fictional and does not describe customer results. It shows why frequency and simplicity should be considered together.

To choose between them, the team also estimates implementation, operating and supervision costs. It then tests the scope it can control most effectively rather than treating every hour currently spent as a promised saving.

Design the pilot and its stopping conditions

Define an observable beginning and end: an enquiry arrives, a record is created or updated, and an owner is informed. Limit the pilot to one source and one team. Prepare ordinary cases, missing-data cases and a temporarily unavailable service.

In n8n, an error workflow can be attached to the main workflow to respond when an execution fails. That capability does not replace an operational procedure: someone must own the alert, and the team must decide how the case will be recovered.

Measure supervision time, the proportion of correctly processed cases and manual interventions. Set a stopping threshold if checks reveal an unacceptable risk or more work than expected. A clearly scoped automation should remain understandable to the team using it.

Prepare a decision the team can act on

Before starting, collect an anonymised real example, the usual volume, the current steps and the mistakes encountered. That is enough to begin a practical discussion about scope, controls and budget.

Unsure which task to start with? Contact Smart Wise Monkey to examine the options and choose a measurable first project, without assuming the benefits before testing them.