← All case studies
Case study · Klarna

Making an AI assistant actually sound like Klarna

Klarna's AI assistant could resolve a query in seconds — and still leave the customer angrier than before. Content design's job was to figure out what "good" generated output even meant, then build the system that got the model there, every time.

Company
Klarna
Role
Head of UX Content Design
Focus
AI content design
Based in
London, UK
2 min
average resolution time, down from 11
25%
drop in customers repeating their inquiry
~$40M
estimated savings in the first year

The situation

Klarna's AI assistant was fast — it just wasn't always good. Before it existed, the numbers told their own story: an average of 11 minutes to reach a conclusion, over 40% of customers repeating their inquiry because the first answer didn't land, and documentation that was, in the team's own words, disastrous. It was also expensive to run. And when the assistant's tone missed, customers noticed immediately.

A one-star Klarna app review titled Was an awesome app in the past, describing a frustrating experience with automated purchasing power being reset to zero, with the customer saying they'll move to other platforms like Afterpay or PayPal.
The stakes — a real one-star review. Bad support doesn't just fail to help; it actively pushes people toward competitors.

One customer summed up the emotional cost more bluntly, complaining that they'd contacted support about terrible assistance "only after I spent 4 hours screaming into a pillow." The brief was clear: how might AI help get users the answers they need in less time — without generating that reaction?

Defining our role

Our role was to figure out what "good" generated output actually looked like, and how to get a language model to reach it consistently. Our goal was simple to state and hard to deliver: get users the answers they need as quickly as possible, in a voice that still sounded like Klarna.

Early attempts made the size of the problem obvious. A first-pass persona prompt described the assistant as "bubbly, kind, and like a friend they turn to because they trust it." One internal reviewer's verdict: "It's clearly a robot, and it's cringey that it wants to be my friend." The MVP's actual output wasn't much better — technically accurate, but written like a policy document read aloud: "We're not able to help, I'm so sorry! It's because while we manage your payment schedule, the order is fulfilled directly by the merchant…"

AI doesn't understand tone the way we do

The obvious first move — just describe the tone you want in the prompt — turned out to be nowhere near enough on its own.

A ChatGPT screenshot where a prompt asks to rewrite a payment-options message to sound curiously bold, offbeat but optimistic, and strikingly relevant. The output uses phrases like not every order gets the green light and that's by design.
A reasonable-sounding prompt, an over-the-top result — "curiously bold, offbeat but optimistic" produced copy that tried too hard. Adjectives in a prompt don't reliably become tone in the output.

We built a systematic way to close that gap instead: reverse-engineering our own prompts by asking the model to describe the tone of sample outputs, then comparing that description against what we'd actually intended. Where they didn't match, we had a concrete, specific instruction to add — not a vaguer adjective, but a rule like "do not use contractions" or "start every sentence with the subject and verb."

A tone system titled Friendly, clear, confident, Always on, organised into three goals — Delight, Motivate, Reassure — each broken into two named tones (Intriguing, Playful, Empowering, Active, Helpful, Reassuring) with concrete writing rules for each.
The tone system — six named tones, each with concrete, testable rules — "use modal verbs like 'can'," "do not use the passive voice" — not adjectives a model could interpret however it liked.
The habit that made it repeatableEvery observed problem got logged the same way: what we saw, what the model produced, what we actually wanted, and the specific prompt change that would close the gap. That log became the working document the whole content team iterated from.
A four-column table: Observation, Control output, Desired output, Changes need to be made. Rows cover hyperbolic adjectives, jargon, reading level mismatches, and clunky transitions, each with concrete before-and-after examples.
Turning complaints into instructions — "usage of hyperbolic adjectives" isn't actionable on its own. "Remove and rewrite terms like 'unique' from the retrieved policies" is.

The sample bank: teaching tone by example

Rules got us most of the way, but rules alone produce copy that is correct and lifeless. The other half of the system was a library of pre-written messages showing what good sounded like across the emotional situations customers actually arrive in — because a model, like a new writer, learns tone far faster from examples than from description.

Each sample was tagged to a point on the tone spectrum we'd already built for the wider product, so the assistant's voice wasn't a separate invention. The spectrum told us which tone the situation called for; the sample showed the model what that tone looked like in a sentence.

Customer situationTone called forWhat good sounds like
Angry — third time asking Trustworthy "You've asked about this three times and haven't had a straight answer. Here's what's actually happening with your refund, and what I can do right now."
Anxious — money is tight Reassuring "Your payment is due on 14 March. If that's difficult, you can move it back by 14 days without a fee. Nothing happens to your account in the meantime."
Confused — doesn't know the terminology Educational "A pre-authorisation isn't a charge. It's the shop checking the money is there. It disappears from your balance within 7 days."
In a hurry — standing at a checkout Informative "Your card ending 4471 has expired. Add a new card and the order goes through."
Suspects fraud — frightened Trustworthy "I've paused the payment while we check this. No money will leave your account. Tell me whether you recognise the £84.00 order from ASOS on 2 March."
Embarrassed — missed a payment Encouraging "It happens. Your payment is 3 days late and there's no fee yet. Pay it today and nothing else changes."
Delighted — everything worked Playful "All sorted, and your last payment is done. Nothing left to pay on this one."
Being told no Familiar (neutral) "I can't change the delivery address once the order is placed. The shop can, though — here's how to reach them."

