What the Last Day Has to Produce
The eight things a last working day has to produce — access, property, handover, data, pay, documents, announcement, file — and their order.
What one organisation computed on a last day, line by line
Three of the five lines were still unpaid six weeks later. The deduction on the last line was taken under a clause signed on the employee's first day; whether it may be deducted from a final payment at all is a question for somebody qualified in the place concerned.
A last working day has to produce eight things. System access closed, property returned, handover completed, data accounted for, final pay computed, documents issued, the announcement made, the file closed. Two of those are usually on somebody's list — property and the announcement — and the other six are nobody's job in particular.
The handover issue in “What the Last Day Has to Produce” is easier to manage when current projects, recorded time and unfinished work can be reviewed before access closes. A team evaluating view the solution for does microsoft teams track your activity should set a clear cutoff, export what is genuinely required and avoid retaining unnecessary activity data after the departure workflow is complete.
None of this is difficult. It fails because it is distributed — IT, payroll, the line manager, facilities and HR each hold a piece, nobody holds the whole, and the day arrives with no single list that anyone is accountable for.
For an independent reference relevant to “What the Last Day Has to Produce”, consult the FTC data-security guidance. Use it to test record quality, access, retention, fair process and exception handling against the organisation’s real departure workflow.
One list, one owner
The fix is unglamorous and reliable: a single checklist per departure, with a named owner for every line and a date, held by one person who is not the line manager. The line manager is the wrong owner because they are the one having the difficult conversations and the one most likely to be away the following week.
- Confirm the last working day in writing, and whether notice is worked, paid or part of each.
- Issue the checklist to every function on the day notice is given, not on the last day.
- Collect property and record what came back, including what did not.
- Close access on a schedule agreed with the manager, not all at once at 9am.
- Complete handover and name the person who now owns each thing.
- Compute and check the final payment before the last day, not in the next payroll run.
- Issue the documents the person is entitled to and keep copies.
- Close the file, set the retention date, and record who the file now belongs to.
The checklist is also the evidence. Eighteen months later the question is rarely "did you behave reasonably" in the abstract; it is "what did you actually do, and when", and a dated list answers it in one page.
Access is not one switch
Treating access as a single event produces two failures at once. Cut everything at nine in the morning and the handover that was supposed to happen that day cannot happen. Leave everything open until somebody remembers, and a former employee has a working account for a fortnight.
The workable shape is a staged close: interactive access ends at an agreed hour, mail is diverted rather than deleted, shared credentials are rotated because they cannot be revoked person by person, and anything the person administered is reassigned by name before they go.
| What is being closed | When, in practice | Who has to act |
|---|---|---|
| Interactive sign-in | End of the last working day | IT |
| Mail and calendar | Diverted same day, retained to schedule | IT |
| Shared or service credentials | Rotated within the week | IT and system owners |
| Building and site access | End of the last working day | Facilities |
| Third-party and vendor accounts | Needs a list that usually does not exist | System owners |
| Administrator rights held personally | Reassigned by name before the last day | System owners |
The last two rows are where organisations discover that nobody knows which external services the person held accounts with, or that a production system has exactly one administrator and they are leaving on Friday.
Property, and the things that are not property
The list of company property is easy and almost always complete. What is missed is the category next to it: things that are not property but matter more, such as work held in a personal account, a phone number clients call, or a document that only exists on a laptop.
Record what came back and record what did not, including the person's own explanation. A line saying the second monitor was never issued is worth having; discovering six months later that nobody can tell whether it was issued is not.
Handover has to name people
"Handover completed" is not a fact about anything. What makes it one is a list of things with a named person against each — not a team, not a function, a person — written while the leaver is still there to argue with it.
The useful question to ask is narrow and slightly rude: what will break in the next ninety days if nobody else learns this? It produces a much shorter and much more honest list than asking somebody to document their role.
Pay before the day, not after
A final payment computed in the next ordinary payroll run is a final payment computed after the person has gone, by somebody who cannot ask them anything. It is also the single most common reason a departure that was going fine turns into correspondence.
Compute it in advance, have somebody else check the arithmetic, and make sure the person knows what they are getting and when before they leave. Most disputes about final pay are not disputes about entitlement at all; they are about a number that arrived with no explanation attached.
Send the breakdown before the last day, line by line, with the date it will be paid. A figure with no explanation attached generates a reply; a breakdown usually does not.
The announcement, which is the part everybody gets wrong
Something will be said, whether or not it is planned, and the version that circulates is the one that was said first. Agreeing a single sentence with the person before they leave costs nothing and removes almost all of the subsequent trouble.
It also constrains what the organisation can say later. A departure announcement that is vague, warm and short is consistent with every reference the organisation might later give; one that explains too much is not, and the inconsistency is what gets noticed.
Closing the file
The last act is to close the file deliberately: what is kept, for how long, on what basis, and who owns it now that the manager and the HR adviser have both moved on. A file that is simply left where it is tends to be either destroyed early by somebody tidying up or kept forever by nobody in particular.
Both are problems, and both are avoided by writing a retention date on the file on the last day. How long that date should be is a question for somebody qualified in the place concerned, and it is a question worth asking once and then applying to every departure rather than asking each time.