Which business process should you automate first?

The loudest task is not always the best first process

Inbox pain gets attention because it is visible. A quieter handoff may be costing more. If every signed proposal waits two days before delivery receives the right information, that delay deserves a look even when the copying itself takes only twenty minutes.

A good first process repeats often enough to learn from, has a recognisable finish and can be bounded without redesigning the entire company. It should matter, but a failure during testing should still be recoverable.

Make a short candidate list from real work

Review the last two weeks and name activities rather than departments. “Sales” is too broad. “Prepare a proposal after a qualified call” can be observed from start to finish.

Useful candidates often sit where information changes hands. Enquiries, proposals, onboarding, recurring reports, invoice preparation and approval follow-up are common because they combine repetition with coordination. Common does not mean automatically suitable. Your recent cases decide that.

Score the conditions that change the decision

Use a simple five-point scale for each candidate. The numbers are there to expose disagreement, not to manufacture a scientific ranking.

• Frequency: how often does a case enter the process?
• Owner dependence: how often does work stop for your memory or context?
• Stability: are the inputs and business rules recognisable across cases?
• Delay or error cost: what happens when the handoff is late or incomplete?
• Recoverability: can a failed first version be spotted and handled safely?

Look closely at exceptions

An activity can look repetitive while each case follows a different commercial rule. If half the work is exception handling, the first engagement may be process clarification rather than a build.

Count exceptions from recent cases. Name who resolved them and what information they needed. Some variation can become a documented route. Other variation is the business judgement clients are paying for. Keep the second kind visible.

Choose a boundary small enough to finish

“Automate onboarding” is still too large. A first boundary might begin when a contract is marked signed and finish when delivery receives a complete start pack with any missing item assigned to someone.

That boundary has a trigger, a receiver and observable completion. It also leaves sales decisions and the delivery work itself outside the build. If the first version works, another boundary can follow.

Use the choice to learn about the business

The first automation is also a test of ownership. Can somebody provide real examples? Can the business settle an unclear rule? Will the people doing the work use one agreed source? These conditions decide more than the connector catalogue.

Pick the candidate that makes the next useful weakness visible. A small successful loop is valuable. A clear decision not to build can be just as valuable when it prevents a vague process becoming expensive software.