Illustrative examples in the style of the sample library — representative of the patterns, not the live production strings.

What the bank was really teaching

Read them together and the pattern is more interesting than any individual line. Almost every sample leads with the fact and follows with the feeling, which is the opposite of what an unguided model does — left alone it opens with an apology, then buries the answer. Several also do something a rule could never specify: they name the customer's emotional state without performing sympathy about it. "You've asked about this three times" acknowledges the frustration by demonstrating that we noticed, not by saying sorry a fourth time.

That's the argument for a sample bank over a longer rulebook. You can write "be empathetic without being obsequious" in a prompt and get nothing usable. Show eight examples of it and the model reproduces the pattern — and so, usefully, does the next content designer who joins the team.

Building it to last

None of this was meant to live in one person's head. We consolidated the work into a single system prompt shared across every assistant, AI-friendly tone and voice guidelines written specifically for how language models actually parse instructions, and a large library of pre-written text samples and prompts the wider team could pull from directly, so good output didn't depend on one expert being in the room.

Principles for writing tone into a model

What I learned making a language model sound like a specific company, rather than like a language model being told to sound like one.

Principle 01

Adjectives are not instructions

The single most expensive lesson. "Bubbly, kind, and like a friend they turn to" produced an assistant one reviewer described as clearly a robot, and cringey for wanting to be their friend. Descriptive tone words give a model latitude, and latitude is exactly what you don't want.

✗ Interpretable
"Be warm, curiously bold, offbeat but optimistic."
Produces copy that tries too hard, differently each time.
✓ Testable
"Do not use contractions. Start every sentence with the subject and verb. Use modal verbs like 'can'. Do not use the passive voice."
Each rule is checkable against any output, by anyone.
Principle 02

Reverse-engineer the gap instead of guessing at it

When output missed, we asked the model to describe the tone of its own sample output, then compared that description against what we'd actually intended. The delta between the two is where your missing instruction lives — and it hands you a specific rule to add rather than a vaguer adjective to try.

Principle 03

Log every failure in the same shape

Every observed problem got recorded identically: what we saw, what the model produced, what we actually wanted, and the specific prompt change that would close the gap. That log became the working document the whole content team iterated from — and it's what turned individual observations into a system rather than a pile of anecdotes.

The translation this forces "Usage of hyperbolic adjectives" isn't actionable. "Remove and rewrite terms like 'unique' from the retrieved policies" is. The log's format makes you do that conversion every single time.
Principle 04

Write guidelines for how models parse, not how humans read

This also became the place where accessibility rules had to be re-expressed. A human style guide can say "write clearly and keep it comprehensible." A model needs that as a constraint it can satisfy — a target reading level, a ban on idiom, a rule about front-loading the answer — otherwise "clear" is just another adjective. The accessibility standard didn't change; the way it had to be written down did.

Our existing style guide was written for content designers. A model doesn't read a 35,000-word document and absorb a house style — it needs rules stated as constraints, positioned where they'll be weighted, without the hedging and context a human reader needs. AI-friendly voice and tone guidelines are a genuinely different artefact from the human ones, and treating them as the same file is why most attempts fail.

Principle 05

Speed only counts if the answer lands

An assistant that resolves in seconds and leaves the customer repeating themselves hasn't saved anyone time — it's moved the cost somewhere it isn't measured. The metric that mattered most wasn't resolution time; it was the 25% drop in customers repeating their inquiry. The AI didn't get smarter on its own. The content system around it got rigorous enough for the speed to mean something.

Principle 06

Build it so it doesn't live in one person's head

A single consolidated system prompt shared across every assistant, guidelines written for how models actually parse instructions, and a library of pre-written samples and prompts the wider team could pull from directly. If good output depends on one expert being available, you have a bottleneck, not a system.

The sample bank turned out to be the most durable artefact of the lot. Rules decay as the product changes; examples of good tone in a hard moment stay useful, and they onboard humans as effectively as they steer models.

The outcome

Across all of Klarna's AI assistants, monthly conversation volume grew past 3 million, while quality moved in the direction that mattered: a 25% drop in customers repeating their inquiry, average resolution time down from 11 minutes to 2, the number of chats needing a human agent cut to a third of where it started, and an estimated $40 million saved in the first year alone. The AI didn't get smarter on its own — the content system around it got rigorous enough for the AI's speed to actually mean something.

"The model didn't need a better personality. It needed rules specific enough that 'friendly' meant the same thing every single time."