HighLevel SaaS Mode: What Running It Looks Like After You Turn It On

You typed "highlevel saas mode" instead of "gohighlevel saas mode," probably because that's what your billing screen says. HighLevel is the company, gohighlevel.com is the domain, and GHL is what everyone in the Facebook groups calls it. One product, one SaaS Mode, gated to the same $497/mo Agency Pro plan. That part takes a sentence.

The part that takes a post is what happens after you turn it on. Other posts on this site already cover the definition, the worth-it decision, and the mechanics and rebill walkthrough. This one is about the operating model. What the platform does for you the moment a client pays, what it leaves to you, how the support load shows up, how you keep 30 sub-accounts on the same snapshot, and where your third-party apps fit in the plan tiers.

HighLevel, GoHighLevel, and GHL run the same SaaS Mode

There's no HighLevel version and GoHighLevel version. The help portal calls itself the HighLevel Support Portal, the pricing page lists Starter at $97/mo, Unlimited at $297/mo, and Agency Pro at $497/mo, and SaaS Mode sits under Agency Pro with automated sub-account creation listed as a feature of that tier. Older help docs call the same tier the SaaS Pro plan or the $497 SaaS plan. Same thing.

Unlimited gets you the white-label layer: your logo, your domain, unlimited sub-accounts. Agency Pro adds the SaaS Configurator, automatic provisioning, and rebilling. If you're still deciding between the two, the white-label pillar covers that tradeoff and the SaaS Mode pricing post runs the numbers. The rest of this post assumes you're on Agency Pro and the toggle is already on.

What the platform does the minute a client pays

Everything starts in Agency View, then SaaS Configurator. A plan holds the monthly and annual price, a trial length if you want one, the features that tier includes, usage limits, add-ons, and the snapshot that gets loaded into every new account. You can build up to 99 plans, though you'll want three. Each plan has a Copy sale link button, and that link is the thing you put on your pricing page.

When a prospect pays through it, HighLevel's configurator guide describes the sequence: a sub-account is provisioned and linked to the customer, the snapshot applies, a welcome email goes out with login credentials, and the sub-account shows as Active (or Trialing if the plan has a trial). You don't touch it. You'll see a new row in your Sub-Accounts list next time you look.

Here's what the platform doesn't do, and this list decides your onboarding flow:

• It won't register the client's phone number for A2P messaging. Their texts don't go out until that's done, and it's the ticket you'll see first.
• It won't connect their Google Business Profile, Facebook page, or Instagram. Those need the client's own logins.
• It won't point their domain at their funnels or set up their calendar availability.
• It won't import their contacts.

So the client lands in a working shell, not a working business. HighLevel's own SaaS Mode playbook puts the goal plainly: "The user should not have to 'build' anything. They should only have to 'turn it on.'" In practice that means your snapshot carries the onboarding, not your calendar. Build a Getting Started pipeline into the snapshot with one opportunity card per day-one task, and customize the welcome email (SaaS Configurator, Advanced Settings, Customize Welcome Email) so the first thing the client reads is your voice and a link to a 15-minute kickoff call. That call exists to do the four things above. Everything else, the client does by clicking through the pipeline you shipped.

One setup gotcha to know before your first real signup: if the funnel hosting your order form sits on Stripe test-mode keys, the payment goes through and no sub-account gets created. Both the agency and that sub-account need live keys pointed at the same Stripe account. Test with a real card and refund yourself.

The support load shows up on a schedule

Nobody budgets for this because the setup guides end at "embed the link." Once clients are paying you for software, they file software tickets. In the first 90 days on a new SaaS book, the ticket mix is predictable:

• Week one: "I never got my login." The welcome email landed in spam, or they signed up with a typo. Resend it.
• Weeks one and two: "My texts aren't sending." A2P registration is pending. Set expectations on the kickoff call so this isn't a surprise.
• Month one: "How do I connect my calendar, my Facebook, my Google?" Loom videos for the top ten questions answer most of these without a reply from you.
• Ongoing: wallet questions. Clients on a usage plan fund a wallet, and auto-recharge keeps it topped up. HighLevel's SaaS FAQ notes that auto-recharge doesn't support 3DS-only cards, which is the kind of thing you learn when a client in Europe asks why their texts stopped.
• Ongoing: upgrades and cancellations. Upgrades are a quick plan change. Cancellations have a sequence that matters: when SaaS is disabled for a sub-account, the subscription is cancelled and the wallet is permanently deleted. You get the balance by email and refund it manually. Write that into a checklist so nobody on your team clicks before they've noted the balance.

