Hidden work: the steps nobody wrote down, and why they break automations
Automations follow the written process, and the real work has steps nobody wrote down. Where they hide, what happens when a bot meets one, and how to find them.
The short version
Automations fail on hidden work because they are built from the documented process, and the real work includes steps nobody wrote down: email and phone requests, spreadsheet clean-up, unwritten rules. Varick Agents reports a gap of 30% or more between SOP and real work. Find the steps by laying the SOP over real cases, logs, screens and the people who did the work.
- 01Where the unwritten steps live
- 02What an automation does when it meets one
- 03The people who hold it, and why they will not simply tell you
- 04How to find them
- 05What I would do first
- 06Where the evidence is thin
On this page
- What I read
- McKinsey, Shorrock and Varick Agents, on 2026-10-19
- Independent counts of the gap
- None found
- The example process
- Invented, and labelled
Key takeaways
- McKinsey’s retailer case traces missing work to email and phone requests, spreadsheet clean-up and waiting for busy decision makers, none of it logged by the ERP.
- An automation built from the SOP follows the written path, so it stops or finishes wrongly at the unwritten rule; the only gap counts I found come from a vendor’s own engagements.
- Find the hidden steps by laying the SOP over real cases and the people who did them, then delete, code or hand off each step before you automate it.
The process document describes the work somebody imagined. The work itself is done by people who have spent years filling the gaps in that document. An automation is built from the document, so it inherits the gaps and none of the people.
That is my claim, and you can argue with it. I think the first job before any automation is to find the steps nobody wrote down, and that most companies skip it because it feels like consulting and not like AI. On 2026-10-19 I re-read three sources to see how much evidence there is: a McKinsey article on process and task mining, Steven Shorrock’s essay on the varieties of human work, and a long post by Daniel Kornum of Varick Agents. There is less evidence than I would like. I will say where.
My position: map one real workflow before you build anything, start from recent cases and not from the SOP, keep the people who did the work in the room, and be ready to delete some of what you find. The method is in our guide to mapping a process for AI.
Where the unwritten steps live
Here is one made-up example. A supplier invoice arrives and its price is 3% above the purchase order. The SOP has a box for that: resolve the mismatch. This is how a clerk resolves it.
- 01Invoice arrives and is matched to the purchase orderIn the SOP and in the system log. A bot sees this step.
- 02System flags a 3% price differenceIn the SOP, as “resolve the mismatch”. The SOP says nothing about how. A bot built from it must guess here.
- 03Clerk emails the buyer: is this the freight surcharge?Hidden. An email, so no event in the system.
- 04Buyer checks a side deal in a private spreadsheet and phones the supplierHidden. A spreadsheet and a phone call. Nothing in any system.
- 05Clerk applies a rule: under 2% over, approve; above that, ask the controllerHidden. The 2% lives in the clerk’s head and appears in no document.
- 06Approver clicks Approve and payment is releasedLogged. The log shows days of delay between the flag and the approval, and no reason for them.
An invented illustration, not a customer story and not Nolli data. The dimmed steps leave no record in a business system. Three of the six steps are the ones the document skips.
None of this is exotic. McKinsey’s best-known case is a large international retailer that ran process mining over its operations and found $200 million to $500 million of potential savings. When its improvement teams tried to capture them, they could identify initiatives for only about a quarter. McKinsey says the company had a partial picture. The tool missed delay and rework that came from actions outside the ERP system: change requests sent by email or phone, spreadsheet work to clean or format data before it went in, and decisions that waited because the people who had to make them were busy.
Read that list again. Email. Phone. A spreadsheet. Someone who is not at their desk. Every item is something a competent clerk does without thinking, which is exactly why nobody writes it down.
Kornum’s list, from the companies Varick audits, is the same list in miniature. A spreadsheet people always check first. A colleague they email directly because the system notification does not work. Seventeen kinds of exception a team handles every month. An unwritten rule that anything over $5 million goes to the controller. He says the real workflow differed from the documented one in 50 places in the case he describes. I cannot check his count. It is one vendor describing its own work.
What an automation does when it meets one
Shorrock, a human factors specialist, describes a tactic called work to rule. Railway workers in Britain used it as industrial action: do exactly what the written rules say, nothing more. Shorrock’s point is that the system then cannot function effectively. The rules were never enough to run on.
“It is usually impossible to prescribe all aspects of human work.”
— Steven Shorrock, “The Varieties of Human Work”, Humanistic Systems, 2016
An automation built from the SOP is a worker on permanent work to rule. It has no corridor, no “let me just ring him”, no sense that 2% is fine and 9% is not. Kornum puts a number on the result: build for the document and you automate about 70% of the volume and break on the other 30%. The broken 30% then creates more work than the team had before, because they fix the machine’s mistakes on top of doing their own.
I see two ways this goes wrong. The loud way: the bot meets a case the document does not cover, stops, and a person picks it up. That is irritating and visible. The quiet way: the document says “resolve the mismatch”, a person resolves it with the 2% rule, and the bot resolves it with whatever it was told. The run looks successful. The invoice is paid. Nobody knows the rule was missing until the controller asks why.
The quiet way is my reasoning from the examples, not a finding. No source I read measured how often failures are quiet, and I would want data before I put a percentage on it.
of the $200 million to $500 million in savings that process mining flagged at one large international retailer could be matched with improvement initiatives by its teams. A single unnamed company, and a case about initiatives, not about automations.
of computer time spent on order entry by around 100 sales employees at one global industrial distributor, with more than half of that time spent double-checking and correcting basic information such as pricing and availability. Found by task mining.
of orders needed manual updates by sales staff, in 1.5 million transactions across three systems at the same distributor, though many were routine orders from regular customers. Found by process mining.
is the usual gap between the written procedure and the real work in Varick Agents’ own engagements, and over 70% in exception-heavy work such as accounts payable exceptions. A vendor’s account of its own work, with no method published.
The distributor is the case I find most useful. Nobody had written “double-check the price” into a process. It showed up only because two methods looked from different sides.
The people who hold it, and why they will not simply tell you
Our manifesto says the best forward-deployed engineers you could hire already work for you. I mean that literally for this problem. The 2% rule is in the clerk’s head, and the only way to get it out is to ask her or to watch her.
Asking has a limit. Shorrock separates the work people do from the work they disclose, and calls the second partial and often biased: people tell you what feels safe to tell. A clerk who has bent a rule for six years to get invoices paid will not volunteer it to a stranger with a clipboard. People also guess badly when they estimate their own work. Our post on finding AI use cases without a survey gives that case at length.
So I trust no single source. An interview alone gets the story people are willing to tell. A log alone leaves the retailer’s three quarters unexplained. Each is blind somewhere different.
How to find them
The grid below is my reading of which method can see which kind of hidden step. The evidence for each cell is in our longer comparison of process mining, task mining and AI discovery, and the tools that record screens are compared in best task mining software in 2026.
| Event logs (process mining) | Screen recording (task mining) | Interviews | Reading the work itself | |
|---|---|---|---|---|
| A change request sent by email | none | partly | partly | fully |
| A request made by phone | none | none | fully | none |
| Spreadsheet clean-up before data goes into a system | none | fully | partly | fully |
| A rule that lives in someone’s head | none | none | fully | partly |
| A decision made in a corridor | none | none | fully | none |
| How often it happens, across every case | fully | partly | none | partly |
none partly fully · Our reading from McKinsey, Varick Agents and the pages cited in the two posts linked above, not a measurement. Full ball: the method shows it by itself. Half: it shows part of it, for example that an email was opened but not what it said. “Reading the work itself” means learning from screens, mail and documents, which is the approach Nolli takes; an interview-only tool would score lower on email and spreadsheets. No column is full.
The pattern is that nothing covers the phone call and the corridor except a person, and nothing counts every case except the logs. That is why McKinsey argues for using more than one method. Varick’s CEO described the effect on a podcast: a $5 billion software company’s process document listed seven steps to get a quote signed, and process mining on its CRM found 20 steps and seven loops. I have that from our own guide, not from the episode.
A rule I like from that guide: any step that shows up in only one source is a finding. Either the document is stale, or the log is blind, or somebody is working around something.
What I would do first
Pick one workflow with an owner
One that runs often and has a person who wants it fixed. Do not start with the workflow that demos best.
Do this todayDo this today: write down the workflow and the name of its owner.
Pull recent real cases, not the SOP
Take the last twenty or so cases of that workflow, with their emails, spreadsheets and approvals. The SOP comes later.
Do this todayDo this today: ask the owner for the last five cases that went wrong.
Lay the SOP over the cases
List the steps the document prescribes and the steps the cases show. The steps that appear in only one place are your list of hidden work.
Do this todayDo this today: draw two columns and fill in one case by hand.
Ask the person who did it why
For each hidden step, ask what it protects against. Then sort it: delete it, turn it into plain code, give it to an agent, or keep it with a person. See the four buckets.
Do this todayDo this today: ask “what would go wrong if you skipped this?” about one step.
Write the unwritten rule down, with its number
The 2% belongs in the SOP, with the name of whoever decides above it. Then run the agent beside people in shadow mode before it acts alone.
Do this todayDo this today: find one threshold nobody has written down.
Step four is where I would argue with a lot of automation plans. Some hidden steps are a patch over a broken handoff, and the right move is to remove the step, not to teach a bot to do it. Michael Hammer made that argument in Harvard Business Review in 1990, in an article whose title says to obliterate rather than automate. I know the title and not the article, which is behind a paywall.
Where the evidence is thin
There is also a case where I would skip most of this. Kornum says engineering work is bounded, checkable, structured and verifiable, which is why AI works there. If your workflow has those four properties, with a compiler or a test suite to tell you when it is wrong, the documented path is closer to the real one and the audit pays less. Most office work has none of them. Some hidden steps are also plain mistakes, and finding one does not mean it should be kept.
Where Nolli fits
Where Nolli fits, and where it does not
Nolli learns how your company works from your people’s work on company devices, the email and calendar your company connects, and the logs of the AI agents they use. Each finding shows the evidence it came from, so a hidden step can be traced to a screen, a message or a document. The limits are real. It sees only what your company lets it read, so a phone call or a corridor decision that leaves no trace on a device, in mail or in a calendar is invisible to it too. It does not give the exact counts across every case that process mining gives. Your company sets the policy on what it may learn from. See Why Nolli. No public price. Request a demo.
Request a demoQuestions people ask
What are undocumented steps in a business process?
They are steps people do that no procedure describes: a spreadsheet checked first, an email sent to a colleague because a system notification fails, an unwritten approval threshold. McKinsey’s retailer case lists change requests by email or phone, spreadsheet clean-up and delayed decisions as work that process mining did not capture.
Why do automations fail on hidden work?
They are built from the documented process, so they follow the written path. Varick Agents reports that building for the document automates about 70% of the volume and breaks on the other 30%. A bot can also finish a case wrongly without stopping, which is my reasoning and not a measured result.
How do you find hidden steps in a process?
Take recent real cases, lay the SOP over them, and ask the people who did the work why each extra step exists. Check what they say against system logs and, where the company allows it, recorded screens. A step that appears in only one source is worth a look.
Can process mining find undocumented steps?
Only the ones that leave an event in a system. McKinsey says process mining missed delay and rework driven by email, phone requests and spreadsheet manipulation outside the ERP at one large retailer, which is why it recommends combining process and task mining.
Should every hidden step be automated?
No. Some hide a broken handoff and are better removed. Ask what each step protects against, then delete it, turn it into plain code, give it to an agent or keep it with a person.
Sources
- Kar-Woon Choy, Rodrigo Chaparro Gazzo, Rohit Panikkar and Rohit Sood. “Better together: Process and task mining, a powerful AI combo.” McKinsey & Company, March 18, 2024.
- Steven Shorrock. “The Varieties of Human Work.” Humanistic Systems, December 5, 2016.
- Daniel Kornum. “If AI is so great, why isn’t it working?” Varick Agents, accessed October 19, 2026.
- Greg Isenberg, with Vasuman Moza of Varick Agents. “Become a $1M/yr FDE (Full Course).” The Startup Ideas Podcast, October 1, 2026.
- Michael Hammer. “Reengineering Work: Don’t Automate, Obliterate (cited by title only; not read).” Harvard Business Review, July–August 1990.
Plain-text copy: /blog/hidden-work-steps-that-break-automations.md