The people side: what happens to the staff whose work you automated

The part of an automation project that decides whether it lasts has nothing to do with the software. It is what happens to the person whose task you automated, and whether the people left have any reason to make the new system work.

The short answer

Decide before you start what the time you save is for, and tell people. Automation projects that do not answer this get answered anyway — by rumour, and the rumour is always redundancy. A team that expects to be replaced will not report the system’s mistakes, and unreported mistakes are what kill the project.

Why silence is the expensive option

When a company automates a task without saying what it means for the people doing it, three things happen in order.

People stop volunteering problems, because a problem is evidence the system is not ready and readiness is now the thing that threatens them. Then they stop using it as intended, keeping the old spreadsheet alongside. Then the project is judged on numbers produced by people who quietly work around it.

None of that looks like resistance. It looks like the technology underperforming, and it gets diagnosed as a model problem.

What the work actually becomes

Automation rarely removes a job here. It removes a portion of several jobs and replaces it with a different kind of work — checking rather than producing.

That change is bigger than it sounds. Entering forty orders is tiring but it feels productive. Confirming forty machine-drafted orders is faster and feels like doing nothing, while requiring more attention, because the errors are rare and you must stay alert to catch them.

Plan for it: rotate the checking role, keep the sessions short, and never measure a checker only on volume, or they will start approving without reading — which removes the control you designed in and leaves you with an unsupervised system nobody meant to build.

The three conversations to have before go-live

Conversation	With whom	What must be said
What this is for	The whole team	Which task, what the saved hours go to, and what is not changing
What your job becomes	The people doing that task	Concretely: what leaves, what arrives, what is unchanged
How to report it going wrong	Everyone touching it	Where a complaint goes, and that reporting is welcome

The third is the one skipped most and it is the most valuable. The people closest to the work find failures months before monitoring does, but only in an organisation where saying so is safe.

Be honest when the answer is headcount

Sometimes the point genuinely is to do the same work with fewer people. Pretending otherwise is worse than saying it, because people work it out and then trust nothing else you said.

If that is the case, say what the timeline is, whether it is by attrition or otherwise, and what support exists. You will get a slower, more honest project. The alternative — a reassurance that turns out to be false — makes every future change harder.

The World Economic Forum’s Future of Jobs Report 2025, drawn from over a thousand employers, describes a labour market being reshaped by technology alongside demographic and economic forces — with reskilling, not simple replacement, as the dominant employer response. The ILO reaches a similar conclusion from a different direction: its 2025 index of occupational exposure finds that because most occupations consist of tasks needing human input, transformation of jobs is the likeliest outcome rather than wholesale automation. That is the honest framing for most Gulf SMEs too: the tasks move before the jobs do.

Who should own the system afterwards

Name someone before launch. Not the supplier, and not “IT” in general — a person in the business who owns the outcome, has the authority to pause it, and to whom problems are reported.

Without a named owner, a system enters a slow decline nobody is responsible for noticing: the accuracy drifts, a workaround becomes standard, and eighteen months later it is switched off by someone who never knew what it was for.

Give that person three things: the test set from before launch, the monthly cost line, and the authority to stop it. That is what makes ownership real rather than nominal, and it is why we build the acceptance test set to be re-runnable rather than throwaway.

Managers lose visibility too

The disruption people plan for is at the desk. The one they miss is a level up: a supervisor who used to understand the day by watching the work happen now sees only a queue of confirmed items.

Volume, backlog and who was struggling were all legible from the room. Automate the task and that signal disappears, usually before anything replaces it — so problems that used to surface in a morning surface in a monthly report instead.

Replace it deliberately. A daily count of items handled, items corrected and items the system refused gives a supervisor back roughly what they lost, in thirty seconds a day. Decide who reads it and when, or it becomes another dashboard nobody opens. NIST’s AI Risk Management Framework puts this under Govern — accountability is a named role and a reporting line, not a policy document — and it is the function most small deployments skip entirely.

This is also where the shape of the system matters. A script that does one step leaves the process visible; an agent that decides its own steps does not, and needs more reporting built in to stay legible to the people accountable for it.

Training that actually lands

Training people on what the system does is nearly useless. Train them on where it fails.

The productive session is an hour with ten real examples, three of which the system gets wrong, discussed openly. It sets a correct expectation — this is a tool with a known error rate, and your judgement is the control — instead of the impression that a machine is now in charge and disagreeing with it is disloyal.

It also sharply reduces the two failure modes at either end: blind trust, and blanket refusal to use it.

A worked example

A company automates invoice data entry for a finance team of four. One person had spent most of her week on it.

The first version was announced as efficiency, with no detail. Within a month she was checking every automated entry against the original by hand — slower than before — because being the person who let an error through was the visible risk, and being slow was not.

What fixed it was not a change to the software. The saved time was assigned publicly to supplier reconciliation, a job the team had never had time for and which found real money — the kind of second-order gain that only appears once you have chosen the first process deliberately. The checking standard was written down: confirm anything above a threshold or flagged by the system, spot-check ten per cent of the rest. Her job description changed to reflect the reconciliation work.

Same system, same accuracy, opposite outcome — and the hours only appeared once somebody said what they were for.

What to measure, beyond the hours

Three numbers tell you whether it is actually working: how many items are corrected by a human each week and whether that is falling, how many problems people report each month, and whether anyone still maintains a parallel spreadsheet.

That last one is the most honest metric in the whole project. A shadow process is the team telling you the system is not trusted yet, in the only language that costs them nothing.

How we handle it

On our automation projects the people doing the task are in the first conversation, not shown the result at the end — partly because it is fairer, mostly because they know where the process really breaks and no amount of scoping replaces that. Tell us which task you are considering and we will ask who does it now.

Frequently asked questions

When should we tell the team?

Before the project starts, not before launch. The people doing the task are your best source on where it goes wrong, and involving them late wastes that and reads as concealment.

What if people deliberately make the system look bad?

It is rare, and it is nearly always a rational response to an unanswered question about their job. Answer the question and it stops. Treating it as an attitude problem confirms the fear that caused it.

Do we need to retrain people formally?

Usually an hour on where the system fails, plus a written standard for checking, is enough. Formal programmes matter when the role changes substantially, not when a task changes.

Who decides when the system is switched off?

Name that person before it goes on. A system nobody can stop is a system nobody is responsible for, and it will outlive its usefulness.

How do we know it is trusted?

Look for the parallel spreadsheet. When the manual copy quietly disappears, the system has been accepted; while it survives, it has not, whatever the reported hours say.