Customer exit interviews: how to talk to people who cancelled
Customer exit interviews find the reason behind 'too expensive'. When to reach people who cancelled, how to invite them and how to turn answers into fixes.
Why a user research repository goes unused after launch, and six habits that bring product teams back to check it before new research.

"Has anyone already asked customers about the new airport pickup?" a product manager asks you. You're on the research team at a car rental company. You remember a study last spring, but the shared folder shows nothing called "pickup". So do you run it again?
That shared folder is your user research repository, the place where a company keeps what it learned from customers.
It goes quiet for a few fixable reasons. Nobody owns it, findings lose the quote behind them, and nobody checks it before new research starts. Each reason has one habit that fixes it.
So which habit does your repository need first? Start with the one that matches what you saw when "pickup" came up empty.
Research repositories go quiet for plain reasons. Nobody owns them, or adding to them is too much work. In a Nielsen Norman Group survey of over 400 UX and research operations professionals, only 9% reported mature and thriving research repositories. And 11% said theirs had stalled or been forgotten.
Research operations people run the tools and rules a research team uses. In the same survey, published in July 2024, almost a fifth (19%) of respondents felt their research repository had poor adoption. That means people at their company were not using it.
Age seems to matter too. Almost 80% of respondents had a repository younger than 3 years old, with over 60% of those less than a year old. In the same survey, 65% of respondents with a repository older than 3 years reported good adoption. The figure was 37% for repositories of 1 to 3 years, and 34% for those less than a year old.
The survey shows a pattern, not a cause. Teams with older repositories were more likely to say people used them. So the first year may be when the habits around it form or fade.
You can match what you see today to the habit that fixes it.
| What you see | Reason | Habit that fixes it |
|---|---|---|
| Old folders pile up | Nobody owns it | One owner reviews entries weekly |
| People doubt findings | No quote behind them | Link each finding to its quote |
| Search misses the deck | Finished decks only | One searchable sentence per finding |
| Studies start unchecked | Nobody looks first | Ask "what do we already know?" |
| Product teams search and miss | Tags use research words | Tag in customer words |
| Only researchers open it | Outside daily work | Bring findings to meetings |

A repository goes quiet first when nobody is in charge of it, then when people stop believing what's in it. A folder nobody tidies gets harder to search, and a finding with no evidence is easy to ignore. Nielsen Norman Group names "no one owns the repository" as one reason they fail.
Say five teams at the car rental company each added their own folders last year. Nobody removed anything, so the pickup study now sits beside three old drafts of itself.
The habit is to name one owner. That's a person, not a group, who reviews new entries each week and archives anything out of date. One person matters because a shared space with no owner fills up. Each new study then makes search a little worse.
You'll know it works when new entries follow the same format without anyone asking.
Suppose the pickup study's summary says "customers get lost at pickup". A product manager who disagrees can't see who said it, or what they said. So they have nothing to check, and they move on.
The habit is to link every finding to at least one participant quote and the interview it came from. A verbatim quote is the participant's exact words. It lets a doubter check a finding in a minute. The same check works for themes, as the guide to auditing interview themes back to the exact quote shows.
You'll know it works when people forward a finding with its quote attached.
People skip a repository when a search finds nothing useful. Asking a colleague, or running a new study, feels faster. Two habits fix that. One makes each finding easy to search. The other puts the repository at the start of every research request, so checking it becomes part of the job.
Suppose last spring's pickup study is a long slide deck called "Q2 final v3". Search can see the file name, but not the finding on slide twelve.
The habit is to store each finding as one short sentence. Give it a date, the study it came from and its quote, and attach the deck to it. You'll know it works when a search for "pickup" returns the finding itself.
The product manager was about to request a new study, and nothing in the process asked them to look first.
The habit is to make "what do we already know?" the first line of every research request and every user research plan. Whoever writes the request answers it from the repository, with links. A repeated study spends weeks and money to learn what the company already paid to learn.
You'll know it works when new requests cite earlier findings, and some requests end there because the answer already exists.

Even a tidy one goes unused if it uses the research team's words and sits in a tool only researchers open. People outside research search with their own words and work in their own meetings. So the last two habits bring each finding to them, in words they already use.
Say the pickup study is tagged "phase 3 issue B". The product manager searched for "airport" and "keys", so nothing came up.
The habit is to tag each finding with the product area, the customer group and the words customers used. A few times a year, check the tag list with two people from outside research who use it.
You'll know it works when people outside research find what they need without help.
Suppose it lives in a tool that only researchers open. The product team plans in other meetings, so the findings never reach the room where pickup gets decided.
The habit is to bring two or three findings, each with its quote, to the meetings where product decisions get made. Link back to the repository each time, so people learn where the findings live.
You'll know it works when requests start with "I saw in the repository that pickup customers said".
If you can start only one habit this month, start with the owner, because the other five habits need someone to keep them going.
A year from now, the product manager's question about airport pickup should take one search. It returns the finding, the quote and the interview, and nobody books a study to learn the same thing twice.
The quote and search habits are easier to keep when the research platform does part of the work. Pulse keeps every study's themes, quotes and transcripts together in the insight repository, beside earlier studies. You can search it, so a team can check what customers already said before running something new.
Pulse also groups what participants said into themes, and every quote links to the transcript it came from. That's habit 2, built into each study. Findings are queryable across projects too, so a team can ask what earlier studies heard about pickup before it books another one.
The owner, the tags and the meetings stay with your team, and that's where a researcher's time pays off most. To see a study and its findings in one place, book a demo.
A research repository is a shared place where a company stores what it learned from research, so people can find it later. It holds findings, quotes, recordings and reports. A user research repository holds the studies a company ran with its own customers. The glossary covers what a research repository is in more depth.
You need one when more than one team runs research, or when research outlasts the people who ran it. Without one, findings live in personal folders and inboxes, so the company can pay to learn the same thing twice.
Start broad, from a customer group or a product area, and browse its most recent findings. Then follow the words customers used in those quotes, because they often point to other findings with different tags. If browsing feels slow, ask the repository owner, who usually knows where things sit.