- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
The equipment and the final payroll run are the easy part — this covers the live work, the access and the automations that still speak as the person leaving.
An offboarding checklist for managers whose team works in a shared CRM
Most offboarding checklists were written for an office. They cover the laptop, the badge, the final payroll run and the exit conversation, and they stop there. For a team that runs client work inside shared software, that list misses the part that actually causes damage later: the work assigned to the person leaving, the automations sending under their name, and the access nobody remembers granting.
What follows assumes a manager in that situation. The employment and payroll side varies by jurisdiction and belongs with whoever advises you on it; the sections here cover the operational continuity that is yours to get right.
Start before the last day, not on it
The single biggest determinant of how an exit goes is how much notice the handover gets. A departure known two weeks in advance allows knowledge to move while the person is still available to answer questions. A departure handled on the last afternoon produces a month of archaeology.
The moment a leaving date is known, do three things: list what only this person knows, list what only this person can access, and name the person taking each item. Everything else on this page is the execution of those three lists.
The four categories, in the order they cause trouble
| Category | What has to happen | What goes wrong when it does not |
|---|---|---|
| Live work | Reassign open conversations, tasks, deals and client responsibilities to a named person | Client messages arrive at an unmonitored inbox and go unanswered for days |
| Access | Remove logins, revoke tokens, rotate any shared credential they knew | A former team member retains access nobody audits, sometimes for years |
| Identity in systems | Change what sends, signs or appears as them in automations and templates | Clients receive email from someone who left, and replies go nowhere |
| Knowledge | Write down the undocumented process before the person is gone | A routine task becomes a research project the first time it is due |
Live work ranks first because it has an immediate external cost. Everything assigned to a departing person needs a new owner before their last day, not after: open conversations, outstanding tasks, deals in progress and any client who thinks of them as their contact. Where assignment drives your workflows, manual actions and assignment is the place those tasks are visible, and any rule that routes by individual rather than by role needs updating at the same time.
Access: revoke, rotate, and check the places that are not a login
- Platform accounts. Remove the user rather than changing their password, so the removal is recorded and no shared session survives.
- Sub-account and client-level access. Agency-level removal does not always cascade; check each client environment the person worked in.
- Shared credentials. Anything they knew has to be rotated, not merely un-shared. This is the step most often skipped, and the reason shared logins are worth eliminating before you need to.
- API keys and integration tokens they created. These outlive the user account and are invisible in a normal access review.
- Third-party access granted through them — advertising accounts, business profiles, analytics properties. Ownership frequently sits with a personal account rather than the business, and the time to discover that is not after they have left.
- Physical and phone. Number forwarding, voicemail and any device that receives client calls.
Record each revocation as it happens. Keeping that in an audit trail turns a future security question into something you can answer in a minute rather than reconstruct, and it is the same habit that makes any operational review possible.
Identity: what still speaks as them after they have gone
This is the category generic checklists never mention, and clients notice it immediately. Automated messages, sequences and templates often carry a specific person’s name, signature or sending address. When that person leaves, the messages keep going out and the replies land somewhere nobody watches.
Walk the automations rather than the inbox. Anywhere a workflow sends as an individual, change it to a role address or a monitored shared identity — and verify the sending configuration afterwards, because the workflow sender domain is a common place for a change like this to look applied and not be. Calendar links, booking pages and forms that route to them need the same treatment, and any account template you clone for new clients should be corrected once at the source. Where templates are protected, protected snapshot assets is what stops the fix from being overwritten the next time an account is created.
If you operate a white-label arrangement, remember that your customers see only your brand, so a departing employee’s name appearing in their product is your inconsistency rather than a vendor’s.
Knowledge: capture it while there is someone to ask
Ask the departing person to write down the things they do that are not written down anywhere. The prompt that works is specific: what would break next month if you were unavailable, and what would nobody know how to do? That produces better documentation than a general request for notes.
Convert what comes back into the same form as the rest of your process documentation rather than filing it as a memo. The argument for that is why an SOP comes before hiring or scaling, and the shape it should take — structure, owners and exceptions — is what makes a written procedure usable by the person who inherits it. Shift-based and rota-based teams have an even sharper version of the same problem, which is the subject of shifts, incidents and handover.
Clients and the handover conversation
Tell affected clients before they notice. A short message naming the new contact, sent by the manager rather than by the person leaving, prevents the uncertainty that makes clients start looking around. Introduce the successor while the outgoing person is still present if you can — a handover with both people on the call transfers context that no document carries.
Then make sure the new arrangement actually holds. Response times slip during a transition, and a client’s experience of an exit is largely the experience of waiting longer for replies, which is what a conversation SLA exists to prevent. Watch the accounts involved for the following weeks: a change of contact is a recognised moment of elevated risk, and the ordinary countermeasures are the ones in the mechanics of retention.
Close the loop
Two weeks after the last day, re-run the access list. Something will have been missed — an integration, a shared document, a forwarding rule — and it is far easier to find while the context is fresh. Note what was missed and add it to the checklist itself.
That last habit is what turns offboarding from an event into a process. Every exit teaches you something the previous list did not cover, and a checklist that grows is worth more than one that was perfect once. The same logic applies at the other end of the relationship: a client onboarding checklist improves the same way, and the two documents should reference the same inventory of systems, so that anything granted on the way in has a matching step on the way out. Recording the transition as a set of stages with clear exit criteria, in the way pipeline stages with exit criteria describes for deals, keeps it from being reconstructed from memory each time.
Frequently Asked Questions
What do standard offboarding checklists usually miss?
The systems layer. Most were written for an office and cover equipment, access badges and final pay. They rarely cover reassigning open client conversations and tasks, rotating shared credentials the person knew, or changing the automations and templates that still send under their name.
Is removing someone’s login enough?
No. Remove the user rather than changing their password so the removal is recorded, then check client or sub-account environments separately because agency-level removal does not always cascade. Rotate any shared credential they knew, and revoke API keys and integration tokens they created, since those outlive the user account.
What should happen to work assigned to the person leaving?
It needs a named new owner before their last day: open conversations, outstanding tasks, deals in progress and any client who treats them as their contact. Any automation rule that routes to an individual rather than a role should be changed at the same time.
Why do clients keep receiving messages from someone who has left?
Because sequences, templates and workflows often carry a specific person’s name, signature or sending address. The messages continue and the replies arrive somewhere nobody monitors. Walk the automations rather than the inbox, and switch anything sending as an individual to a monitored role address.
How should knowledge be captured before someone leaves?
Ask a specific question rather than requesting notes: what would break next month if you were unavailable, and what would nobody know how to do? Then write the answers into the same format as the rest of your process documentation so the person inheriting the work can follow it.
When should clients be told?
Before they notice. A short message from the manager naming the new contact prevents the uncertainty that makes clients look elsewhere. Where possible, introduce the successor while the outgoing person is still available, because a joint handover transfers context that documents do not.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.