Which business processes should you automate first?

How do you turn the scores into a decision?

Add the first four factors for a total out of 20. Apply the gate before you read the total at all: if you cannot write the rules on one page, the process comes off the list whatever it scored. Then read what is left like this:

• 15 or more, through the gate: a strong first candidate. Build it.
• 9 to 14: shortlist it and come back once the first project is live. Some become obvious after the first automation has connected a system or two.
• Under 9: leave it alone. Hours spent here are hours not spent at the top of the list.

Then do one piece of arithmetic: how often it runs, multiplied by how long it takes. Forty runs a week at six minutes each is four hours a week, about fifteen hours a month. Be sober about that number. Fifteen hours is real, but it is not a salary, and it only becomes money if those hours go into selling, servicing or work you would otherwise pay someone to do. If you are weighing automation against putting another person in the seat, we looked at that in automation versus hiring another person, and the build side of the sum in what automation actually costs in South Africa.

Which processes usually score highest for SA SMEs?

Different businesses, same six answers, most of the time:

• Lead capture and routing. High frequency, clear rules, and a real cost when it slips: an enquiry left until Monday is often gone. Routing every web, email and WhatsApp enquiry to the right person with an instant acknowledgement is a clean first project.
• Quote generation and follow-up. Building the quote may need judgement; chasing it does not. The follow-up sequence — day two, day seven, day fourteen — is pure rules, and it is the first thing dropped when the week gets busy.
• Invoice chasing. Debtor reminders are rule-based, repetitive, awkward for staff, and tied directly to cash. Automate the polite early ones and your people are left only with the accounts that need a conversation.
• Report compilation. If someone spends two days every month pulling numbers from three systems into a spreadsheet, that is high frequency, high time per run and fully rule-based. The judgement is in reading the report, not assembling it.
• Staff or client onboarding. Same documents, same accounts, same checklist every time, and a missed step usually only surfaces weeks later. Strong scores on error cost and people touched.
• Data re-entry between systems. Wherever someone retypes customer details into a second system, there is no judgement in the process at all. The fix is usually connecting the two systems so the data is captured once rather than automating the typing.

Notice what these share: high-volume, rule-based admin sitting between people and systems. That is the bread and butter of the kind of process automation we build, and why the same handful of candidates keeps coming up.

What should you not automate first?

This half of the framework saves more money than the other half. Five things belong at the bottom of the list, however appealing they look in a demo:

• Anything where the rules are unclear. If two experienced staff would handle the same case differently and both would be right, that is judgement wearing a process costume. Automating it means picking one of their answers and applying it to everyone.
• Low-frequency work. The annual budget pack, the once-a-year compliance submission, the quarterly board file. Even when each takes days, the build cost never spreads over enough runs to be worth it early.
• High-judgement decisions. Pricing negotiations, credit decisions, hiring, performance conversations. Software can prepare the information a person needs to decide, which is often a good project, but not your first one.
• Processes that are broken. Automating a broken process gives you a broken process that runs faster, more consistently and with fewer humans positioned to notice. If the flow has three workarounds and a step everybody skips, fix it on paper first, with the people who run it. That is cheap; rebuilding an automation six weeks after launch is not.
• Anything about to change. A process due for a new system, a new regulation or a restructure next quarter is a moving target. Wait.

How do you run the audit yourself this week?

You need a pen, paper, one working week and an hour the following Monday. No software, no consultant.

1. Rule up five columns on Monday morning

   Task, times per week, minutes per run, who touches it, rules clear yes or no. Stick it on the wall by the kettle where people will actually see it.

2. Log every repeat all week, and not only yours

   The trigger phrase is "I'm doing this again": every time anyone touches a familiar task, add a line, unfiltered and untidied. Give two or three staff their own sheet as well. Owners see a different half of the business, and it is the admin clerk's sheet and the sales rep's sheet where the volume shows up.

3. Total the minutes on Friday

   Times per week multiplied by minutes per run, line by line, then sort by that number. The order will surprise you at least once, and that surprise is the point.

4. Score the top eight on Monday, out of 20

   Four factors, one to five each. Then apply the gate: if you cannot write a process's rules on one page, it comes off the list whatever it scored, including the ones you hoped would win.

5. Write the rules for the survivor

   Take whatever sits at the top and write its rules out longhand, as if for someone starting next week. If you cannot fill one page without writing "it depends", you have found the process that needs defining, not your first automation. If two survivors tie, pick the one whose owner actually wants it.

What happens once you have picked one?

Three things before anything gets built. Write the rules down including the exceptions, because exceptions are where automations fail. Name one person who owns the process and will say whether the new version is right. Agree the number you will check thirty days after launch — quotes sent per week, days to payment, hours off month-end — so the project can be judged rather than argued about.

That mapping is deliberately the first step in how we approach automating a workflow: map the process as it really runs, workarounds included, before deciding what software touches it.

Common questions

Should we automate the biggest problem or the easiest one first?

Start with the easiest process that is still genuinely worth doing. The first automation buys credibility as much as hours: if it lands quickly and works, the team brings you the next candidate themselves. A first project aimed at your most tangled process usually runs long, and the whole idea gets blamed for it.

How long should a first automation take to build?

A well-chosen first automation should be scoped in weeks, not quarters. If a proposal for a first project stretches across several months, the scope is too broad. Narrow it to one process, one rule set and one measurable outcome, then extend once it is running.

What if only one person understands the process?

That is a documentation problem before it is an automation problem. Sit with that person, write the rules down as they describe them, then check the written version against three real cases from last month. If the rules hold, you can automate. If every case needs an exception, the process is not ready.