Regrettable-attrition classifier
Auto-labels exits as regrettable or non-regrettable using performance, role criticality, and replacement-cost data.
HR processPlanSourceSelectHireOnboardDevelopRewardExit
By Don, DoneThat’s AI coach · updated
Keep the human as the classifier
A regrettable-attrition classifier does not decide who was a loss. It proposes a label, regrettable or non-regrettable, only when three files can support that proposal: recent performance, role criticality, and replacement-cost. A people-analytics or talent lead still records the official class. If any of those three cites is missing, the suggested field stays empty. Empty is the correct output. It is not a defect to fill.
That split matters because the class will be reused. Downstream work such as attrition root-cause attribution and predictive attrition forecasting will treat the field as ground truth. A machine-written class that nobody reviewed becomes a firing-adjacent score the moment someone filters on it. Classification is not a firing decision, not a performance rating, and not a headcount target.
HRIS and people-analytics suites (Workday, Visier, Lattice, Culture Amp) already hold pieces of the three files. Treat them as source systems, not as classifiers. Pull extracts. Do not let a vendor dashboard's "regrettable" flag overwrite the human field.
Load performance, criticality, and cost before suggesting
Run the job against a closed exit, not against an open resignation. For each person who has left, assemble three inputs with stable identifiers: employee ID, role ID, and last day.
Performance: use the last completed review cycle, or a documented calibration result, with a date. Informal manager comments are not a cite. If the person never received a review in the window your policy uses, there is no performance cite.
Role criticality: use the role's current criticality flag from the workforce plan or succession file, not a manager's after-the-fact claim that the leaver was "key." Criticality belongs to the role, not to the exit narrative. If the role has no flag, there is no criticality cite.
Replacement cost: use the cost file your finance or talent-acquisition team already maintains (recruiting spend, ramp time, contractor backfill, or a standard replacement-cost table by job family). Do not invent a dollar figure at classification time. If the job family is missing from the table, there is no cost cite.
Load order is extract, join, then suggest. Do not suggest on a partial join. A suggestion that cites two of three files is still a missing-cite case. Leave it blank.
Write the suggestion as cites, not as a score
When all three cites exist, the suggestion is a short record:
- Proposed class: regrettable or non-regrettable
- Performance cite: source, period, and the value used
- Criticality cite: role ID and flag
- Replacement-cost cite: table row or actuals file and the value used
- Reason line: one sentence that names those three facts
The reason line must point at the files. A phrase such as "high performer in a critical role with a material replacement cost" is allowed only if each clause maps to a field. If the model cannot point at the performance field, it does not mention performance, and it does not propose a class.
Write the two-class policy once, next to your other exit codes:
- Regrettable: performance is at or above the keep threshold, the role is flagged critical or successor-scarce, and replacement cost is in the file.
- Non-regrettable: performance is below the keep threshold, or the role is not flagged critical and replacement cost is treated as routine under your table.
Do not encode "we liked them" or "the manager is upset" as regrettable. Those belong in exit interview thematic analysis, next to themes, not next to the class.
If the three files conflict (strong performance, non-critical role, high replacement cost), still suggest, still cite, and still require a human. Conflict is a reason to read the record, not a reason for the model to break ties in silence.
One exit, two outcomes
A senior data analyst resigns. The last review is on file and meets the keep threshold. The role is flagged critical in the workforce plan. The replacement-cost table has a row for that job family. The job can propose regrettable, with those three cites attached. A talent lead opens the record, checks that the review is the right cycle and that the criticality flag still applies to that role ID, then writes the official class.
Change one fact. The review is missing because the person joined after the last cycle. The other two files are complete. The suggestion field stays empty. The lead does not type regrettable because the team "knows they were good." They wait for a documented performance cite (a calibration note, a probation outcome, or an approved exception with its own cite) or they leave the official class empty as well. Empty stays empty if a cite is missing.
That is the method: load the three files, suggest with cites, leave blanks, human classifies. There is no fourth step where the model backfills from culture or from an ai-conducted exit interview. Interview text can explain why someone left. It cannot stand in for performance, criticality, or cost.
Failure modes that corrupt the class
A label with no performance cite is the most common corrupt record. Someone writes regrettable because the role was critical and replacement will be expensive. Without performance, you have a hard-to-fill seat, not a regrettable loss. Later reporting then mixes keep-level exits with roles that were simply scarce. Block any write of a suggested class when the performance pointer is null.
Treating the suggestion as the official class is auto-labeling. Dashboards that bind to the suggested field skip review. Bind reporting to the human field only. Keep the suggestion visible, with cites, so the reviewer can accept, reject, or leave blank. Acceptance is an action. Copying suggested into official by default is auto-labeling, which this process does not do.
Inventing a regrettable rate is the slide that follows a half-classified file. Do not divide regrettable by all exits and publish the percentage. The denominator is wrong while blanks exist, and the numerator is wrong if suggestions were copied across. Report counts of classified regrettable, classified non-regrettable, and unclassified. Unclassified is a data-quality number, not a rounding error. A rate is only honest after a defined cohort is fully classified under the same policy.
Catch these in review as well: using the exit interview as a performance cite; letting a manager recode criticality after the resignation; treating classification as a reason to accelerate a PIP for people still in seat. The class describes an exit that already happened. It does not authorize a firing decision for anyone remaining.
What the classified file is for
Publish a classified extract, not a model score. Each row should carry official class (or blank), the three cites used, reviewer, and date. Rows with a blank official class stay in the file so you can see coverage.
Use reviewed regrettable rows to focus retention work. Keep non-regrettable exits from crowding that queue. Feed only reviewed classes into attrition root-cause attribution. Forecasting models that want a regrettable target should train on the human field and should drop blanks rather than impute them.
Revisit the policy when the performance scale, criticality definition, or cost table changes. Relabeling history is a documented batch, with the new cites, not a silent refresh of suggestions.
Vendors in this class (Workday, Visier, Lattice, Culture Amp) can store the official field and the cite pointers. They do not replace the review step. If a platform offers an automatic regrettable flag, park it next to the suggestion, never on the official class.
The operating rule is short. Suggest only with performance, criticality, and replacement-cost cites. Leave the suggestion empty when a cite is missing. A human still classifies. Do not auto-label. Do not invent a regrettable rate. Classification is not a firing decision.
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