Taking Over a Client's GoHighLevel Account

The client forwarded the login on a Sunday night, pleased with themselves. The last agency had “set the whole thing up,” they said, and they just needed you to take the wheel. You logged in Monday morning. The dashboard looked busy. Workflows down the left rail, a calendar, a website, a pipeline with stages already named. For about a minute it looked like a running account you could simply adopt.

Then you opened the workflows, and most of them sat in Draft. You opened the calendar, and it was still bound to a Google account that was not the client’s and not yours, a stranger’s inbox somewhere. You opened the custom values and found a booking link pointing at a Calendly that belonged to whoever this build served before. You checked the phone number and there was no A2P brand registered against it, which meant that for however many months the client thought they had a working system, the texts it tried to send had been quietly dropped at the carrier. The account was not broken. It was worse than broken. It was running, and it was doing nothing, and nobody had noticed because every light on the top layer was green.

That is the job you have actually been handed. Not a working account to adopt, and not an empty one to build. A half-poured casting someone else walked away from, that you now have to decide what to do with. This is how to read it, and how to tell whether it is worth truing up or belongs back in the melt.

This is the opposite of a handover

It helps to name the thing precisely, because it looks like a job you already know and it is not. When you finish a build and pass it to a client, you run a handover: you walk the account from the bottom up and scrub your own name, your calendar and your admin seat off it before it goes out. We have a full pass for that, and it exists because a clean build can still leave the floor with you baked into it.

A takeover is that same walk, inverted and run blind. In a handover you know the account because you built it. In a takeover you know nothing. Someone else chose the triggers, authorised the integrations, named the custom values and registered, or did not register, the number. You are inspecting a stranger’s work with the client already on your books and the clock already running. The danger is not that the account is empty. It is that it is full, and full of someone else’s decisions, half of which are wrong and none of which announce themselves.

So the first move is not to fix anything. It is to find out what you are standing on.

What you actually inherited

A GoHighLevel sub-account is layered, and an inherited one is almost always sound on the top layer and hollow underneath. Understanding why comes down to understanding what does and does not travel when an account is built from a snapshot and then abandoned, which is how most of these accounts came to exist.

A snapshot copies structure, not connections. The public guides on snapshot imports lay out exactly where the line falls, and it matches what you find in the wild: a calendar keeps its names, its durations, its availability hours and its buffers, but the link to a real Google or Outlook account has to be reconnected inside the destination sub-account. Email sending, payment gateways and external app connections have to be re-authorised. Custom domains need their own DNS, published per account. Phone numbers are account-specific. Workflows arrive in Draft and have to be switched on one by one. That source is a third-party guide confirmed across several search results rather than fetched from GoHighLevel directly, but it describes the behaviour every agency sees: an imported account has the shape of a working system and none of the wiring.

Sitting under all of it is the one that bites hardest, because it is invisible from the screen. A2P 10DLC registration, the thing that lets a US number actually send text messages, is tied to the sending business and the number, not to the build. The compliance guides on this make the point that each client sub-account registers its own brand and campaign, coordinated through The Campaign Registry, and that unregistered traffic is filtered by the carriers with no visible error on the GoHighLevel side. That is why a handed-over account can look completely live and still drop every text it sends. The previous builder either never registered it, registered it under their own business, or registered it for a different client entirely. None of those help you. The send path has its own full trace if you want the deep version, and on a takeover you run that trace early, not late.

Read it as salvage, not as a to-do list

Here is where a takeover stops being a checklist and becomes a judgement call. You are not trying to list everything that is wrong. You are trying to decide, subsystem by subsystem, whether the thing in front of you is worth keeping. Three questions do that work, and you ask all three of every piece.

First, does it do the job this client needs. Not the job the last client needed. A roofing funnel inside an account you just took over for a dental clinic is not a head start, it is a demolition job with extra steps.

Second, can you take ownership of it cleanly. An integration authorised under a stranger’s Google, a domain on DNS you do not control, a number with no clear registration: these are not yours to fix, they are yours to rebuild, and that is a different cost.

