The Next-of-Kin Problem Hiding in Your Collaboration Stack
The leaving do is booked. The card has gone round, someone has ordered the Colin the Caterpillar cake, and there is a speech being drafted that will mention 'the good old days' at least twice. All very civilised. Then Friday arrives, the laptop goes back to IT, and a quiet question starts spreading through the team: who actually administers the shared inbox?
That is the digital handover, and most UK teams do not have one. They have a knowledge handover, which is different. Knowledge handover is about what someone knows. Digital handover is about what someone controls. The two overlap, but they are not the same thing, and the gap between them is where teams get stuck.
The leaving card is not a handover
A proper offboarding conversation usually covers the client list, the live projects and the half-finished spreadsheet with the confusing tab names. It rarely covers the Zapier account that has been quietly filing form responses into a shared drive since 2023, or the Figma licence that is billed to a personal card, or the Slack channel where one person is the only admin and the other admins left months ago.
None of this is malicious. It is just the normal drift of modern work. Tools get adopted quickly, ownership gets assigned informally, and before long the team has a set of small digital dependencies that no one has written down. The problem only becomes visible when the person who holds them leaves.
Start with a tool census, not a tearful speech
Before anyone resigns, it helps to know what you are dealing with. A tool census does not need to be a six-month IT project. It can be a shared document with a few honest columns: tool name, what the team uses it for, who owns it, who the backup is, how it is billed, and where the admin settings live.
The list is usually longer than people expect. Shared mailboxes. Project management boards. The wiki that everyone claims not to use. Design files. Password managers. Calendar scheduling tools. The automation platform that connects two systems nobody remembers connecting. The channel where the team keeps its real decisions, which is somehow separate from the channel where it keeps its official decisions.
If a tool has only one admin, it has a single point of failure with a leaving date. That is the sentence to keep in mind.
The admin map: one name per tool, plus a spare
For each tool, write down the primary owner and a backup. Not a team name like 'the digital team'. A person. Then make sure the backup can actually get in. A name on a spreadsheet is not access. A backup who has never logged in is a hopeful note, not a plan.
The practical test is simple: can the backup complete one routine admin task without asking the owner for help? If not, the backup is decorative. Fix that before the notice period starts, not during the last week when everyone is trying to be nice to each other.
A shared workspace such as Kula can hold this map in a sensible place, but the habit matters more than the software. The map has to be reviewed, or it becomes another document that was accurate in February and is now a work of fiction.
Shared inboxes are where good intentions go to die
Shared inboxes are a classic. Everyone knows the team monitors it. Everyone assumes someone else is checking it. Then the person who set up the forwarding rules leaves, and the inbox becomes a small black hole with an out-of-office reply that nobody has updated.
When someone leaves, check the rules, the filters, the auto-replies and the forwarding addresses. Look at the billing contact too. If the inbox is tied to a licence that renews annually, who is going to approve that payment next time? These details are boring right up until they are urgent.
API keys, automations and the quiet single points of failure
Automations are the sneakiest part of the stack. A Zapier or Make scenario might be running on a personal login. A webhook might be tied to someone's old email address. A bot might be using an API key that only one person knows how to regenerate.
When that person leaves, nothing explodes immediately. The automation just stops. A form stops reaching the right folder. A notification stops appearing in the right channel. A report stops updating. By the time anyone notices, the workaround has already become a habit, and the original problem is harder to find.
Add automations to the census. Note who owns the account, not just who built the workflow. If the account is personal, move it to a team-owned one before the leaving date is a factor.
Sudden departures: the test you hope never to run
Notice periods are a luxury. Redundancies, resignations with immediate effect, long-term sick leave and garden leave can all remove access faster than a handover plan can keep up. That is why the audit should not depend on someone being available to explain things.
Keep a break-glass process with HR and IT: who can grant access in an emergency, how they verify the request, and where the recovery details live. Do not put passwords in a shared spreadsheet. Use a proper password manager with an audit trail. The point is not to be dramatic. The point is to avoid a Friday afternoon where three people are guessing which email address owns the company's design files.
A two-page digital handover that actually gets used
A useful handover document is short enough to read and specific enough to act on. For each tool, capture the owner, the backup, the admin URL, the billing arrangement, the key integrations and the next review date. Then add a short section for 'what breaks if this account disappears' and another for 'who to contact if it does'.
Finally, test it. Ask the backup to do one real task using only the document. If they have to message the leaver, the document is not finished. If they have to message the leaver twice, it is a leaving card, not a handover.
The question to ask before anyone resigns is not 'who is covering the work?' It is 'who holds the keys on Monday?' Teams that can answer that question are not being pessimistic. They are just making sure the leaving do is the only thing that gets emotional.
