The honest answer depends on your intent
Automation creates capacity. What happens to that capacity is a business decision, not a technical consequence, and it is one you make rather than one the software makes for you.
We ask about it during scoping because the answer changes the design: an automation intended to remove a role is scoped differently from one intended to absorb growth.
What we usually see
The most common pattern across our projects: nobody leaves, the role changes shape, and the hire that was about to be made is not needed. One client planned two admin hires, spent £14,000 automating order intake and invoice matching, hired one, and moved that person into account management.
“Take on more work without hiring” is a real answer to what the freed hours are for. “They will be more productive” is not, and it will not survive contact with a board paper.
Tell your team early
- Say what the automation is for, in plain terms, before they hear it as a rumour
- Say what happens to the time it frees
- Involve the people who do the task in designing the replacement — they know the exceptions
- Be honest if headcount is affected; people work it out anyway and dishonesty poisons adoption
Silence is what causes resistance
Teams that are not told assume the worst, and the people whose knowledge you need to build the thing become the least cooperative. That is how a technically sound project fails on adoption.
Teams that are told, and asked to help, tend to produce a better specification than any consultant would.
Where automation genuinely does reduce headcount
High-volume, low-judgement functions at scale — an outbound calling floor, a keying operation. In one call-centre deployment, 60 outbound agents became 4 monitoring staff.
That is a real outcome and it deserves a real plan: notice, redeployment where possible, and honesty rather than discovering it at the end of a project.