Third, is it bespoke to this client or generic. A stock workflow you could reinstall from any snapshot in an afternoon is worth nothing as inherited material. A pipeline the last agency genuinely tailored to this client’s sales motion, with real history in it, is worth protecting.

Run those three reads across the layers that matter, ownership, the number and its A2P status, the calendar and other connections, the custom values and fields, and the workflows, and you stop having a vague sense that “it needs work.” You have a map of what salvages and what scraps, and the map is what the rebuild-or-repair decision is actually made from.

The faults a running account hides

A takeover goes wrong in a specific way: you fix the layer you can see, go live, and the layer you could not see takes the client down a week later, in front of them, after you told them it was handled. These are the ones that do it. For each, what you see, what is actually wrong, and the move.

The silent A2P gap

What you see is a complete, confident texting setup. Workflows that send SMS. A number on the account. Message templates written and waiting. What is actually wrong is that the number was never registered under this client, so the carriers have been dropping the sends the whole time, and GoHighLevel shows you no red anywhere, because from its side the message left. You find this the way everyone finds it: the client asks why none of the leads from last week ever got their text, and you have no good answer because you assumed a setup that looked finished was finished.

The move is to check A2P before you touch anything else, because it has the longest lead time and the highest blast radius. Register the brand and the campaign for this client’s business against this account’s number. Until that clears, nothing you build on top of it matters, because none of it can send.

The calendar that books to a ghost

What you see is a working calendar. Slots, availability, a booking widget on the site that confirms an appointment when you test it. What is wrong is that the appointment landed in a Google calendar you cannot open, because the OAuth link still points at the previous builder’s account. The client’s leads book time that the client never sees. You often cannot even tell from the settings screen, because the calendar shows as connected. It just is not connected to anyone you or the client controls.

The move is to disconnect the calendar integration and reconnect it to the client’s own Google or Outlook, then book a live slot and confirm it lands where a human on the client’s team will see it. A connection that reads as healthy is not the same as a connection that points at the right inbox.

The buried custom value

What you see is a message going out. The automation fires, the text sends, the email arrives. What is wrong is that the body reads “book here: “ followed by the last client’s link, because a workflow is interpolating a custom value that still holds the previous owner’s data. The slots came across in the import. The values inside them are whatever the last builder typed, and they do not announce themselves, because the message still sends and still looks like a message. It is just quietly wrong in a way the client’s own customers see before you do.

The move is to open and read every custom value, not scan them, and treat each as the previous client’s until you have confirmed otherwise. Why those values arrive blank or stale is worth the read if you build from masters yourself, because the failure on a takeover is the same one with a different name on it.

The draft-workflow trap

What you see is a long, reassuring list of workflows. The account clearly has automation. The nurture is “there.” What is wrong is that a chunk of it imported in Draft and was never switched on, so the sequence the client believes has been following up with every lead for months has never fired once. The list of workflows is not a list of running workflows, and nothing on the dashboard distinguishes the two until you open each one and read its status.

The move is to walk the automation and separate what is active from what is merely present. Do not count a workflow as working because it exists. Enrol a test contact and watch it actually move before you tell the client the follow-up is handled.

The ownership you do not hold

What you see is admin access and a login that works. What is wrong is that the previous agency still holds the location, or a seat on it, or the token behind a key integration, which means you are about to invest hours improving an account that someone else can still reach, lock, duplicate or wipe. This is the one that turns a bad week into a bad month, because every hour you put in before you have confirmed ownership is an hour you have lent to a stranger’s good behaviour.

The move is to settle ownership before you build, not after. Confirm who holds the location, get the client made the owner, step the old agency’s access down to nothing, and only then start spending real time. An account you do not control is not an asset you are improving. It is a liability you are decorating.

The arithmetic of fix versus pour

Once the triage map is in front of you, the decision is arithmetic, and the arithmetic is simpler than it feels in the moment. Both routes share one fixed cost that drops out of the comparison: the GoHighLevel subscription. That is $97 a month on Starter, $297 on Unlimited and $497 on Agency Pro, with roughly a sixth off for paying annually, checked on 27 October 2026. The client pays that whether you patch the account or replace its contents, so set it aside.

