Which business process should you automate first?

Your team copies requests from email into a CRM. They reconcile spreadsheets every Friday. They chase customers using a shared tracker. There is no shortage of automation ideas; the difficult part is deciding which one to tackle first.

The best first candidate is a frequent, well-understood task with reasonably stable rules and mistakes you can recover from. It is not necessarily the task that takes the longest, or the one that looks most impressive in a demonstration.

Here is how to turn a list of frustrations into a first project whose usefulness you can actually measure.

Describe a specific workflow, not an entire department

“Automate administration” is not a workable scope. “Create a CRM record when a complete sales enquiry form is received” is.

For each idea, describe five things:

1. The trigger: a submitted form, a status change or an uploaded file.
2. The inputs: the information required and where it can be found.
3. The processing rule: what determines the next step.
4. The expected output: a record created, a document prepared or a person notified.
5. The owner: the person who intervenes when the process cannot complete.

Writing this down often reveals how much of the work relies on informal knowledge. If only one person knows how to distinguish ordinary requests from exceptions, start by making their criteria explicit. A tool will not make an unwritten rule clearer.

Observe the real work, including the exceptions

Talk to the people doing the task, then follow several cases from start to finish. A written procedure may leave out essential steps: finding an attachment, correcting an identifier, checking for duplicates or asking for approval.

Record the volume, the time actually spent and any rework. Separate working time from waiting time. A case might require eight minutes of work but spend three days sitting in an inbox. In that situation, an alert or better assignment of incoming requests may be more valuable than automating data entry.

Build a small collection of difficult cases too: missing information, unusual formats, existing customers and cancelled requests. Your sample needs to cover the variations in the process, not just its easiest cases. If the activity is seasonal, a quiet week is not enough to represent how it operates.

Compare candidates against four criteria

An identifiable benefit

What exactly do you want to achieve: time returned to the team, fewer errors, shorter turnaround times or better traceability? Choose one primary outcome. An automation can be worthwhile even if it saves few minutes, for example when it prevents missed follow-ups that are otherwise difficult to detect.

Rules that are stable enough

A rule that changes with every case will be expensive to implement and maintain. A sequence of explicit conditions, by contrast, is well suited to conventional automation.

If the work involves understanding free-form text, comparing different ways of expressing something or summarising documents, an AI component may help. It does not replace process definition: separate the steps that require interpretation from those that can follow an explicit rule.

Accessible data

Check access before designing the workflow. An available API, suitable permissions and reliable identifiers make the project easier. An interface that must be operated like a human user, incomplete exports or files without a common structure will make it more fragile.

That does not rule out automation. But the cost of retrieving and cleaning the data needs to be part of the decision, rather than a surprise after the project begins.

Manageable risk

Creating an internal draft and initiating a payment have very different consequences. For a first project, favour operations that can be checked before approval, reversed or repeated without creating duplicates.

The useful question is straightforward: if the system makes a mistake on a case, who will notice, how soon, and how will they correct it?

Calculate a net benefit, not just minutes saved

An initial calculation can fit into a few lines. Consider this fictional example, intended to illustrate the method rather than suggest a typical return.

A team handles 300 cases per month, spending eight minutes on each one. That adds up to 40 hours of work a month.

The assumptions after automation are:

• 240 standard cases still require two minutes of checking each, totalling eight hours;
• 60 exceptional cases remain manual, adding another eight hours;
• monitoring the automation takes four hours per month.

Total working time would therefore fall to 20 hours, freeing up another 20 hours. At an internal valuation of €40 per hour, that represents €800 a month. Subtracting €200 in subscriptions and €100 in external maintenance leaves a theoretical net benefit of €500 per month.

An initial investment of €4,500 would then have a theoretical payback period of nine months once that operating pattern is reached. Training, the ramp-up period or new exceptions could extend it.

Time freed up is not automatically a cash saving. You need to know how that capacity will be used: handling more cases, clearing a backlog or improving service. Otherwise, the benefit remains an accounting assumption.

Start with partial automation

You do not need to cover the entire journey in the first release. For a sales enquiry, an initial version could:

1. check that the essential fields are complete;
2. look for an existing contact;
3. prepare the record and its assignment;
4. request approval before creating the final record;
5. send ambiguous cases to a manual processing queue.

This scope lets you observe errors without immediately handing every decision to the system. Use a case identifier to prevent multiple records being created when the same event arrives twice, and keep a readable history of the actions taken.

The process owner must be able to pause the workflow. An automation that quietly keeps running after a form changes can cost more time than it saves.

Decide after a measured pilot

Compare a baseline period with a test period that has a similar case volume and level of difficulty. Track at least:

• the time actually spent on each completed case;
• the proportion of cases sent back for manual handling;
• errors and the time needed to correct them;
• the time between receiving a request and resolving it;
• the operating cost of the automation.

Set the conditions for continuing before launching the pilot. If checking the output takes as long as the old data-entry task, the problem has not been solved. You need to reconsider the scope, data quality or approval process.

A successful first project also needs to be transferable: a named owner, a description of how it works, documented access and a procedure for failures. Choosing between an off-the-shelf tool and a small custom component comes next. Compare how they handle your real cases, the integration costs and the maintenance required.

Have several candidate tasks but cannot decide where to begin? Tell us about one specific process, with a few example cases and the tools involved. That is the best starting point for assessing what is worth automating.