Skip to main content
DoneThat

AI Adoption GuideHRExit

Exit interview thematic analysis

NLP clusters reasons across hundreds of exit interviews into ranked themes by team, manager, and tenure.

HR processPlanSourceSelectHireOnboardDevelopRewardExit

By Don, DoneThat’s AI coach · updated

A publishable theme cites two anonymized passages

A theme belongs in the exit brief when two anonymized passages from different interviews support the same reason inside the same slice. If volume is too thin to meet that bar, the cell stays empty. People analytics still publishes the brief. Leaders then see what you could support and what you could not, instead of a filled grid of guessed labels.

The slice is the ranking unit: team, manager grouping, and tenure band. Rank themes only inside a slice. Do not convert rank into a company-wide theme-count percent. A share-of-exits figure implies a complete codebook and a clean denominator you rarely have in qualitative exit text.

A cluster name with no attached excerpts is a failure mode. "Career growth" on a slide without two passages is a heading, not a finding. Send it back. Inventing a percent so the slide looks quantitative is the same class of error. Rank order plus cited passages is the evidence.

Passages should be short, checkable, and stripped of names, client names, and other identifiers that would let a teammate re-identify the speaker. If anonymization would leave nothing distinctive, you do not yet have a publishable cite.

Load transcripts before you cluster anything

Build the working file from completed interviews, not from last quarter's narrative. Include facilitator notes only when they are clearly marked as notes, not as the leaver's words. When the program uses an ai-conducted exit interview, load those transcripts with a source flag so you can audit mixing of human-led and model-led sessions.

Attach team, manager identifier, and tenure band to every row before clustering. Manager is a grouping key so you can rank themes inside a span of control. It is not a field the model is allowed to promote into a cause statement. Tenure stays on the row because early exits and long-tenure exits often describe different constraints even when they reuse the same phrases.

Leave adjacent systems in a sidebar for the human briefer. A regrettable-attrition classifier flag, a performance rating, or a pay-band marker can change how ER reads the brief. Those fields are not interview reasons. Do not concatenate them into the text the clusterer sees, or the model will cluster your HRIS labels instead of what people said.

Drop rows with no usable language: no-shows, "n/a", or a single canned "personal reasons" line with no follow-up. Coding those rows as a "personal reasons" theme inflates volume and hides that you never heard a reason.

De-identify according to policy before the clustering step if your review process requires it. Keep two speakers separable after redaction. If redaction collapses five people into identical boilerplate, clustering will invent a consensus that is only shared masking.

Cluster reasons, then keep only groups with two passage cites

Cluster the reason language. The model proposes groups. A reviewer accepts a group only when two passages in that slice support one operational claim. No cite pair, no theme.

Illustrative path, not a measured case: in one product-team slice, inside the one-to-three-year tenure band, several transcripts talk about on-call load after parental leave. Anonymized passage one: the person describes returning on a Monday and taking Friday night pages the same week, with no overlap from whoever covered the leave. Anonymized passage two: another person describes canceling a specialist appointment because the rotation had no named backup and the team chat defaulted to whoever had recently been out. Those two excerpts can support a theme labeled around on-call return from leave for that team and tenure band. They do not support a percent of all exits, and they do not justify a sentence that the manager is the cause.

Treat the manager-verdict failure mode as a review gate. Both speakers may report to the same person. That coincidence is why the slice exists. Staffing rules, pager policy, and backup design can produce the same passages under a manager people like. Write the operational claim. Personnel conclusions stay with ER and the HRBP, who have the employment file and can hold a conversation the model cannot.

Discard "manager quality" or "toxic leadership" labels that come back with no quoted behavior. Discard any auto-generated theme-count percent next to a label. Inside a slice, it is enough to say this theme is supported by more interviews than that theme, in this period.

A knowledge capture agent may run on the same departure so routines and decisions are not lost. Capture output is what the person knew. It does not explain the leave, and it should not be merged into the theme list as if undocumented work were a stated reason.

Thin slices stay blank on purpose

One detailed interview is still one interview. Do not promote it. Do not borrow a second passage from another team or tenure band to complete the pair. Mixing slices is how a company-wide story appears out of two unlike situations.

When the under-six-month tenure band on that team has a single transcript, the brief cell is blank. The accompanying sentence can say the slice was too thin to theme. That is still a finding ER can use: do not act as if a pattern was found.

Low-headcount teams are the common thin case. Do not roll them into a function-wide theme just to populate a chart. A rolled-up claim needs two passages that actually speak to the rollup. If both passages are about one squad's pager rotation, keep the squad slice and leave the function rollup empty for that reason.

Blank is not a delay. The brief still goes out. Empty cells are part of the quality rule, not a backlog item.

People analytics writes the brief; the model does not close the case

The human owner decides the read order: slices with enough volume, themes that met the two-cite bar, cells that are blank, and what is out of scope. Out of scope always includes auto-naming a manager as the cause and any invented theme-count percent.

Thematic analysis is not attrition root-cause attribution. A theme reports recurring reasons in the interviews you actually have. Attribution is a later claim about what caused a departure, with a stricter evidence bar. If you collapse the two, a pager-rotation theme becomes an unofficial case against a person.

Share excerpts only in the anonymized form policy allows. If two passages would still identify the speakers to anyone on that team, you do not have publishable cites. Drop the theme or wait for more interviews. Do not thin the disguise until it fails.

Schedule the brief even in a quiet month. A short note that every slice was below the two-cite bar is better than a delayed deck of unsupported clusters.

Platforms hold the text; they do not waive the cite rule

Open-text exits and org slices often already live in listening and HCM suites such as Culture Amp, Qualtrics, Workday, and Lattice. Treat those products as a class of survey and employee-record systems. Export or connect the comments and the team, manager, and tenure fields, then apply the same clustering and two-cite rule you would apply to a shared folder of transcripts.

Treat any category labels already in the workspace as hints for where to read, then prove a theme with two passages or leave the cell empty. No platform in that class, and no model sitting on top of it, should auto-publish a manager-named cause or a theme percent.

The document ER and the business receive remains a people-analytics brief: ranked themes where the bar was met, blanks where it was not, and no personnel verdict presented as NLP.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first