Imagine it is the 28th of the month. An analyst has eleven Excel sheets open, two banking portals, and a chat with three departments that still haven't sent her their information. It is 8:40 PM. No one asked her to stay; the closing simply doesn't do itself. Every figure she copies has to be checked twice because the last time she didn't, the error showed up in a management meeting.
If you look at that process from the outside, it seems like a perfect candidate for automation. If you look at it from the inside, it's another story: she is the most careful person on the team, used as if she were a copier with judgment.
The work that doesn't appear in the job description
Almost no job description outlines what truly consumes the time of the person in that role. The description says "responsible for reconciliation" or "responsible for settlement." The reality is a mix of five very distinct types of work:
• Transcribe: move data from one place to another. • Cross-check: compare two sources and find differences. • Verify: check that the previous steps were done correctly. • Chase: ask, remind, and wait for information from others. • Decide: resolve what doesn't fit any rules.
The first four are rule-based work. They can be described, repeated, and executed without fatigue. The fifth is judgment-based work, and it is the only reason the company hired that person. The problem is that, in a manual process, the first four take up so much space that the fifth is done at the end, in a hurry, when there is no energy left.
A well-designed automation separates these five layers before writing a single line of code. That separation is the real diagnosis, and it determines whether the project improves someone's life or just changes the place where stress accumulates.
What happens when the role is not redesigned
There is a pattern that repeats when automation is delivered without thinking about the person: the process runs, hours are freed up, and no one knows what to do with them. Three things can happen, and none are good.
The first is that the freed hours are absorbed with more volume. The person does the same as before, but with more load, because "now that it is faster." The second is that the person is left without a clear role, and the fear that already existed that automation was coming to replace them starts to seem reasonable. The third is the quietest: the person continues to manually check what the system does, because no one explained to them what they can trust and what they cannot. They end up with the previous work plus the work of monitoring the system.
In all three cases, the failure is not technical. The system works. What failed is the decision about what the human does now within the process, and that decision must be made before building, not after delivery.
Designing the new place for the person
The role that remains after automation is rarely "supervising." Supervising without tools is looking at an opaque process and hoping nothing fails. The useful role is that of owner of exceptions, and for it to exist, it must be built as part of the project:
1. An explicit exception queue. Everything that the system cannot resolve with its rules goes to a visible place, with the necessary context to decide without having to reconstruct what happened. The person stops looking for the problem and starts solving it.
2. Rules that the person can read. If the logic of the automation lives in a code that only the builder understands, the team cannot trust it or correct it. Trust is built with transparency, not with promises.
3. A coexistence period with an exit criterion. Running the new process in parallel with the previous one helps to gain trust, but only if it is defined when it ends and with what evidence. Without that criterion, the double burden becomes permanent.
4. New responsibilities, named from the start. Analysis of variations, improvement of the rules, relationship with the areas that provide the information. These are tasks that almost always existed in theory and never had time.
Quality of work life: what can be measured
Talking about well-being in an automation project sounds soft until it translates into observable variables. There are several that any company can review before and after:
• How many hours are worked outside of regular hours on closing days. • How many people are the only point of failure of a process that cannot be left unattended. • How many corrections are made after delivering a result. • How many times a month someone has to interrupt what they were doing to respond to an urgency of the process.
None of these appear in a traditional return on investment, and all have real costs: errors, turnover, knowledge that leaves with the person who got tired. A project that reduces execution time but leaves these four variables intact saved hours, but did not solve the problem.
A question worth asking in the discovery
Before defining what gets automated, there is a conversation that almost never happens and that changes the entire design: sitting down with the person who currently executes the process and asking them what part of their job they would like to stop doing, and what part they would never give up. The two answers outline the boundary of automation more precisely than any flowchart.
In those conversations, something often emerges that no technical assessment detects: the person already knows which work exhausts them and which gives them meaning. What they need is for someone to design the system around that difference.
So. A successful automation is not recognized by what the system does at 8:40 PM on the 28th. It is recognized by what the analyst does at that hour: nothing, because they left at six, and the next day they came in to review the three exceptions that truly needed their judgment.
At EmasT, we start each project with that conversation. If you are evaluating automating a process and want to first define what would remain for your team, that is a good way to start.