Field note
Klarna was a sequence failure
The model did not fail. The order did. The judgment was reduced before anything had captured it, in the one function where the product's trustworthiness gets tested.
Where this comes from
Public reporting and the company's own public statements, read against the argument this site makes. This page claims no inside knowledge of the company and no private material.
Not published: Nothing withheld here, because there is nothing private in it. It is a reading of a public case, offered as a reading.
What is on the record
In 2024 an AI customer service assistant was reported to be handling a large share of the company's support conversations, doing work equivalent to hundreds of agents, and cutting resolution time from several minutes to under two. Over the same period the workforce fell substantially, largely by not refilling vacated roles.
Fewer people. Lower cost. Faster answers. The metrics were real.
In 2025 the company's chief executive acknowledged publicly that the focus on cost had produced lower quality, and that customers should always have the option to reach a person.
The lesson everyone drew, and why it is too shallow
The reading that followed was almost universal: let AI handle the routine cases and keep humans for the difficult ones.
That is true. It is also a staffing rule, and staffing rules are recoverable. If the mistake was the ratio, you change the ratio and you are fine.
The reason this case is worth more than that is that it is not recoverable in that way, and the reason it is not is the part with general application.
The order, not the split
Customer service in a financial company is not a support function in the way it is elsewhere. It is where the product's trustworthiness gets tested. The transaction has already happened, something has gone sideways, and money is involved.
The best people in that function held things worth a great deal. When a technically correct answer would nonetheless damage the relationship. When an exception was warranted and when granting one would set a bad precedent. When somebody needed a human response rather than a faster one.
None of that was written in any policy or handbook, and not through neglect. It is not the sort of thing that can be written by asking someone to write it, because it lives as a reaction to a case rather than as a rule in a head.
Which is why rehiring does not undo it. New people arrive competent and without the standards, and the standards took years to form against cases that have already happened. You can restore the ratio. You cannot restore the thing the ratio used to carry.
Why this is the default rather than an error
The uncomfortable part is that nobody did anything unusual.
Automation gets justified on measurable savings, and it gets scheduled against those savings. Capture produces no measurable saving in the quarter it happens and has no line in the business case, so it does not get scheduled, so it does not happen first.
The order is not chosen. It falls out of how the projects are funded. Which means it is the default everywhere, and any business currently automating a function it competes on is running the same sequence right now.
| Automate, then discover the loss | Capture, then automate | |
|---|---|---|
| Cost saving | Immediate | Immediate, same size |
| Quality of exception handling | Falls quietly, over months | Held |
| When you find out | After it shows up in something else | Not applicable |
| Can it be undone | No. The people and the standards are gone | Not applicable |
| Extra work required | None, which is why this is the default | Real, and it happens before the savings |
What the other order looks like
Nothing exotic, and it is not a slower project.
Before the function moves: take the people who are best at it and capture what their good calls actually turn on. Not the process, which is already documented and was never the valuable part. The exceptions. The cases where the obvious answer was wrong and why. The conditions under which a rule gets suspended.
Then automate, with that as the decision layer rather than the model's default one. The savings are the same. What changes is that the exceptional cases still get handled the way the business used to handle them, which is the thing customers were actually buying.
The uncomfortable general form
This is the part worth carrying out of the case.
Every business has one or two functions where it is genuinely better than the alternatives, and quality in those functions is almost never in the process. It is in calls that specific people make, usually without being able to explain them.
Automating there before capturing converts your advantage into the industry average, quickly, cheaply, and with excellent metrics for the first several months.
Frequently asked
What actually went wrong at Klarna?
On the public record, an AI support assistant produced large gains, headcount fell over the same period, and the company later said the focus on cost had produced lower quality and that customers should always be able to reach a person. The usual lesson drawn is that AI should handle routine issues and humans the hard ones. That is true and it is a staffing rule. The deeper error was one of order: the people carrying the judgment were reduced before anything had captured what they knew.
Why does the order matter more than the split?
Because a split can be restored and captured judgment cannot be recovered after the fact. Rehire and the new people do not arrive holding the old standards. Those were never written down anywhere, so the split is back and the thing that made the function good is not.
What judgment was being lost specifically?
In a financial company, support is where trust in the product gets tested, so the valuable calls are things like knowing when a technically correct answer will still damage the relationship, when an exception is warranted, and when someone needs a human rather than merely a faster response. None of that appears in a policy document, which is exactly why it left with the people.
Is this an argument against automating support?
No. The same automation with the same savings, run in the other order, does not produce this outcome. Capture what the best calls in the function turn on, then automate. The cost saving is the same and the thing that made the function worth having survives.
Why is this a general lesson rather than one company's mistake?
Because the ordering error is the default. Automation projects are justified on measurable savings and scheduled against them. Capture has no line in that business case, so it does not get scheduled, so it does not happen first. Nothing about that is specific to one company.
Where this sits
The rule that prevents this is at what should a founder automate first. Why the documentation that already existed did not hold the judgment is at an Imprint vs an SOP. The category is defined at what Imprinted AI is.
Related
- What should a founder automate first? The rule that prevents this, and how to sort for it.
- Can AI replace a founder's judgment? The same mechanism running slowly inside a smaller business.
- An Imprint vs an SOP. Why the documentation that existed did not hold the judgment.
- Tacit knowledge in business. Why the good calls were not in any handbook to begin with.
Keep going
The general form at the bottom of this page is the one worth sitting with: the function you are proudest of is the one where automating first costs the most.
The full case is The A.I. Business Manifesto. About 23,000 words, free to read on the page, no gate in front of it. If you would rather have the short version, the same page will send you the three fixes and the PDF.
Read The A.I. Business Manifesto
Free either way. Reading it costs nothing and asks nothing.
Last updated: 28 July 2026