Plan for roughly half an hour per client per week during those first 90 days, then watch it drop as the snapshot gets battle-tested. What doesn't drop is the weekly account health pass. HighLevel's playbook recommends monitoring account health for engagement drops, and it's right: a client who stops logging in during month two is a month-four cancellation. Ten minutes a week scanning last login and message volume across the book is the cheapest churn work you'll ever do.

Keeping thirty sub-accounts on one snapshot

This is the part of SaaS Mode that changes most as the book grows. Your plan points at a snapshot. Every signup gets whatever version of that snapshot existed at that moment. Fix a workflow on Tuesday and the accounts created Monday still have the old one.

The maintenance loop, per HighLevel's refresh and update doc, goes like this. Edit the asset in the source sub-account. Open Account Snapshots and refresh the snapshot, because that isn't automatic. Then use Push Update to pick which sub-accounts that loaded this snapshot should receive it, and which assets to send. Pushes only reach sub-accounts inside your own agency. Version Management records a new version on each refresh with a summary of what was added, removed, or synced, but it doesn't include a revert. There's no rollback button. If you push a broken workflow to 30 accounts, you fix it in the source and push again.

That shapes how you run the book:

• Keep one source sub-account that's never sold to anyone. It's the master. Nobody tests in it.
• Keep a second staging sub-account on the live plan. Sign yourself up through the real sale link and confirm the snapshot lands correctly before you push anything.
• Push selectively. The push lets you choose assets, so send the fixed workflow, not the whole snapshot. The assets you push replace the versions in the sub-account, so anything a client edited in one of them gets overwritten. Either tell clients to duplicate before customizing, or leave client-editable assets out of every push.
• Keep a changelog outside GHL. Version Management shows you what changed, not why.

The scale pain here is real enough that agencies keep asking for finer tooling. One request on HighLevel's public ideas board reads: "We need the ability to add part of a snapshot (workflow or trigger) to every single sub-account at once (or selected accounts) instead of pushing a snapshot update." That's what you're managing around at 30-plus accounts. For the broader snapshot playbook, the snapshots pillar goes deeper.

Existing clients you sold before SaaS Mode don't migrate on their own either. From the Sub-Accounts list, the three-dot menu has Switch To SaaS. You pick a plan and a Stripe customer, and the account sits On Hold until the client adds a payment method. Their feature access changes to match the tier the moment it activates, so check that the tier includes everything they were already using.

Where the app stack fits in the plan tiers

The third-party layer is what separates your SaaS from the other white-labeled GHL offers in your client's inbox, and the configurator lets you bundle it. Per HighLevel's app bundling doc, you add marketplace apps to a plan from the SaaS Configurator, up to 10 apps per plan, and only apps with the Agency and Sub-Account distribution type are eligible. Two operating rules follow from the fine print:

• Auto-install only fires on new sub-accounts created after you save the plan. Existing sub-accounts don't get the app retroactively; you or the client add it manually. So decide your stack before you launch the tier, not after 20 signups.
• App charges bill to your agency card by default. Passing the cost through means raising the plan price to cover the app plus your markup. The doc says exactly that, so build the tier price from the app costs up, not from a round number down.

Tier it the way the support load taught you. A base tier with the core snapshot and no apps for the price-sensitive signup. A middle tier that adds the two apps every client in your niche needs. A top tier with the full stack. Removing an app from a plan later stops future installs only, and existing accounts keep it until someone uninstalls. The SaaS Mode benefits post covers the margin side of stacking apps this way.

The app most SaaS books are missing

Every sub-account you provision ships with GHL's Social Planner, and on most SaaS books nothing fills it. The client got a scheduler, not content, and an empty feed is the first thing a prospect notices when they check the client out. Brandblast is a white-label app installed from the GHL App Marketplace that generates months of branded posts, carousels, videos, and AI avatars per sub-account from the client's own logos, colors, and images, pushes them into that Social Planner, and keeps creating and posting with Autopost. Bundle it into a plan tier and every new signup gets a full content calendar on day one, which is the closest thing to an instant win a SaaS client can see without logging in. The white-label pillar covers where it sits in the stack.