Hire vs automate: should you add a person or automate the work?

The short answer: automate the work that repeats, follows rules and arrives in volume. Hire for the work that needs judgment, a relationship or taste. Most companies that ask us this question are about to hire someone for a job that is mostly copying information between systems, and the honest answer is a smaller hire plus an automation, or no hire at all.

We build automation for a living, so read this with that in mind. We also say "don't automate that" fairly often, and the second half of this guide is about when hiring wins.

Last updated: September 9, 2026

Hire or automate: the comparison in one table

What does a new hire actually cost?

More than the salary, and the gap is where most hire-or-automate decisions go wrong. Salary is the line everyone knows. The rest is spread across five other lines that rarely appear in the same spreadsheet.

Here is the loaded-cost framework we use. Fill it in with your own numbers; we deliberately give none.

One number worth having on the employer-costs line, because it is public: for a salaried employee in Israel the employer's national insurance contribution is 4.51% of the wage on the lower band and 7.6% above it, per Kol Zchut's page on national insurance for salaried employees (2026 rates). Add pension and severance contributions, paid vacation and the rest, and the loaded monthly cost sits well above the gross figure on the offer letter. Your accountant has the exact multiplier for your company; use theirs.

The ramp-up line deserves a second look. A person hired into an operations role is usually doing the job at full speed after 3 to 6 months. In the meantime you are paying the full loaded cost and getting a fraction of the output, while somebody senior spends part of every day teaching. If the role turns over every 18 months, you're paying that ramp-up again and again.

What does automation actually cost?

Automation has a different cost shape, and only sometimes a lower cost: most of the money goes in at the start, then there is a smaller, ongoing line for keeping it alive. Here is the equivalent framework.

Two things changed the picture on this side. The first is that open-source tools pushed the hosting line close to zero: an n8n instance on your own server runs your workflows with no per-task pricing, and your data stays with you. The second is that language models made messy input automatable. Reading a supplier's PDF, understanding a customer's WhatsApp message, pulling the fields out of a form that was filled in badly. That used to be a person's job by necessity. A model such as Claude reads it now, and the person handles what the model flags.

The maintenance line is where automation projects quietly die, so I'll be blunt about it. A system nobody owns breaks the day a supplier changes their invoice layout, and stays broken until someone notices the backlog. Budget an owner before you budget the build.

How do the two costs behave over three years?

Differently enough that a one-year comparison misleads. A hire's line starts at the loaded monthly cost and climbs: raises, the second hire when volume grows, another ramp-up every time someone leaves. It never comes down on its own.

An automation's line spikes in the first two months, drops to hosting plus maintenance, and stays there. It bumps up when the process changes and the workflow has to follow, and it stays flat when volume doubles, which is the property the hire's line can never have.

The crossover point is what you're really looking for. For rule-based work in real volume it usually lands inside the first year. For low-volume work it may never arrive, and that is a legitimate answer: don't automate it.

Which work should you automate and which should you hire for?

Sort the work by its shape, never by the job title. A single role usually contains 3 or 4 different shapes of work, and each of them has a different answer.

Four signals push hard toward automate: the work already arrives through a system (email, a form, a CRM), the same 5 steps happen every time, whoever does it today can explain it in an afternoon, and the volume is real.

Two signals push hard toward hire: nobody can write down the rule, and the cost of being wrong is high enough that you want someone accountable by name.

Why is the answer usually both?

Because almost no job is one shape of work. Take intake at a professional-services firm. A new client arrives by email or through a form, someone reads what they sent, checks it against the requirements, opens a file in the practice system, requests the missing documents, chases them, and finally hands a complete file to the professional who does the actual work.

Everything up to the handoff is intake and paperwork. It is rule-based, it arrives in volume, and it changes rarely. Automate it: the agent reads the submission, opens the record, asks for what's missing and chases until the file is complete. The professional at the end is judgment and relationship. That person you hire, and they now spend their day on the part only they can do.

The pattern holds across industries. Automate the intake and the paperwork. Hire for the judgment. The hire you make after automating is usually a different hire from the one you were about to make: more senior, and a lot less likely to leave from boredom.

