How Klarna rewired its support operations with disciplined prompt engineering

In early 2024, Klarna announced that its AI assistant, built on OpenAI's technology, was handling the work of roughly 700 full-time customer service agents. The company reported the assistant managed 2.3 million conversations in its first month of full deployment, covering two-thirds of all customer service chats. Those figures came from Klarna directly, so they carry the caveats that apply to any vendor-adjacent disclosure. That said, the operational shift was real and visible enough that independent observers confirmed the scale of the change in workforce structure. What made this work was not the model itself. Several companies had access to the same underlying models and got far less useful results. The difference was how Klarna's teams wrote and structured their prompts.

What Klarna actually did

Klarna's engineering and operations teams spent considerable time before deployment defining exactly what the assistant was and was not supposed to do. This is the step most organizations skip or underinvest in, and it is where the prompt architecture took shape.

The first pattern they applied was tight role scoping. The system prompt did not ask the model to "help customers." It defined a specific agent personapersonaA semi-fictional, research-based representation of your ideal customer: their goals, frustrations, behaviours and decision criteria.View full definition → with explicit behavioral constraints: the assistant handles refund inquiries, payment schedule questions, and order disputes. It does not offer financial advice, discuss competitor products, or speculate about account decisions outside its data access. This kind of negative specification, stating what the model must not attempt, turns out to matter as much as the positive instructions. Models without negative constraints drift into confident-sounding answers in territory where they have no reliable information.

The second pattern was context injection at the prompt level. Every conversation started with a structured block of user-specific data pulled from Klarna's internal systems: account status, recent transaction history, active disputes. The model was not asked to remember or infer these details. They were placed directly in the prompt, formatted consistently, and given explicit labels. This is sometimes called grounded promptingpromptingPrompt engineering is the practice of designing and refining text inputs to guide large language models toward accurate, relevant, and reliable outputs.View full definition →: the model works from facts provided to it, not from general knowledge or inference.

The third pattern was output formatting instructions. Klarna specified response length ranges, required the assistant to offer a concrete next step in every reply, and prohibited hedging language like "it might be possible that" or "you may want to consider." These constraints reduced the verbal padding that LLMs tend to produce and made responses faster to read for customers who were already frustrated.

The fourth pattern was escalation triggering. Rather than letting the model decide when a situation was too complex, the prompt included explicit conditions: if the customer uses certain emotional markers, if the dispute value exceeds a threshold, if the request involves a regulatory complaint, route to a human agent immediately. This is a structured decision rule embedded in prompt logic, not a judgment call left to the model.

The results

Klarna reported a 25 percent reduction in repeat contacts for issues handled by the AI assistant, compared to equivalent human-handled contacts, and average resolution time dropped from 11 minutes to under 2 minutes. Both figures came from Klarna's own press materials, published in February 2024, and should be read as self-reported data. The company also stated the assistant achieved customer satisfactioncustomer satisfactionCustomer Satisfaction Score, a direct measure of satisfaction captured right after a specific interaction or experience, usually on a short rating scale.View full definition → scores on par with human agents, though the methodology for that comparison was not fully disclosed.

What is less disputed is the workforce impact. Klarna reduced its customer service headcount through attrition over 2023 and into 2024, and by mid-2024 the company's total headcount had dropped from around 5,000 to approximately 3,800 employees. This was not purely a function of AI deployment but it was a contributing factor the company acknowledged publicly.

The financial picture is harder to pin down precisely. Klarna attributed roughly $40 million in annual profit improvement to the AI deployment, again from its own communications. Given the headcount changes and the scale of contact volume handled, that range is plausible, but independent verification does not exist.

What transfers, and where your context differs

The four prompt patterns Klarna used are not proprietary. Any team deploying an LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → for a bounded operational task can apply them directly.

Role scoping with negative constraints works in any domain where the model might otherwise try to be helpful in ways that create risk. A legal team deploying a contract review assistant should specify not just what the model reviews but what it must never opine on (jurisdiction-specific enforceability, litigation strategy, regulatory interpretation). The boundary is what makes the output trustworthy enough to act on.

Context injection matters most when your use case involves user-specific or organization-specific data that the model has no way to know. If you are building a prompt for internal financial reporting analysis, the prompt should include the relevant data directly, structured and labeled, rather than asking the model to work from a general description of your situation.

Output formatting constraints reduce the need for human editing of model responses. If your team is using LLMs to draft client-facing communications and then spending 15 minutes cleaning up each output, the problem is usually the absence of format instructions, not the model's capability.

The escalation pattern is the one most organizations are slowest to implement. The instinct is to give the model discretion to recognize when it is out of its depth. In practice, models are not reliable at this. Hard rules in the prompt, based on identifiable conditions, perform better than leaving the judgment to the model.

Where Klarna's context differs from most: they had centralized data access, engineering resources to build the integration layer, and a single high-volume use case with consistent query types. If your deployment is more varied, the prompt patterns still apply but you will need separate prompt templates for meaningfully different task categories rather than one prompt trying to handle everything.

The principle that runs through all of it: a well-specified prompt does the cognitive work that would otherwise fall to the model's general judgment. General judgment from LLMs is inconsistent. Specified behavior is not.