Short answer
Exit interview analysis turns separate accounts of why people left into a structured set of themes, exceptions, and decisions. Start with a question the organization can act on, code direct statements separately from interpretations, preserve links to the source passages, check who is missing from the data, and assign every accepted action an owner and review date.
The goal is not to discover a single hidden reason for every resignation. It is to produce a defensible account of what departing employees reported, where similar experiences recur, what remains uncertain, and what the organization will examine next.
Decide what the analysis must support
A coding exercise without a decision in view tends to produce an attractive theme chart and little else. Write the decision question before opening the transcripts.
Useful questions include:
- Which part of onboarding should the operations owner review?
- Which role family reports unclear progression criteria?
- Which workload issue needs a local conversation rather than a company-wide policy?
- Which themes also appear in current-employee conversations?
- Which reported problem already has an action, and who owns its review?
Avoid questions such as "What is the real reason people leave?" They invite analysts to flatten different accounts into one answer. Acas describes exit interviews as a way to understand reasons for leaving and inform recruitment or retention changes. That is a practical purpose, not a claim that one interview proves why an outcome occurred. See Acas guidance on responding to a resignation.
Write the decision question, audience, time period, and permitted level of detail at the top of the analysis plan. This prevents a dataset collected for process improvement from quietly becoming material for an individual performance or disciplinary decision.
Prepare a source table before coding
Give every interview or written response a stable record ID. Keep identifiers in a restricted source table, separate from the working analysis where possible. The analysis table should contain only the fields required for the stated purpose.
A practical source table can use these columns:
| Field | What to record | Why it matters |
|---|---|---|
| Record ID | A non-meaningful identifier | Lets an authorized reviewer return to the source without copying a name into every file |
| Departure date | Month or quarter when exact date is unnecessary | Supports time comparisons while reducing needless detail |
| Departure type | Voluntary, involuntary, retirement, end of contract, or another defined status | Prevents unlike events from being combined |
| Role family | A stable job group | Supports useful comparison without relying on exact titles |
| Location or unit | Only at a level safe and useful for the analysis | Helps test whether a theme is local or shared |
| Tenure band | A predefined band | Avoids false precision and makes cohort rules repeatable |
| Interview mode | Conversation, form, call, or other channel | Makes collection effects visible |
| Source passage | The relevant answer or an exact reference to it | Keeps the interpretation reviewable |
| Missingness | Declined, not invited, incomplete, or unavailable | Stops completed interviews from being treated as all departures |
The UK Information Commissioner's Office says employers should specify why they collect worker information, use it fairly and transparently, and keep only what they need. Apply those principles to exit notes before adding fields "just in case." See the ICO guidance on collecting and keeping employment records.
Build a codebook that another analyst can use
Qualitative coding associates passages with meaningful ideas and groups recurring codes into themes. UK government guidance describes thematic analysis as a common way to make sense of a large volume of qualitative material. See GOV.UK guidance on analysing qualitative data.
For each code, document:
- Name: a short, neutral label such as
schedule_notice. - Definition: what the code means in this project.
- Include: statements that qualify.
- Exclude: nearby ideas that belong elsewhere.
- Direct or interpreted: whether the employee stated the point or the analyst inferred it.
- Example: a fictional or safely redacted passage.
- Parent theme: the broader reporting group.
- Version: the date and author of the latest change.
Here is a small example:
| Code | Include | Exclude | Evidence status |
|---|---|---|---|
progression_criteria | The person could not tell what evidence was required for a move | A role did not exist or had no budget | Direct when stated; otherwise analyst hypothesis |
schedule_notice | Late or unpredictable notice of working hours | Total hours or staffing capacity | Direct when a time or example is given |
manager_availability | Difficulty getting a decision, review, or support from a manager | General dissatisfaction without an example | Direct when a work moment is described |
role_reality_gap | Material difference between the role described and the work performed | Normal role evolution discussed and agreed | Direct statement plus contextual review |
Do not use sentiment intensity as a shortcut for importance. Strong wording can reflect communication style, and calm wording can describe a serious issue. Code the subject, example, and consequence that the person actually described.
Pilot the codebook and keep disagreements
Apply the first version to a varied sample before coding the full set. Include short and long interviews, different channels, and records from the groups you plan to compare. Have a second reviewer code part of the material independently or critically review the proposed themes.
When reviewers disagree, record why:
- the definition overlaps another code;
- the source passage lacks enough context;
- one reviewer inferred something the employee did not state;
- the code combines a work condition with an outcome;
- the passage belongs under more than one theme.
Revise the codebook and keep a change log. There is no universal agreement percentage that makes an exit analysis trustworthy. The useful test is whether reviewers can explain differences, apply the definitions consistently, and return from a reported theme to the evidence that supports it.
Separate statements, interpretations, and hypotheses
Use three columns instead of calling everything a root cause.
| Layer | Example | How to report it |
|---|---|---|
| Direct statement | "I did not know what evidence was needed for the next role." | The employee reported unclear progression criteria |
| Analyst interpretation | The progression process may not be visible in this role family | Interpretation to verify against policy and other accounts |
| Operating hypothesis | A clearer criteria briefing may reduce this source of uncertainty | Proposed test, not a predicted retention result |
This separation matters because one departure can support a useful question without supporting a general conclusion. It also makes review easier when an operational owner knows that a policy changed after the interview.
Compare cohorts without hiding the denominator
A theme count needs a denominator. Report at least:
- eligible departures in the period;
- people invited;
- completed interviews;
- usable responses for the question;
- records excluded and the reason;
- the number of coded passages, kept separate from the number of people.
Ten mentions are not ten people when one interview contains several passages. A percentage of completed interviews is not a percentage of all leavers when many people did not participate.
Before comparing teams or locations, check that the groups cover a similar period and departure type. Suppress or combine small cells when a reader could infer who spoke. A reporting threshold reduces disclosure risk but does not create anonymity on its own, especially when the team, date, and circumstances are already known.
Use an analysis matrix, not only a ranking
A practical review matrix keeps evidence and action together:
| Theme | Direct accounts | Counterexamples | Missing context | Proposed owner | Next review |
|---|---|---|---|---|---|
| Progression criteria | What people explicitly reported | Teams where criteria were understood | Whether the process changed during the period | Talent lead | Date of criteria review |
| Shift notice | Examples of late notice | Sites with stable notice | Seasonal demand and local agreements | Operations lead | Date of schedule test review |
| Role reality | Tasks that differed from the role described | Roles where expectations matched | Changes agreed after hiring | Recruitment lead | Date job materials are checked |
Do not rank themes by frequency alone. Add severity, actionability, evidence quality, and the cost of being wrong. A rare report about a serious control failure may deserve immediate specialist handling. A frequent minor irritation may belong in a process backlog.
Worked fictional example
A fictional services company reviews 18 voluntary departures from one quarter. Fourteen people were invited, nine completed an interview, and eight answered the progression question. The working sample is therefore eight for that question, not 18.
Five respondents directly describe uncertainty about progression criteria. Two of those also mention manager availability. One respondent says the criteria were clear after a recent briefing, and two give no progression concern.
The analyst records:
- a supported theme about criteria visibility among respondents;
- one counterexample after the briefing;
- an open question about whether the briefing reached every role family;
- no claim that unclear criteria caused the departures;
- an action for the talent lead to audit where the briefing was delivered;
- a date to compare future accounts after the audit.
This is useful because it tells leadership what to verify next. It remains honest about participation, timing, and causality.
Turn the report into a decision log
For every accepted action, record:
- the theme and evidence reviewed;
- the decision taken;
- the accountable owner;
- the affected process or population;
- the date for review;
- what new evidence would support changing or stopping the action;
- what can be shared back with employees.
A decision log prevents the same theme from appearing in several quarterly decks with no owner. It also distinguishes "we heard this" from "we decided this" and "we verified the effect."
For a broader treatment of qualitative material, use the guide to qualitative engagement data. To design the collection process before analysis, see the exit interview software procurement guide and the confidentiality design guide.
Where AI can assist, and where review stays human
AI can suggest codes, retrieve similar passages, draft a theme description, and point out records that do not fit the dominant reading. It can also introduce false themes, omit qualifying language, merge different concepts, or write a causal conclusion that the source does not support.
NIST's AI Risk Management Framework recommends documenting intended scope, knowledge limits, human oversight, testing, and the context in which a system is expected to work. Apply that discipline to exit analysis: test with representative records, retain source references, review high-impact themes, record corrections, and prevent summaries from directly triggering employment actions. See the NIST AI RMF Core.
Lontra is an employee conversation platform, not a dedicated exit-management system or HR system of record. Review the conversation and analysis capabilities, then use a focused campaign to test the collection workflow, permissions, manager brief, aggregate HR view, and human review against this framework. Verify any required exit export or integration separately.
