Automation or another hire: which does your business need?

What happens at 2am and over the December shutdown?

This is where automation has a genuine edge. An enquiry landing at 22:40 on a Saturday can be acknowledged immediately and put in front of the right salesperson by Monday; handled entirely by people, it sits unread. That after-hours acknowledgement is usually the first thing built, and in this market it usually gets built on WhatsApp rather than email. In December the gap widens: a business that closes for two weeks still has customers and competitors who do not, and a scheduled report does not go to the coast.

Two honest caveats. An automation only survives the shutdown if it does not run on a PC under a desk in a locked office that may also be without power, so anything unattended belongs somewhere that stays up. And unattended does not mean unwatched: something must raise a hand when it stops, or you find out in January that it failed on 12 December.

How does each option fail?

People fail visibly and gracefully. Someone is sick, someone resigns and takes ten years of undocumented process knowledge with them, a wrong hire costs months and a difficult conversation. Frustrating, but you see it coming.

Automation fails silently and at scale. The Tuesday report stops generating and nobody notices for three weeks: its absence looks like a quiet inbox. A flawed rule sends three hundred wrong messages before a human intervenes. Worst is the orphaned build: whoever made it has left and everyone is afraid to touch it. The defences are unglamorous and non-negotiable — alerting when a step fails, exception handling, an audit trail, documentation, and a named owner.

The biggest failure mode belongs to neither option: automating a process nobody has agreed on. If three people run the same task three different ways, software picks one and does it faster, wrongly, forever. Automation without process clarity just makes the mess arrive sooner, which is why much of the value in a properly scoped workflow automation project sits in the mapping done first.

What work should stay with people?

Judgement work, and more of it than most automation pitches admit. Negotiating with a supplier who has missed a deadline. Deciding when to break your own rule for a customer worth keeping. Hiring, mentoring, choosing what the business does next. Anything where being wrong is expensive and the rules cannot be written in advance.

A practical test: if you can write the rule down completely, with no "it depends", software can run it. Every "it depends" is a person's job, and automating the first category buys back hours for the second.

How do you tell the team so it lands as support, not threat?

Reaction depends mostly on how the change is introduced, not on what the software does. The people who most hate compiling the monthly report are the ones who compile it. Take it off them well and you get loyalty; spring it on them and you get a rumour by lunchtime.

• Tell them before you start. A tool that materialises one Monday morning reads as a decision made about people, not with them.
• Be specific about what changes. Name the tasks going away and the ones staying. Vague reassurance sounds like something being hidden.
• Involve whoever runs the process. They know the exceptions and the client who is always handled differently, and people defend what they helped design.
• Be honest about headcount. If nobody is losing a job, say so plainly and behave consistently. If a role will change, say that instead. A comfortable promise broken later costs more trust than the automation saved in hours.
• Say what the freed hours are for. "You will spend Thursday chasing the accounts that owe us, not building the spreadsheet" is something people can picture. "Efficiency" is not.

Then follow through on adoption: a system nobody trusts gets worked around within a month, and you pay for the automation and the manual process. That is why hands-on training and after-launch support is part of the work.

So which comes first, the automation or the hire?

For most businesses at this point it is both, in sequence: automate the repetitive load first, then hire into whatever is left. Hiring into an unclear manual process bakes that process in, and you only find out what capacity you genuinely need once the drudgery is gone.

There are clear cases for hiring first. When the process changes month to month, there is nothing stable to build on. When volumes are low, a build may never pay back. When the bottleneck is a skill you do not have, no automation supplies it. And if you cannot describe the process to a colleague, you cannot explain it to software.

A workable way to decide, before spending anything:

1. Track where the hours actually go

   For two weeks, have the team note what eats their time. Most owners are surprised by at least one item on the list.

2. Split the list into rules and judgement

   Rule-based tasks can be described completely, with no "it depends". Everything else is judgement work and stays with people.

3. Act on whichever pile is bigger

   If the rule-based pile dominates and is stable, that is the shape of work automating a business process is built for. If the judgement pile dominates, hire. If neither is stable, fix the process on paper first.

Choosing the right first candidate is its own skill, and getting it wrong is the most common reason automation projects disappoint. We work through it in what to automate first.

Common questions

Is automation cheaper than hiring someone?

Not automatically. They have different cost shapes: a hire is a recurring monthly cost including overheads, plus a ramp-up before the person is productive, while an automation is mostly upfront build cost plus a smaller running and maintenance cost. Automation wins on high-volume, stable, rule-based work; a person wins where the work is varied, low-volume or needs judgement. Compare both over 24 to 36 months.

Will automating a process cost someone their job?

It does not have to. The version we would argue for is a role you never add rather than one you remove: the existing team carries more volume instead of you writing the next job ad. What matters is being straight about which of the two yours is, because announcing an automation as neutral and then restructuring later does far more damage than the honest version.

Can we automate a process that is not written down?

You can, but it is the most expensive place to start. Undocumented processes carry exceptions that live in one person's head, and those surface halfway through a build as rework. Half a day mapping the process with the people who run it, workarounds included, usually saves weeks, and sometimes shows that a process change alone solves the problem.