A customer will never thank you for brakes that work. They'll leave forever if the brakes don't. That's a different kind of want from a nicer stereo.
What it is
Noriaki Kano, a Japanese quality professor, published the model in 1984. It sorts customer needs into categories by how satisfaction responds when you deliver them:
| Category | If missing | If delivered | Example |
|---|---|---|---|
| Must-be | Very unhappy | Not noticed | Brakes work. The report is accurate |
| Performance | Less happy | More happy, the more you deliver | Faster delivery. Shorter report |
| Attractive (delighter) | Not missed | Pleasantly surprised | The report flags a problem before you asked |
| Indifferent | Don't care | Don't care | The report's font |
| Reverse | Happier without it | Annoyed by it | A chatty intro paragraph |
Over time, delighters become expected. Yesterday's surprise becomes today's must-be.
Why it matters
Teams spend effort on the wrong things. They polish delighters while a must-be is failing. Or they keep adding performance features nobody asked for. Kano makes you sort before you spend.
Why people skipped it
The formal method uses a paired questionnaire for each feature: "How would you feel if it had this?" and "How would you feel if it didn't?" Then you tabulate the answers. It takes a survey, responses and analysis. Most teams guess instead.
How a bot does it
Two ways, depending on what you have.
From existing data (fast):
- Give the bot complaints, reviews, support tickets and sales notes.
- Have it list the features and needs mentioned.
- Have it propose a category for each, with evidence. Complaints about something missing often point to must-be. Praise for something unexpected often points to attractive.
- A person checks the categories.
With a real survey (better):
- Have the bot write the paired Kano questions for each feature.
- Send the survey. People answer.
- Have the bot tabulate the answers using the standard Kano table.
The bot brief
Draft a Kano classification.
Inputs: [complaints, reviews, tickets, notes]. Feature list: [optional].
For each need or feature: propose a category (Must-be, Performance, Attractive,
Indifferent, Reverse), with 1-3 quoted pieces of evidence from the inputs.
If the evidence is thin, mark CATEGORY UNCERTAIN.
Then: list any Must-be that complaints suggest we are failing today.
Optional: write the paired Kano survey questions (functional and dysfunctional)
for the 10 features with the most uncertain categories.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
For a bot that drafts customer replies:
| Need | Category | Evidence |
|---|---|---|
| Correct order number | Must-be | 6 complaints when wrong, never praised when right |
| Reply speed | Performance | "Faster is better" in 4 reviews |
| Mentions the customer's last order unprompted | Attractive | 2 customers praised it |
| Long sign-off with company slogan | Reverse | "Too much fluff," 3 tickets |
Decision: fix the order-number check before anything else. It's a must-be that's failing. Drop the slogan.
Where bots differ
Kano categories come from how real people feel. A bot reading thin data can only guess at those feelings. With a handful of complaints, treat its categories as hypotheses. With a real survey, the bot does the tedious tabulation, and the answers come from people.
What this means for you
- Sort needs before deciding what to improve.
- Fix failing must-bes first.
- Have a bot draft the sort from what you already have.
- Run the real survey when the decision is big.