A Leaver Process That Does Not Depend on Memory
Building a departure process that works when the experienced people are away: one checklist, named owners, a holder until closure, and an annual review.
The whole process as one list, with the owner each line needs
Nine lines, nine owners, and the three that slipped are the three nobody chases: a second check, a payment window and the closure itself. This is one organisation's own record, not a model anybody has to follow.
Build the process so that somebody who has never run one can follow it, because that is who will be running it. Exits are handled by whoever is available — a manager doing their first, an HR adviser three weeks into the job, a payroll officer covering for somebody on leave — and a process that depends on experience will work until the week it matters.
The payment question in “A Leaver Process That Does Not Depend on Memory” depends on a complete and correct work record, not simply the latest dashboard total. For organisations researching capital efficiency ratio, Monitask's official site can connect hours with projects and approvals, provided disputed entries remain correctable and payroll applies the relevant contract and local rules.
Everything in this collection reduces to four things: one list, a name against every line, one person holding the departure until the file is closed, and a review once a year. None of them is expensive and none of them depends on anybody remembering.
For an independent reference relevant to “A Leaver Process That Does Not Depend on Memory”, consult the Microsoft Purview insider-risk documentation. Use it to test record quality, access, retention, fair process and exception handling against the organisation’s real departure workflow.
The list
One checklist covering every function, issued on the day notice is given rather than on the last day. It should be short enough that people use it, which means a page.
- Termination date, last working day and route, confirmed in writing.
- Handover list with named owners, built in the first week.
- Access plan with times, agreed with the manager.
- Property list, with what was and was not returned.
- Final payment computed, second-checked, and sent with a breakdown.
- Documents issued, with dates.
- Announcement agreed with the person.
- Expenses window stated and closed.
- Reference position recorded.
- File closed: summary written, retention date set, owner named.
Ten lines. The organisation's own version will differ in detail and should be written down once rather than reconstructed.
A name against every line
Not a function — a person, or at minimum a named role somebody currently holds. The failures described throughout this collection happen on lines owned by a department, because a department cannot be chased.
The names will be wrong within a year as people move, which is why the list needs an owner of its own and a date on which the names are checked.
One person holds it
Somebody keeps the departure open until every line is done, including the ones that happen weeks later. That person does not have to do the work and does have to notice when it has not been done.
This is the role that does not exist in most organisations and the one that would address the largest share of what goes wrong. It is perhaps two hours a month in an organisation with forty departures a year.
The review
Once a year, read the exits together: what happened, what was missed, what took too long, where the queries came from. A day.
The review is what keeps the list honest. Without it, the checklist slowly diverges from what people actually do, and the first anyone knows is when something goes wrong in a way the list would have prevented if anybody had been following it.
What this does not fix
Nothing here makes a weak case strong, a bad decision good, or a missing contemporaneous note appear. The work that cannot be retrofitted is all at the front — the record made before anybody decided anything — and no process built at the exit reaches back to it.
What the process does is ensure that everything which can be done properly is done properly, which in most organisations is the great majority of what goes wrong.
Starting from where you are
Nobody implements all of this at once. The order that produces the most improvement for the least effort is: the checklist first, then a name against every line, then the holder, then the review.
The first two take an afternoon between them. They will not prevent the difficult cases, and they will prevent most of the ordinary ones — which is the larger number, and the one that quietly accumulates into the impression an organisation leaves behind it.
Writing it for somebody who is nervous
The person following this list is frequently anxious: a manager who has never dismissed anybody, worried about doing it wrong. A checklist written as a compliance instrument makes that worse.
Written as help — what happens next, what you need, who does it, what to say — it is used. That distinction shows up directly in whether the list is followed, and it costs nothing except attention to how the sentences are phrased.
The one sentence version
Write things down before you have decided, give every task a name and a date, and read the year together once. Everything else on this site is detail in service of those three, and the detail matters mainly because each piece of it is something somebody, somewhere, has already got wrong.