Klarna is an interesting AI story partly because the AI worked.
When the company launched its AI customer-service assistant in 2024, the early numbers were extraordinary. After its first month, Klarna said the assistant was handling two-thirds of customer-service chats and doing work equivalent to 700 full-time agents. Average resolution time had fallen from 11 minutes to under two, repeat inquiries were down 25%, customer satisfaction was on par with human agents, and Klarna estimated the assistant would improve profits by $40 million in 2024.
A year later, something seemingly contradictory happened. Klarna began emphasizing humans again. CEO Sebastian Siemiatkowski acknowledged that the company’s aggressive focus on AI and cost reduction had affected service quality. The company began hiring again and put renewed emphasis on service quality and the role of people alongside AI.
It would be easy to tell this as another story about AI being overhyped, except Klarna didn’t abandon AI.
The more interesting question isn’t whether Klarna’s AI worked. It’s what happens to the human job when it does.
If machines handle a large share of straightforward customer interactions, the people who remain aren’t simply doing less customer service. They’re increasingly handling the things the automated system didn’t resolve, the things customers still want a person for, and the situations where something about the normal path didn’t work.
Klarna shows the first part of that pattern. The rest is what I’ve been trying to understand through this series. When machines disproportionately remove routine work, the averages can start lying to us about the work people actually do. As more human work consists of things that don’t fit the standard process, the side door can start becoming the whole building. When those decisions require more judgment, the dollar threshold starts looking increasingly crude because risk isn’t static. And when routine work was also how inexperienced people became experienced, the work was doing two jobs.
I’ve been treating those as different problems. I’m no longer sure they are.
The normal case wasn’t just most of the work. It was the organizing assumption of the company.
Think about how most organizations are built. Processes exist because enough situations repeat that we can decide in advance what should happen next. Jobs exist because enough tasks can sensibly be bundled together. Averages are useful because they tell us something about what people actually do. Approval limits work because fairly simple rules are good enough for a large number of reasonably predictable decisions. People get better partly because they do enough ordinary work before they’re asked to handle the difficult stuff. Even a cumbersome exception process makes sense when exceptions are actually exceptions.
The normal case made all of that possible, which is why I keep coming back to the argument behind Migrating Scarcity. When technology makes something abundant, scarcity doesn’t disappear. It moves to whatever the newly abundant capability still depends on.
There is something I didn’t take far enough in the book. What if the thing becoming abundant isn’t just a resource the organization uses? What if it’s the kind of work the organization was built around?
Much of the work companies are automating first has something important in common. It is structured enough, frequent enough or predictable enough to hand to a machine with confidence. Those are also many of the characteristics that made the work possible to standardize in the first place.
As more of that work moves to machines, what reaches people starts to look different. More of it involves ambiguity or disagreement. Facts don’t line up neatly. Objectives conflict. The policy covers most of the situation but not quite all of it.
And those aren’t just differences in difficulty. They put pressure on how work is measured, where decisions get made, when something gets escalated and how people learn to exercise judgment.
That raises a question I hadn’t really considered before writing these essays. If you were designing an organization mainly to handle that work, would you design the organization we have today?
I doubt it.
Take a different, hypothetical company. It automates 70% of a process. Unit costs fall, response times improve, customers get answers faster, and the business case delivers exactly what management promised. The automation was successful.
But the remaining 30% may now need different skills, different measures of productivity and more room for judgment. Escalation paths designed for occasional exceptions may start carrying much more of the human workload. Authority may still be calibrated to the old mix of work. And the company may eventually discover that some of the routine work it removed was also helping develop the people it now needs most.
The company solved the problem it set out to solve, but in doing so it exposed the next one. That’s the part that connects back to Migrating Scarcity. Removing a constraint and capturing the value released by removing it are not the same thing. If the constraint moves, eventually the organization has to move with it.
I think this may explain some of the frustration we’ll see as AI deployments mature. Automation rates will rise and unit costs will fall. Individual AI projects will show perfectly respectable returns. Yet executives may still wonder why the organization isn’t becoming as fast, adaptive or productive as the technology seemed to promise. The natural reaction will be to ask what else can be automated, and sometimes that will be exactly the right question.
But sometimes the AI will already have done its job. It will have removed enough of the normal work to expose something we hadn’t thought much about: much of the organization was built on the assumption that people would still be doing that work.
At that point, another model isn’t necessarily the answer.
The organization has to move with the scarcity.
For more than a century, one of management’s great achievements was learning how to make ordinary work repeatable enough to scale. We broke jobs into pieces, standardized processes and built organizations capable of handling enormous amounts of recurring activity efficiently.
AI may turn out to be extraordinarily good at precisely the work we became extraordinarily good at organizing. That doesn’t make the organization unnecessary. It changes what we need the organization to be good at.
We designed the organization around the normal case and built special machinery at its edges for everything that didn’t fit. AI may be taking the normal case first.
What happens when the edges are increasingly where the organization lives?
And Vijay Says... 