Business process automation: where to start and what to expect

Automation has a reputation problem, and it is mostly deserved. Projects stall because they start from the tool rather than the process: a platform is chosen, licences are bought, and only then does anyone ask which steps actually consume the time. The businesses that get real value from automation do something far less exciting first — they write down how the work happens today.

Automation is about order, not technology

A process that is inconsistent, undocumented, and dependent on one person's judgement cannot be automated — it can only be accelerated, mistakes included. Automation is the reward for clarity, not a substitute for it. This is why the first deliverable of a serious automation project is usually a process map, not a workflow diagram in a marketing tool.

Finding the process worth automating first

Score candidate processes against five questions. The best candidate is not the most annoying one — it is the one where automation is genuinely possible and visibly valuable.

• Frequency — does this happen daily or weekly? High frequency pays back faster.
• Rules — can you write the decision rule on one page? If it needs judgement, start elsewhere.
• Volume of handoffs — how many people touch it, and how many times is data re-entered?
• Cost of error — does a mistake cost money, trust, or compliance? These are the strongest cases.
• Stability — is the process changing every month? Automate the stable parts only.

Write the process as it actually happens

Not the idealised version in the procedure document — the real one, including the exceptions, the WhatsApp confirmation, and the spreadsheet someone keeps on the side. Those workarounds are requirements in disguise: they tell you exactly what a system has to handle, and skipping them is how automation produces a tool people quietly stop using.

Automate one step, not the whole chain

Large automation programmes tend to produce large disappointments. Pick one handoff — where data moves between systems or between departments — automate it properly, and measure the result. A single well-chosen integration that removes two hours per day is more valuable, and far easier to defend, than a grand redesign that runs late and changes everything at once.

What automation genuinely delivers

• Fewer errors — rules applied consistently, every time, without fatigue.
• Faster cycle times — steps that took a day happen in minutes.
• Visibility — you can see status, volume, and exceptions instead of asking around.
• Capacity — existing staff absorb more work without more coordination.
• Auditability — a record of what happened, which matters for finance and compliance.

Where automation projects fail

• Automating a process nobody has agreed on, so the system encodes three departments' competing versions.
• Ignoring the exceptions, which are often the majority of the workload in practice.
• Choosing a platform before defining the process, then bending the business to fit the tool.
• No owner after launch, so the automation decays the first time the business changes.
• Measuring activity rather than outcome — counting runs instead of hours saved or errors avoided.

Automation does not fix a broken process. It makes it faster, more visible, and considerably harder to ignore.

A realistic first project

Choose a repetitive, rule-based task with a clear trigger and a measurable end state — for example, taking a form submission, validating it, creating a record, notifying the right person, and updating a report. Build that, keep it under control, and let the result make the case for the next one. Two months later you have evidence, a working pattern, and a team that trusts the approach.