We hire people for judgment and relationships, and then we bury them in copy-paste.
That sentence describes almost every operations team I've worked with, while running my Business Development Agency. The org chart says "category manager" or "supply planner." The calendar says something else: moving data between a supplier portal and an ERP, chasing the same confirmation for the fifth time, reformatting a file a vendor sent in the "wrong" template again.
None of that is why these people were hired. All of it fills their week.
The numbers on wasted time are worse than the anecdotes
This isn't a vibe. It's measured, repeatedly — by an AI research arm, a hardware vendor's commissioned survey, and a work-management platform with its own reasons to publish this. Discount for motive if you like; the direction still doesn't move.
Read that first number again. Sixty percent — not a slow afternoon, the majority of the week — spent not doing the job people were hired for, just keeping the machinery of work fed. Asana's framing is blunt: knowledge workers lose 352 hours a year just talking about work, before a single deliverable moves. [1]
So why, after a decade of "automation," is this still true?
Automation optimised the demo, not the job
Here's the uncomfortable mechanic. Most process automation — classic RPA, no-code flow builders, the "if this then that" school — is built around the happy path: the clean, documented version of a process where every input arrives in the expected format and nothing surprising happens.
The happy path is real. It's just not most of the work.
In practice, the happy path is often a fraction of the volume. The rest — the exceptions, the reformatting, the "let me just call them" — is where the hours go, and it's exactly the part that brittle automation refuses to touch. So it flows back to a human.
Method note. The 80/20 split in the hero is an illustrative rule of thumb from operations practice, not a measured constant — the exact ratio varies by process, supplier base and market. The defensible, sourced point is narrower and still damning: a large share of operational work is exception-handling, and exception-handling is precisely what flow-based automation is worst at. Treat "80%" as a directional claim, not a citation.
Why this is a cost-structure problem, not an efficiency project
It's tempting to file this under "nice-to-have productivity." It isn't. In low-margin categories — grocery being the extreme case — the cost of running operations is the business model. If your people spend a quarter of their week on reconciliation, that cost is baked into every unit you sell.
Two things follow.
First, the prize isn't "cut headcount." It's change the mix of what people do all day. Nobody wakes up excited to reconcile a spreadsheet or chase a missing delivery note for the fifth time. Move that work off their plate and you don't just save cost — you get the judgment and the supplier relationships you were paying for in the first place.
Second, the winners here will be structurally cheaper, not marginally cheaper. And in retail, structurally cheaper usually wins.
My Take, Your Summary
What "solving the 80%" actually requires
If the failure mode of old automation is that it breaks on the first weird case, the bar for anything new is simple to state and hard to build:
It has to operate in the mess, not around it. It has to work where the process already lives — the ERP, the supplier portal, the shared spreadsheet, the inbox, and yes, sometimes the phone — without a six-month integration project first. It has to handle the exception end-to-end and escalate to a human only when judgment or a relationship genuinely matters. And it has to do all of that with an audit trail, because "the bot did something" is not an acceptable answer in a regulated, money-moving process.
That's a very different design brief from "automate the happy path." It's the difference between a macro and a colleague.
The teams that get this right won't be the ones with the prettiest process diagram. They'll be the ones who accepted that the diagram was always fiction, and built for the 80% they'd been pretending wasn't there.
I'm Ramar Ranjeet Skanda — I write about product, operations and AI from Prague. If your team is drowning in the 80%, I'd like to hear what it looks like for you.
Next in this series: Your Process Map Is Fiction — and It's Why Your Automation Failed.




Comments
0Be the first to comment.