CRM when an employee leaves: a handover checklist
| RANI | Question to answer | What to write down |
|---|---|---|
| Recorded | Where does the knowledge live? | Logins, admin rights, how the main processes work, why key settings were chosen |
| Accountable | Who really owns it? | A named owner and a backup. Is the main admin account in a company name, not a personal one? |
| Navigable | Can a new starter find it? | One shared place, one clear name for it, and the date it was last updated |
| Interconnected | What relies on that person's login? | Forms, automations, calendars, and the recovery email and phone number for security codes |
Don’t ask the person leaving to list the tools they use. Ask them to show you. Sit down together and open the CRM. Your goal is to answer one simple question: what relies on their account to keep working? Note what each thing does, what it connects to and who is taking it over.
Then test it before you switch anything off. Send a test enquiry and follow it all the way through. Check that it lands where it should and the right people are told.
What if they’ve already gone?
Try not to panic, and don’t switch anything off yet. Find out who can still get in as an admin, and where password resets and security codes are going. If the answer is the person who left, sort that first.
When I step into a business like this, I start by listening. I ask the team what frustrates them, because they know where it hurts. Then I go through the tools themselves, looking for forgotten automations and ways to make things simpler. I’ve found forgotten automations still sending form entries into a spreadsheet that nobody remembered existed.
Once you know what’s there, write it down, one tool at a time. If your team still isn’t confident, my post on getting your team to use a new system may help.
Is this a software problem or a structure problem?
Usually, it’s structure.
The person who left may not have known those things were linked to them. That isn’t their fault. The structure was never built to cope with someone leaving, and the business can fix that so it doesn’t happen again. The people aren’t the problem. The structure is.
A good CRM can’t fix that on its own. If one person is the only one who knows how it works, the same thing will happen with the next system. I wrote more about this in how to reduce key-person dependency in your business.
When is it worth asking for help?
When nobody on your team is sure how the CRM works, or whether they could change it safely.
That’s usually the moment the team has stopped trusting the system. It doesn’t mean you’ve done anything wrong. It means the business has grown past one person holding it together.
If you’re still choosing a CRM, start with my guide to the best CRM for a small service business in the UK and my six questions to ask a CRM consultant.
If you’d like help setting up a CRM that your whole team understands, I offer CRM setup services for small service businesses through Simplify. I give you two or three options and a clear recommendation, build it around how you work and train your team. Or feel free to message me.
If the person who set up your CRM leaves, the system keeps running. What goes is the knowledge: who can get in, and why it was built that way. The team is then left to struggle on. The fix starts before they go. Write down who owns what, and keep it where everyone can find it.
What actually goes wrong when the CRM person leaves?
The software is fine. The knowledge about how it works leaves with them.
In one of my recent calls with a business, the team told me what happened when a colleague who had set things up left. The account was in her name. To get in, they had to text her and ask for a security code.
It’s easy to see a leaver as an access problem. Who needs to be switched off? But some things rely on that person to keep working. A web form may feed a spreadsheet they own. An automation may run from their email address. Security codes may go to their phone. Nobody notices until the day something goes wrong.
Who should own your CRM?
One named person, plus one named backup. Then nobody is the only one who knows how it works.
Being able to sign in is not the same as being in control. In many CRMs, one main owner can do things other users can’t. That might be adding people, changing permissions or updating payment details. Your team can use the CRM every day and never know that the person leaving is the only one with full control.
Where you can, put the main account under the company, not under a person. Then check that the new owner can actually do those things. Signing in doesn’t prove it.
What should I write down before anyone leaves?
Logins, admin rights, who owns what, and why each setting exists. I use the four parts of the RANI Method to keep the list short: Recorded, Accountable, Navigable and Interconnected.
© Systems Rani 2026. The information contained herein is provided for information purposes only; the contents are not intended to amount to advice and you should not rely on any of the contents herein. We disclaim, to the full extent permissible by law, all liability and responsibility arising from any reliance placed on any of the contents herein.
