Auto Alpha AdvisoryEvery owner who asks me whether to automate a task has already priced the alternative. They know roughly what another admin person costs. What they do not know is what the automation costs — the whole thing, not the subscription — so the comparison never actually gets made.
I am a CA(SA) who writes the code as well as the business case. I have built the automation, paid to keep it running, and watched it break on a Sunday. Both sides of this ledger are on my own books.
The short answer: the threshold is not volume. It is variance. A task with stable inputs beats a hire at far lower volume than owners expect. A task with messy inputs loses to a hire at far higher volume than vendors admit.
What a junior ops hire actually costs in South Africa
More than the advertised salary, and the published figures disagree with each other by a factor of four before you add a cent of overhead.
Indeed puts the average administrative assistant salary at R7,464 a month, from 1.8k reported salaries, updated 30 July 2026. SalaryExpert, measuring the broader office administrator band, puts the national average at R354,041 a year, via bBrief's April 2026 salary guide. Same-sounding title, very different jobs. Before you compare anything to an automation, decide which of those two people you are actually hiring, because the answer moves your threshold by a factor of four on its own.
Then load it. SARS charges a Skills Development Levy of 1% of total salaries once you expect to pay more than R500,000 in salaries over the next twelve months. The employer's UIF contribution is another 1% of remuneration, capped at R177.12 a month. Those two are small and certain.
The rest is neither. A 13th cheque is another month of salary spread across twelve. Then medical aid contribution, a recruitment fee if you use an agency, a laptop, a desk, leave cover, onboarding, and the cost nobody puts on the schedule: your own hours managing the person. I model a hire at base plus about a third. That is a rule of thumb off my own numbers, not a published figure, and you should build your own version of it before you use mine.
What an automation actually costs, including the line everyone leaves out
Three things: build time, tool subscriptions, and maintenance. The third is where most business cases quietly die, because it is the only one that never appears on a quote.
Subscriptions are the small number and the one everyone fixates on. Build time is the honest one — real hours, at whatever your hours are worth, and roughly double whatever you first estimated.
Maintenance decides it. An API changes its response shape. A supplier redesigns the page you were reading. A model version retires. A credential expires at 2am on a public holiday. None of that is a failure of the automation; it is the weather. A business case with no monthly maintenance number is a brochure.
There is a second question hiding inside that one, and it matters more for a mid-market South African business than the rand figure does: who does the maintenance? If the answer is an outside developer, you have a call-out rate and a response time to budget for. If the answer is you, you have taken on a small permanent obligation to a piece of software, and you should count those hours the same way you would count a salary. The businesses that get burned by automation are rarely the ones that picked the wrong tool. They are the ones that built something nobody owned.
Why volume is the wrong test
Because volume tells you how much work there is, not how much of it is the same. A thousand identical tasks automate cleanly. Fifty tasks with fifty exceptions do not.
Chris Lamberton, who led robotic process automation for financial services at EY, gave the selection rule in a January 2017 interview, before any of this was called AI: "Robots should be targeted at the 70% of a process that's simple, with the 30% that's complex left to humans." His account of why projects fail starts before the tooling — "companies target the wrong processes. Often, they pick the most complex ones" — and he is blunt about chasing the rest: trying to solve the complex 30% "can take way more than 30% of the budget, and may still not deliver a good result."
That is a variance test wearing a percentage. The simple 70% is the part with stable inputs and a rule you can write down. The complex 30% is where the exceptions live, and it is the part that eats the budget when somebody automates it anyway.
The three questions that decide it
Ask these before you write a line of code or sign a vendor.
Does the input arrive in the same shape every time? A CSV from the same system every morning is stable. A supplier invoice that arrives as a PDF, a scan, an email body, or a photograph of a printout is not.
Can you write the decision rule down? If you cannot express it in a paragraph a new employee could follow, an automation cannot follow it either. Vague rules do not become precise by being coded.
What does a wrong output cost? An automation that drafts a report you review is cheap to get wrong. One that pays a supplier is not. High variance plus a large blast radius should send you to a hire whatever the volume says.
The worked example: what R220 a month replaced
My portfolio intelligence bot scans 80+ assets every morning and writes the brief I used to write by hand. It costs about R220 a month to run across model calls, two data APIs and a small server, and it replaced one to two hours of daily research.
Set that against the smaller of the two salary figures above and it looks absurd. It is not, quite. Here is why.
The build was not a weekend. A first version took a few evenings. Making it reliable took considerably longer, spread over weeks, because production breaks in ways a test run never shows you. Maintenance runs an hour or two most months. It has never been zero, and twice it has been a bad afternoon.
It works because the inputs are stable. Prices are numbers. The APIs return the same shape every day. The decision rule fits in a paragraph: flag anything that moved past a threshold, summarise the news attached to it. And a wrong output costs me a poor brief, which I notice in about thirty seconds. Stable input, writable rule, small blast radius. That combination is why it beat a hire at what is, by any honest measure, a low volume of work.
When the hire still wins
When the input is a person, an unstructured document, or a decision that changes with context.
Debtors follow-up is the clearest case. It is repetitive, the volume is real, and it still loses to a person, because knowing which client gets a firm letter and which gets a phone call is judgement about a relationship. The same holds anywhere the exception rate is high and the exceptions are the expensive part.
Then there is the argument that has nothing to do with arithmetic. A person absorbs new work. When the task changes, they adapt in a conversation. An automation does one thing and needs a developer to do anything else. If the role is genuinely one task forever, that costs you nothing. Most junior ops roles are not one task forever.
What to do this week
Do not model it. Count it. Take the task you are weighing up, log every instance for a week, and mark each one clean or exception. If more than one in ten needed a human decision, hire the person and automate the clean nine tenths later, once you understand them properly. If almost none did, you are already past the threshold and paying a salary for it.
The arithmetic is not the hard part. The counting is, and it is the step everyone skips.
If you want a second opinion on which of your processes are stable enough to automate and which are not, that is what a bounded AI automations engagement is for: fixed scope, a deadline, and an audit trail on your own data. Or read the full build log behind the R220-a-month pipeline and price your own version of it.