In projects that work, the job doesn’t disappear. What disappears is the part of the job that nobody claims: searching, retyping, checking things by hand.
This is a claim that needs to be backed with precision, not reassurance. People who work in an office can tell a realistic description from a stock phrase, and that difference determines how a project is received far more than its technical features do.
The distinction between task and role
A role is made up of tasks. An administrative caseworker gathers documents, checks requirements, consults precedents, evaluates, drafts, communicates. A support technician looks up information, diagnoses, intervenes, documents.
Automation doesn’t act on roles. It acts on individual tasks, and generally on the ones with three traits: repetitive, rule-defined, no discretion involved.
The consequence is that a role changes composition. If forty percent of the time was absorbed by collecting and transcribing and that share shrinks, the role doesn’t disappear: it concentrates on the remaining tasks.
This concentration has an effect that needs to be named openly. The remaining work is on average more demanding, because the simple cases arrive already prepared and what’s left are the hard ones. It’s an improvement in professional content and an increase in intensity at the same time. Presenting it only as relief is inaccurate, and the people doing that work notice within a few weeks.
What moves to the machine, and what stays
A concrete list is worth more than a principle.
Moves to the machine. Searching for a document in an archive. Transcribing data from a document into a system. Formal completeness checks against a defined list. Comparing values found in different sources. Classifying according to established categories. Preparing a draft on a recurring template. Retrieving similar cases already handled.
Stays with the person. Judgment on the merits and the decision itself. Interpreting a rule in a case it wasn’t written for. Handling the exception. The relationship with the citizen, the client, the colleague. Taking on formal accountability, which cannot be delegated to a system. And recognizing that something doesn’t add up — which remains the most effective control an organization has.
The line isn’t technological, it’s about accountability: whatever someone has to answer for stays with that person, and the system stops short of it.
An honest clarification. Not every role changes to the same degree. A role made up almost entirely of repetitive tasks changes more deeply than a varied one. Saying this clearly, and addressing it with the people concerned and with employee representatives where applicable, is preferable to a generic formula nobody believes.
Why operator involvement determines adoption
Not for morale reasons, but for three operational ones.
They already know the real rules. Formal procedure and actual practice almost always diverge, and the divergence carries information: the recurring exceptions, the checks added over time after a mistake, the steps that get skipped because they’re pointless. A system designed around the formal procedure gets the real cases wrong.
They’ve already catalogued the exceptions. Asking the people who do the work which ten cases complicate their day produces, in an hour, the list that would otherwise take six months of operation to surface.
Rejection is silent. An imposed system doesn’t get challenged: it gets worked around. People keep working the way they always did and use the tool only for the operations that are mandatory. From the outside, the project looks active and produces no effect.
Effective involvement is specific: participation in mapping the process, defining test cases, validating results against their own work, a structured channel for reporting errors. A launch-time institutional announcement doesn’t produce the same effect.
One thing does more for adoption than anything else: making it visible that reports lead to changes. If a reported error gets fixed and the fix gets communicated, the channel stays open. Otherwise it closes within a few weeks.
Training as part of the project
Not a closing module, but an activity that accompanies the rollout and continues afterward.
It needs to cover three things. What the system does and how to use it — the easiest part. What the system doesn’t do and where it gets things wrong, with real examples of errors found during testing: this is the part that builds trust, because a system presented as infallible loses credibility at the first mistake. And what to do when the output is wrong: how to correct it, how to report it, to whom.
Training needs to be differentiated by role. The people who use the system, the people who supervise it and the people accountable for it need different content.
And it needs to be repeated. People change, the system evolves, and training delivered once at launch only covers whoever was present that day.
What this approach doesn’t solve
It doesn’t eliminate concern about the impact on employment, and it isn’t a vendor’s job to reassure people about decisions that belong to the organization. What’s correct is to be explicit about which tasks change, and let the organization communicate its own choices.
It doesn’t resolve pre-existing organizational conflicts. A project that cuts across offices that disagree makes that disagreement visible.
It doesn’t produce adoption where the process hasn’t changed. If the workflow stays identical and the tool gets bolted on, it’s perceived as extra work.
And it doesn’t work without dedicated time. Involvement and training require hours from operational staff, which need to be recognized and carved out of the regular workload, not added on top of it.
In closing
The quality of a project of this kind is also measured by how precisely it describes what changes for the people who do the work. Generic formulas about people and technology working side by side convince no one that the work is really being done.
What convinces is a list: these tasks move to the system, these stay yours, this is what the system gets wrong, this is the channel for reporting it.
If you’re facing a project with a significant impact on an office’s work, we’re available for a conversation with the team involved, before the technical choices are made.
