The Kano Model Explained With Customer Experience Examples

Ask a frequent flyer what made their last trip memorable, and they won't mention that the seatbelt worked. They'll talk about the lounge upgrade, the gate agent who remembered their name, the extra legroom that showed up unannounced. Nobody praises a product for doing what it was always supposed to do. That asymmetry — the fact that some features only prevent anger while others create delight, and the two are never interchangeable — is the entire argument behind the Kano model, and it is the reason most CX roadmaps are built on a false premise: that every improvement moves satisfaction by roughly the same amount.

It doesn't. The Kano model proves that customer satisfaction is not a single dial you turn up with more features or faster service. It is governed by category, not effort — and knowing which category a feature sits in is the difference between a roadmap that delights and one that simply keeps the lights on.

What is the Kano model?

The Kano model is a framework for classifying product and service features by how they actually affect customer satisfaction, rather than by how much they cost to build. It sorts features into five categories — Basic (Must-Be), Performance (One-Dimensional), Attractive (Delighters), Indifferent, and Reverse — based on the relationship between how well a feature is executed and how satisfied the customer becomes. The core insight is that this relationship is rarely a straight line: some features only remove dissatisfaction when present, others scale satisfaction in direct proportion to how well they're delivered, and a few create satisfaction wildly out of proportion to their cost — until the market catches up and they stop being special at all.

That last clause is the part most explainers skip, and it's the part that matters most to anyone running a CX function today: Kano categories are not fixed. They decay. Understanding the decay curve — not just the taxonomy — is what separates a team that uses Kano as a one-off workshop exercise from one that uses it as a living input to journey design.

Where did the Kano model come from?

The model was developed by Dr. Noriaki Kano together with Nobuhiko Seraku, Fumio Takahashi and Shin-ichi Tsuji, who published their framework on attractive and must-be quality in Japan in 1984. It emerged from quality management and manufacturing, not from marketing or customer experience — Kano's original concern was how to classify product attributes for engineering prioritisation, using paired "functional" and "dysfunctional" survey questions to map customer reaction curves rather than relying on simple satisfaction ratings.

That manufacturing origin is worth sitting with. Kano wasn't trying to make customers happy in the abstract; he was trying to stop quality teams from spending equal engineering effort on every feature, as if a seatbelt and a sunroof earned the same gratitude. Four decades later, the same discipline applies directly to service design, digital product teams and CX roadmaps — contexts Kano never worked in, but whose core problem (finite investment, infinite feature requests) hasn't changed at all.

What are the five Kano categories, and what do they look like in CX?

Each category describes a different shape of relationship between feature quality and customer satisfaction. Here is what each looks like translated into service and digital experience, not factory output:

• Basic (Must-Be) attributes: Their presence doesn't earn praise, but their absence causes real anger. A banking app that logs you out mid-transfer, an airline that loses your baggage, a hospital intake form that asks for the same information three times — none of these, done correctly, generate loyalty. Done badly, they generate complaints, churn, and one-star reviews.
• Performance (One-Dimensional) attributes: Satisfaction rises in direct proportion to execution. Call centre wait time is the textbook example — the shorter the wait, the happier the customer, in a near-linear relationship. Delivery speed in e-commerce behaves the same way: two-day shipping is good, same-day is better, and customers notice every increment in between.
• Attractive (Delighter) attributes: Unexpected, and disproportionately rewarded when present — but their absence isn't punished, because nobody expected them anyway. A hotel that upgrades a guest's room with no explanation, a retailer that includes a handwritten note, a car-rental agency that has the vehicle already running and the seat adjusted to the driver's profile on pickup.
• Indifferent attributes: The customer genuinely does not care, regardless of how well or badly they're executed. Many back-end technical features fall here — the customer has no opinion on which cloud provider hosts the app, as long as it loads.
• Reverse attributes: The rare case where more of a feature actively reduces satisfaction for a meaningful segment. Aggressive in-app upsell prompts, excessive personalisation that feels surveilled rather than helpful, or a loyalty programme with so many tiers and rules that it reads as a maze rather than a reward — all can swing from intended delight to active irritation.