What differs is the labour on one side and a published price on the other. Start with the thing you can actually price: a clean build. A snapshot in our catalogue runs from $920 to $2,280, paid once, and licensed for unlimited sub-accounts under your agency. Pick the trade. An HVAC company snapshot lists at $1,440 today, a dental clinic snapshot at $1,480. Delivery is within 24 business hours of purchase confirmation, installation is free with every build, and that install is 15 hours of dedicated installation support, to be used within 8 days of purchase, which on a takeover is precisely the window in which you reconnect the calendar, register A2P and rebrand the account to the client. The full sheet, generated from the same feed the checkout reads, is on the pricing page.

Now the other side, where the numbers go soft, which is the whole point. The patch has no sticker. Its cost is the hours you spend, and the hours you spend are the hours it takes to fix faults you have not found yet. You can estimate the ones on the triage map. You cannot estimate the ones under them, and on a stranger’s account there are always ones under them.

So price it against your own time, with every figure a lever you set. Say you value your build hours at seventy-five dollars each, a number to replace with your own real rate. At that rate a $1,440 build is a little over nineteen hours of your time. The question the arithmetic asks is blunt: will truing up this inherited account take you more than nineteen hours, counting the A2P registration you have to do on either route, the reconnections you have to do on either route, and the open-ended hunt for the buried faults that a clean build simply does not have. If the honest answer is yes, the build is cheaper, and it is cheaper with a known ceiling instead of an open meter. If the honest answer is clearly no, because the account is genuinely sound and this-client-specific and yours to hold, then patch it, and do not let us sell you a build you do not need.

The reason the build so often wins is not that patching is slow. It is that patching is unbounded. A price you can read beats an estimate you cannot, and the inherited account denies you the estimate by hiding the faults that set it.

The objections, including the one against us

“The account mostly works. Rebuilding it is wasteful.” Sometimes it is, and when it is, do not rebuild. If you hold the location, the number is registered and live under this client, the calendar points at their inbox and the build is genuinely theirs, then the account is an asset and replacing it is the waste. The triage is exactly what tells you which case you are in. The waste worth worrying about is not a clean build you did not strictly need. It is the stack of weekend hours spent truing a casting that was never going to run right, on an account you may not even own.

“A rebuild means redoing A2P and reconnecting everything anyway, so why not patch?” This is the sharpest objection and it is half right. You do have to register A2P and reconnect the calendar, the domain and the integrations on any route, because none of those travel with a build, inherited or fresh. That work is fixed. It is not the variable. The variable is everything else: the buried values, the draft workflows, the stranger’s decisions you have to find and unpick one by one. A clean build gives you a known, tested foundation to do the unavoidable connection work on top of, instead of making you do the same connection work on top of a mystery. Same floor, different thing standing on it.

“Why would I buy a snapshot when my client already paid for one?” Because what your client paid for was a running account, and a running account is not the same as a build you can stand behind. If the inherited one holds up under the triage, you have saved your client money and us a sale, and that is the right outcome. We only win this one when the triage says the repair costs more than the pour, and on a genuinely sound inherited account it does not. Buy the build when the math says to, not because the old account has a stranger’s fingerprints on it. Honestly, most of the time, the math says to, and that tells you something about the quality of what gets handed over in this market, not about our wanting the sale.

“I can audit it myself for nothing, so I do not need any of this.” You can, and you should, and the triage above is yours to run free of charge on every account you take over, ours included. The audit is not the cost. The cost is the repair that follows it, and the repair on a stranger’s account is open-ended in a way the audit cannot show you up front. If you would rather not run the account at all once it is sound, that is ongoing fulfilment, which is labour priced as labour. If you only need the clean foundation and will run it yourself, that is a snapshot installation. Either way the decision is yours, and it should be the arithmetic’s, not the sunk cost of what the last agency left behind.

The summary is short. An inherited GoHighLevel account is a casting someone else half-poured. Read it before you touch it, score each subsystem for fit, ownership and bespokeness, and put a number on the repair before you start it. If that number, at your own rate, climbs past the price of a clean build, pour the clean build. The account that looks finished is the one that costs you the most, because finished and working are not the same thing, and only one of them pays your client’s bills.