We run our own company this way, on the same agents we build for clients, and it is why a small team can carry the workload it does.

What should you ask before you hire or automate?

Ask these before either decision, in this order. The answers usually settle it.

1. What does this role actually do, hour by hour, for a week? Have the current person log it. The paperwork share is always higher than the manager thinks.
2. Which of those hours follow a rule someone can write down, and which need a call only an experienced person makes?
3. How many items a day, and how much does that number swing between quiet and busy weeks?
4. How often does the process change, and who decides the change?
5. What happens today when a case doesn't fit the process? Who catches it?
6. If the person doing this today left tomorrow, what would break and how long would it take to recover?
7. Who on your side would own an automation once it's live?

If question 2 comes back mostly rules, question 3 comes back a real volume, and question 7 has a name, automate first and revisit the hire in 3 months. If question 2 comes back mostly judgment, hire, and give that person automated intake so they start with a clean queue.

How do you run your own numbers?

Plug your loaded cost per hour and the hours the work takes into our ROI calculator. It asks for the things this guide told you to collect: how many people touch the process, hours per week, what they cost, and roughly what share of the work is repetitive. It gives back the annual cost of the work as it runs today and the hours an automation would return.

Use the loaded cost from the framework above, never the gross salary. Running the calculator with gross salary understates the case for automation by whatever your employer-cost multiplier is, and it understates the case for the right hire by the same amount.

When is hiring the right answer?

When the work is judgment and relationships, when the process changes faster than you could rebuild it, and when nobody can yet explain what the job is. A fourth case: when volume is low. Automating a task that takes someone 20 minutes a week is a hobby.

There is a version of this where a company automates too early. They build a system for a process they hadn't understood, the process turns out to be 5 different processes wearing one name, and the automation handles the easy one while a person quietly does the other 4 by hand. If you can't describe the work precisely, hire someone who'll do it for 6 months and write it down. Then automate what they wrote.

And there is the plain human case. A growing company needs people who will notice what the process should become, argue with it, and carry the relationships. Software doesn't do any of that. Hire those people, and give them fewer forms to fill in.

Frequently asked questions

Is it cheaper to hire or to automate?

It depends on the shape of the work, which is why this guide gives you a framework and no figures. Automation is mostly an up-front cost with a small maintenance line, and its per-item cost falls as volume rises. A hire is a recurring loaded cost that grows with every added person. For rule-based work in volume, automation wins on cost within its first year in nearly every case we've seen. For judgment work the comparison is meaningless, because the automation can't do the job.

What is the loaded cost of an employee?

The full amount a person costs the company beyond gross salary: employer contributions such as national insurance, pension and severance, paid leave, recuperation pay, equipment and software seats, the months of ramp-up before full productivity, the management time they consume, and the cost of replacing them if they leave. Your accountant can give you a multiplier for your company; apply it to gross salary before comparing anything.

Does automation replace employees?

In our experience it replaces the hire you were about to make far more often than it replaces someone already there. The existing team stops doing the paperwork share of their day and takes on more of the judgment share. Companies that automate to cut headcount usually discover the people they let go were the ones catching the exceptions.

How long does it take before an automation pays for itself?

For a rule-based, high-volume process it is usually a matter of months, driven by how many hours it returns each week against a one-time build. The honest way to find out for your case is the loaded-cost framework above, plugged into the ROI calculator. If the calculator shows a payback beyond 18 months, that process probably isn't the right first candidate.

What kind of work should never be automated?

Anything where the cost of a wrong answer is high and no rule captures the decision. Firing, pricing a one-off deal, handling a furious customer, a medical or legal judgment. Automate the preparation for those decisions and leave the decision with a person whose name is on it.

Can a small business afford to automate instead of hiring?

Yes, and small businesses often get the most out of it, because one automation can stand in for a hire they couldn't justify at full time. Open-source tools like n8n run on a small server with no per-task pricing, and the build is scoped to one process. Start with the single process that eats the most hours and has the clearest rules.

Next step

If you're weighing a hire right now, bring the role description and a week of what the job actually involves. We'll tell you which parts we'd automate, which we'd hire for, and whether the hire changes shape. Talk to us and we'll map it with you before anyone decides anything.