Most CX teams intuitively grasp Basic and Performance attributes, because they're visible in every complaint log and every NPS verbatim. Where the model earns its keep is in forcing explicit attention onto Attractive and Reverse attributes — the two categories that never show up in a standard satisfaction survey, because customers can't ask for something they don't know is possible, and rarely flag a feature as actively annoying until it's already cost you the relationship.

Why do today's delighters become tomorrow's basics?

This is the mechanism most Kano explainers underplay, and it's where behavioural economics does real work. Free Wi-Fi on a flight was once a genuine delighter — a few airlines offered it, most didn't, and passengers who got it felt they'd won something. It is now, for most long-haul travellers, a baseline expectation; its absence generates complaints, and its presence generates nothing but relief. Mobile cheque deposit followed the identical arc in retail banking: delighter in the mid-2010s, baseline by the early 2020s.

The behavioural driver here is best understood through the lens of the affect heuristic and expectation-based judgement: customers don't rate experiences against some fixed objective standard, they rate them against what they've come to expect — and expectations ratchet upward the moment a delighter becomes common knowledge in a category. Once one bank offers instant transfers, every bank is judged against instant transfers, whether or not they can deliver them. The feature hasn't changed. The reference point has.

This is also where loss aversion (Kahneman and Tversky's finding that losses are felt roughly twice as intensely as equivalent gains) explains why the migration only runs one direction. Once a delighter becomes an expectation, withdrawing it doesn't just return the customer to neutral — it registers as a loss, and it is punished accordingly. An airline that quietly removes free Wi-Fi after two years of offering it won't return to "indifferent." It will generate genuine anger, because the customer has already mentally priced the feature into what they're owed. That one-way ratchet is why a Kano classification done once, at launch, and never revisited, is already out of date by the time the feature ships.

The practical consequence for anyone running a CX function: a feature roadmap built entirely on yesterday's delighters is a roadmap that is quietly decaying into a basic-attribute maintenance list. The organisations that keep generating delight are the ones re-running the classification, not the ones that found one good idea and kept polishing it.

How do you actually run a Kano survey?

Kano's original method is more rigorous than most teams realise, and skipping the structure is the single most common reason Kano workshops produce vague, unusable output. The method relies on asking two questions for every candidate feature — one functional, one dysfunctional — and cross-referencing the answers against a standard evaluation table.

1. Select a tight list of candidate features or moments. Pull these from voice-of-customer data, support tickets, and journey friction points — not from a brainstorm. Kano works on real candidate attributes, not hypothetical wish-list items nobody has asked for.
2. Write a functional and a dysfunctional question for each feature. The functional version asks how the respondent would feel if the feature were present ("How do you feel if your delivery arrives same-day?"). The dysfunctional version asks the mirror question ("How do you feel if your delivery does not arrive same-day?"). Each uses the same five-point response scale: I like it, I expect it, I am neutral, I can tolerate it, I dislike it.
3. Cross-reference the paired answers against the Kano evaluation table. The combination of functional and dysfunctional responses — not either question alone — determines whether the feature lands as Basic, Performance, Attractive, Indifferent, Reverse, or Questionable (a contradictory pairing that signals the question itself needs rewording).
4. Segment the results before you trust them. Classification varies by customer segment and by market maturity — what is attractive to a first-time customer is frequently basic to a loyal one. Running the analysis on an aggregated, unsegmented sample hides exactly the divergence you're trying to find.
5. Weight the output against cost and strategic intent, not satisfaction score alone. A delighter that costs ten times more than a performance improvement with similar satisfaction lift is not automatically the better investment. Kano tells you the shape of the reward curve; it doesn't tell you the shape of the cost curve, and the two have to be read together.
6. Re-run the exercise on a cycle, not as a one-off. Given the migration pattern from delighter to basic described above, a Kano classification has a shelf life. Annually, or whenever a competitor launches a feature that shifts category expectations, is a reasonable cadence for categories that move fast — digital banking, telecom, e-commerce.

Teams without the appetite for a full paired-question survey often run a lighter version informally in journey workshops, sorting touchpoints into the five buckets based on frontline insight and complaint data. It's faster, and it's useful for early triage — but it substitutes expert judgement for customer evidence, and that's a real trade-off worth naming rather than hiding.

What are the common mistakes teams make with the Kano model?

The framework is simple to explain and surprisingly easy to misuse. The failures tend to cluster around a few recurring patterns:

• Treating classification as permanent. As covered above, delighters decay into basics. A Kano matrix built three years ago and never updated is actively misleading the roadmap it's meant to inform.
• Confusing "indifferent" with "unimportant." A feature customers don't notice can still be operationally critical — fraud detection, data security, regulatory compliance. Kano measures satisfaction impact, not business necessity, and conflating the two leads teams to deprioritise genuinely essential infrastructure.
• Surveying your loyal base only. Existing customers have already adapted to your current feature set; their basics are often a new customer's delighters, and vice versa. A classification built entirely on retained customers systematically undercounts acquisition-stage attractors.
• Ignoring the Reverse category. Teams love finding delighters and hate finding reverse attributes, so they under-invest in asking the dysfunctional question properly — the exact question that surfaces features actively working against satisfaction, like over-aggressive personalisation or a rewards programme too complex to use.
• Using Kano in isolation from the full journey. A feature's Kano category can only be interpreted against the moment in the journey where it sits. A delighter at the point of first use (a free welcome gift) behaves very differently from the same gesture repeated at every renewal, where it risks becoming an expected, and therefore merely basic, entitlement.

How does the Kano model connect to journey mapping and CX governance?

Kano answers a narrow but vital question — which features matter, and how much — but it was never designed to tell you where those features sit in the customer's lived experience, or which moments carry disproportionate weight in how the whole relationship gets remembered. That's the job of journey mapping, and specifically of identifying genuine Moments of Truth: the small number of touchpoints that silently govern the overall verdict a customer reaches, regardless of how every other step went.

This is where Daniel Kahneman's peak-end rule earns its place alongside Kano in any serious CX practice: customers judge an entire experience largely by its most intense point and its ending, not by the average of every touchpoint along the way. A Kano-identified delighter placed at a forgettable mid-journey step is a wasted investment compared with the same delighter placed at the peak or the close. Teams that run Kano analysis and journey mapping as separate, disconnected exercises routinely discover delighters they built in the wrong place — technically present, emotionally invisible.

The two frameworks are complementary, not competing: Kano tells you which feature deserves investment; the journey map tells you where in the sequence that investment pays off. Organisations serious about closing that loop typically run a structured CX maturity assessment first, to establish whether the basics are actually secure before chasing delighters — a sequencing problem that shows up constantly in practice. Kano's own hierarchy implies it: there is no credit for a delighter sitting on top of broken basics.

For a concrete illustration of how a mapped set of touchpoints exposes where basics are failing and where delight could be built, the stage-by-stage breakdown in this Hertz customer journey analysis shows the same logic applied to a real rental sequence. And for a case where a brand deliberately resisted adding features that looked attractive on paper, In-N-Out's rejection of a loyalty programme is a useful counter-example: sometimes the disciplined move is recognising that a feature customers say they want tests out as indifferent, or even reverse, against the brand's actual promise.

Using Kano without losing the plot

The quiet danger of the Kano model is treating it as a one-time audit rather than a standing discipline. Markets move, competitors copy, and every attractive feature carries a built-in expiry date the moment it stops being rare. The organisations getting genuine value from Kano are running it as a recurring input — tied to behavioural analysis of why categories shift, embedded in CX strategy rather than parked in a quality-assurance deck, and revisited on a cycle that matches how fast their category actually moves.

The companies worth studying aren't the ones who found one great delighter. They're the ones who noticed it decaying into a basic, and had the next one already in build. That's not a one-off workshop output — it's an operating rhythm. Build the rhythm, and the Kano model stops being a classification exercise and starts being a genuine early-warning system for where your experience is about to go flat.