AIPrompt Engineering

How Klarna turned customer service triage into a durable AI workflow

Klarna rebuilt one of its highest-volume, most repetitive operations around an AI agent rather than bolting AI onto an existing process. The decisions they made, and the ones they got wrong initially, offer a practical template for any team facing a similar problem.

By early 2024, Klarna was processing roughly 35 million customer service conversations per year. A large share of those interactions followed a narrow, predictable pattern: a customer wanted to know the status of a payment dispute, adjust a repayment plan, or get a refund initiated. Each conversation required pulling account data, applying a decision rule, and sending a structured reply. A human agent could do it, but the task was not complex judgment work. It was pattern matching at scale, repeated thousands of times a day.

The company faced a choice that many operations teams eventually reach: keep hiring to match volume, or redesign the task around a different kind of worker. Klarna chose the second option, and the execution is detailed enough to learn from.

What they did

Klarna's AI initiative was not a single product decision. It was a sequence of scoped moves, each one adding a constraint or a capability to the previous one.

The first move was definitional. Rather than asking "where can AI help?", Klarna's team identified a specific task class: tier-one customer queries where the resolution path was deterministic. If a customer asked about a refund for a specific transaction, the answer depended on account data and a policy rule, not on relationship history or discretionary judgment. That boundary mattered. It meant the AI agent could be evaluated against a clear correctness standard, which in turn made the build-test-deploy loop much shorter.

The second move was architectural. Klarna built the AI customer service agent on top of OpenAI's technology, integrating it directly into their existing customer data systems rather than running it as a parallel channel. This meant the agent had live access to transaction records and could take actions, not just answer questions. It could initiate a refund, update a repayment date, or escalate a case with full context already populated. That last point is worth dwelling on: the escalation path was designed before launch, not as an afterthought. Human agents receiving escalated cases got a structured handoff, not a transcript dump.

The third move was linguistic scope management. The agent launched in multiple markets simultaneously, handling queries in over 35 languages. Klarna's public communications (Klarna is a vendor, so their figures should be read with that caveat) stated the agent was managing the equivalent workload of approximately 700 full-time agents within its first month of operation. Independent corroboration of that precise number is difficult, but the directional claim, that the agent absorbed a very large share of tier-one volume, is consistent with what Klarna's customer satisfaction data and operational cost reporting suggested in their investor materials through 2024 and into 2025.

The governance layer

One decision Klarna made that often gets left out of the case study summaries: they kept a real-time monitoring function running alongside the agent from day one. A small team reviewed samples of interactions daily, flagged systematic errors, and fed corrections back into the prompt and policy logic. This was not optional quality assurance. It was built into the operating model as a standing function. The agent's behavior could drift, particularly when customers used phrasing that sat on the edge of the training distribution, and the monitoring team was the mechanism for catching that before it scaled into a problem.

The results

Klarna reported in early 2024, in communications addressed to investors and press (again, vendor-sourced), that the AI agent handled around 2.3 million conversations in its first month. Customer satisfaction scores on those AI-handled interactions were reported as roughly equivalent to scores on human-handled interactions of the same type. Resolution time dropped from an average of roughly 11 minutes to under 2 minutes for the ticket types the agent covered.

The cost implication followed directly from those numbers. Klarna cited a projected $40 million profit impact for 2024 from the AI customer service deployment. That figure has not been independently audited in the way that financial statements are, and it bundles several assumptions about what the counterfactual staffing cost would have been. Take it as an order-of-magnitude signal rather than a precise data point.

What is harder to dispute is the structural outcome: Klarna entered 2025 with a significantly smaller customer service headcount than it had in 2023, having reduced overall company headcount by about 22 percent between 2022 and 2024 through a combination of attrition management and the AI deployment. The operations that remained were concentrated in complex case handling and relationship management work.

What transfers

The Klarna case is genuinely instructive for teams outside fintech, provided they are honest about where the conditions differ.

The first transferable principle is the task scoping discipline. Klarna did not automate "customer service." They automated a specific task class with defined inputs, defined outputs, and a testable correctness standard. Any team building an AI workflow should be able to write a one-paragraph description of the task that specifies what data goes in, what a correct output looks like, and what the escalation condition is. If you cannot write that paragraph, the task is not ready to automate.

The second is the action-enabled design. The Klarna agent was not a Q&A bot. It could write to systems. Most first attempts at AI workflows stop at information retrieval because connecting AI to operational systems requires more engineering investment and raises more risk questions. That caution is defensible early, but read-only agents often disappoint because they push resolution work back to humans rather than completing it.

The third is the standing monitoring function. Teams routinely allocate budget to build an AI workflow and nothing to maintain it. Model behavior shifts, policy changes, customer language evolves. The monitoring function is not a launch-phase activity. At Klarna it was an ongoing operational role.

Where context differs: Klarna operates in a heavily regulated financial environment with strong data infrastructure and a large enough volume to justify the engineering cost. A professional services firm running 200 similar client intake conversations per month faces a different build-or-buy calculus. The architecture question, custom build versus a configurable platform like Intercom or Zendesk's AI layer, changes completely at that scale.

The underlying logic holds regardless of scale. Pick a task that repeats, has clear success criteria, and sits within a domain where errors are catchable. Build the monitoring in from the start. Connect the agent to systems so it can complete work rather than just describe it. Klarna's result was not an accident of technology. It was an accident of operational design applied to the right problem.

Finished reading?

Validate your read to earn XP and feed your radar.