Automation and hiring are rarely direct substitutes. A person can handle ambiguity, build relationships and take on new work. A system can repeat a defined task and provide capacity outside staffed hours. Compare the work each option will actually perform, then include supervision and exceptions in both cases.
The arithmetic, using your numbers
Do not use anyone's example figures. Use yours. But the shape of it looks like this:
- For a hire, include salary, employer costs, recruitment, management time, tools and the share of productive capacity available for this process.
- For automation, include discovery, build, integration, usage, maintenance, monitoring and human exception handling.
- Estimate the hours the system could genuinely remove or redeploy. Do not count the full salary unless the staffing cost actually changes.
- Compare a base case, a lower-volume case and a higher-volume case because utilisation changes the result.
Work that may suit automation
- High volume, low judgement. Classifying, routing, extracting, following up. A busy shared inbox that someone sorts by hand is the typical starting point.
- Tasks where response time matters and a safe, approved action can happen outside staffed hours.
- Repetitive follow-up where the sequence, frequency and stop rules are explicit.
- Processes that need to be identical every time. Consistency is what software is for.
Where you should hire a person instead
Hiring may be the better option in these situations:
- The process is not stable yet. Automating a process you are still figuring out just freezes a bad version of it in code. Do it by hand until it stops changing weekly.
- The judgement is the job. Negotiation, complex diagnosis, anything where the answer depends on reading a person.
- Low volume where the measured benefit does not cover implementation, operation and review.
- You need someone who can also do the other nine things. A person is general-purpose. That flexibility is worth real money in a small team, and an automation has none of it.
A hybrid can preserve judgement
A practical design may let software prepare, classify or route while a person approves the decision. That can reduce repetitive work without assuming that judgement has disappeared. Define the review queue, escalation target and maximum acceptable delay, then measure whether released capacity is actually used. Treat headcount savings as a scenario until staffing cost or productive output changes in observed data.