If your agency onboards multiple clients into GHL subaccounts, snapshots are one of the most useful tools in the platform — and one of the most commonly misused. Used well, they cut setup time dramatically. Used carelessly, they load a subaccount with workflows and pipelines the client does not need, creating clutter that takes longer to clean up than it would have taken to build from scratch.
Here is a plain-language explanation of what snapshots are, what they include, and how to use them effectively.
What a GHL Snapshot Actually Is
A snapshot is a saved copy of a GHL subaccount's configuration — not the contacts or data inside it, but the structure. Pipelines, workflows, funnels, forms, email templates, calendars, tags, and custom fields. When you apply a snapshot to a new subaccount, you are loading all of that structure in one step instead of building it piece by piece.
Think of it as a template. You build a well-configured subaccount once, save it as a snapshot, and then use that snapshot to give every new client a consistent starting point. This is what makes GHL genuinely scalable for agencies that onboard clients repeatedly.
What Snapshots Do and Do Not Include
Snapshots include structural elements:
- Pipelines and their stages
- Workflows (including triggers, actions, and branching logic)
- Funnels and website pages
- Email and SMS templates
- Forms and surveys
- Calendars
- Custom fields and tags
- Opportunity and contact settings
Snapshots do not include:
- Contacts or leads
- Conversations or message history
- Phone numbers or email sending domains
- Integrations that require re-authentication (like Facebook, Google Ads, Stripe)
- A2P registration — this always has to be done per account
A snapshot gives you the architecture. The connections and data specific to that client still need to be set up fresh every time.
When to Use a Snapshot
Snapshots are most valuable when you are onboarding clients who need a similar setup. If you primarily work with a specific type of business — home services, real estate, med spas, law firms — you can build a snapshot tailored to that niche and apply it every time, then customize the details for each client.
They are less useful when every client you onboard has a unique setup that does not share much structure with the others. In that case, a snapshot might actually slow you down by loading things you have to remove before you can start building what the client actually needs.
The Most Common Snapshot Mistake
The most common mistake is applying a snapshot without reviewing it first. Snapshots carry over everything — including workflows that reference specific phone numbers, email addresses, or campaign logic that does not apply to the new client. If those workflows go live untouched, you can end up with automations firing incorrectly, messages referencing the wrong business, or triggers that conflict with the new client's setup.
The right approach: apply the snapshot, then go through it systematically before turning anything on. Disable all workflows. Review each one. Enable only what applies to this client, update any client-specific details, and test before going live.
Building a Good Snapshot
If you are building a snapshot from scratch rather than saving an existing subaccount, the goal is to build the most common case — the setup that will be 80% correct for most of your clients — and leave room for the 20% that will need customization. Keep it lean. It is easier to add to a clean snapshot than to clean up an overcrowded one.
Document what is in the snapshot. When you hand a configured subaccount to a client or bring on a new team member who will be working in the account, they need to understand what is there and why. A snapshot without documentation is a black box that becomes a problem the moment something breaks.
Keeping Snapshots Updated
GHL updates regularly, and client needs evolve. A snapshot you built a year ago may reference features that have changed or workflows that no longer reflect how you want to set things up. Revisit your snapshots periodically — at least every six months — and update them to reflect what you have learned about what works and what does not. A snapshot that is maintained becomes more valuable over time. One that is ignored becomes a source of errors.