Agency Account vs. Standalone Account: The First Decision
The agency account structure in GHL separates the platform into two tiers: an agency master account and sub-accounts beneath it. If you are managing GHL for a single business and never intend to manage it for others, a standalone account (single location) is simpler. But if you are building a marketing agency, a consultancy managing multiple clients, or a business with multiple distinct brands, the agency account structure is the right foundation.
The agency account holds: your agency-level settings, the sub-account list, billing configuration, white-label settings, and the snapshot library. Sub-accounts are the client environments — each client or brand gets its own sub-account with its own CRM, pipelines, contacts, automations, and communication channels.
The key constraint to understand upfront: sub-accounts cannot share contacts or pipelines with each other natively. If a client has two business units that share a prospect database, that is a design problem you need to solve in the architecture phase, not discover after you have built three pipelines and enrolled 500 contacts.
Sub-Account Structure and Isolation
Each sub-account should map to one cohesive business operation. That usually means one client, one brand, or one distinct market segment — not one campaign, not one product. Sub-account proliferation is the most common GHL maintenance problem: agencies that create a new sub-account for every campaign end up with 40 sub-accounts after 18 months, most of which are inactive, and nobody knows which ones are current.
The naming convention for sub-accounts matters more than it seems. A consistent format — client name + location or brand identifier — makes the agency account navigable. "Smith Roofing — Phoenix" is better than "Smith Roofing" (ambiguous if there are multiple locations) and much better than "SR_PHX_2024" (unreadable to anyone new).
Custom fields at the sub-account level should be established before any data entry or automation is built. GHL allows sub-account-level custom contact fields and custom opportunity fields. The fields need to be defined based on the actual data the business captures — not a generic template — because automation triggers and workflow branches reference these fields. Renaming or restructuring custom fields after workflows are built is a non-trivial operation.
White-Label Configuration
White-label GHL is the SaaS reseller model: you brand the platform as your own product and resell access to clients. The configuration stack is:
- Custom domain for the portal. Your clients log in at app.yourcompany.com, not app.gohighlevel.com. This requires a CNAME record pointing to GHL's servers. The DNS propagation step is the one that trips people up — configure it early, because it takes time.
- Branded email sending domains. This is the most operationally important step and the one most frequently skipped. If your clients are sending email from within GHL, those emails need to come from a domain you control and have authenticated (SPF, DKIM, DMARC). Sending from the default GHL sending domain is a deliverability risk. Each sub-account should have its own authenticated sending domain, or at minimum a subdomain of the client's primary domain.
- Branded login portal. Custom logo, color scheme, and support contact information so clients do not see GHL branding when they log in.
- SaaS mode configuration. If you are reselling sub-account access as a subscription, SaaS mode lets you configure pricing tiers, feature access by tier, and Stripe integration for recurring billing.
Pipeline and Opportunity Design
The pipeline is the CRM backbone. Every sub-account should have pipelines that reflect the actual sales motion of that specific business — not a generic "Lead → Prospect → Customer" template. That template is meaningless for most businesses and produces pipeline metrics that nobody uses.
The design questions to answer before building any pipeline:
- What is the first stage? (Not "lead" — what specifically does the business call the first meaningful CRM stage?)
- What action moves an opportunity from stage to stage? (Button click? Calendar booking? Phone call logged?)
- What does Closed Won mean here? (Signed contract? First payment? Service delivered?)
- Should there be multiple pipelines? (One for new business, one for upsells?)
Pipeline automation is where GHL earns its keep. Opportunity auto-creation on form submission, auto-move on calendar booking confirmation, auto-notify on stage change — these make the pipeline self-maintaining. A sales rep who books a call through a GHL calendar should see that opportunity automatically move from "New Lead" to "Call Booked" without any manual action.
Automation Workflow Architecture
GHL workflows are conversation-based, not just email-based. A single workflow can send an SMS, wait for a reply, send a voicemail drop, send an email, and assign an internal task — all in sequence, with branching logic based on what the contact did or did not do.
The architecture principle: every workflow should have a clearly defined trigger, a clearly defined goal (what state is the contact in when this workflow successfully completes?), and a clearly defined exit condition. Workflows without exit conditions run until they exhaust their steps. Contacts who re-trigger a workflow without proper enrollment guards run through it multiple times.
The four most common workflow types in a client account:
- Inbound lead capture workflow. Trigger: form submitted. Actions: create contact, create opportunity, send internal notification to rep, send acknowledgment SMS or email to lead, assign follow-up task. This should run within five minutes of form submission. If your lead response time is longer than five minutes, automation is not the bottleneck.
- Lead nurture sequence. Trigger: contact enters a list or pipeline stage with no activity for X days. Actions: email → wait → SMS → wait → email. The if/else branches handle reply detection: if a contact replies to any step, remove from the sequence and notify the rep. Running a nurture sequence on a contact who already replied is a trust-damaging mistake that is easy to prevent.
- Appointment booking workflow. Trigger: calendar booking confirmed. Actions: confirmation SMS and email with address or meeting link, 24-hour reminder SMS, 1-hour reminder SMS. If the appointment is not marked as attended within X hours of the appointment time, trigger a no-show re-engagement sequence.
- Post-service reputation workflow. Trigger: opportunity moved to Closed Won or job marked complete. Actions: wait 24 hours, send review request SMS, if no review after 72 hours send email follow-up. The review request links directly to Google Business Profile. This is the workflow that generates Google reviews without manual effort.
Conversation AI Configuration
GHL's Conversation AI is a first-response bot — useful for FAQ handling, appointment booking, and lead qualification, but not a replacement for a human sales conversation. The configuration question is not "how smart can I make this bot?" — it is "at what point does the bot hand off to a human, and how does that handoff work?"
The bot should handle: FAQ responses, calendar booking for discovery calls, and basic qualification questions (budget, timeline, location, service type). When a conversation requires judgment — objection handling, custom pricing, complaint resolution — the bot should exit and assign the conversation to a rep, with a note summarizing what the contact said.
The handoff mechanism in GHL is a workflow trigger on a specific bot-detected intent or keyword, which fires an internal task assignment and a notification to the assigned rep. If the notification goes unread for X minutes, an escalation trigger can fire to a manager or secondary rep.
Integrations and the Limits of Native Connectors
GHL's native integrations cover the obvious stack: Google (Gmail, Google My Business, Google Ads, Google Calendar), Facebook (lead ads, Messenger), Stripe, QuickBooks, and the major calendar providers. For everything else, the integration path is Make (formerly Integromat) or Zapier via webhooks.
GHL webhooks are reliable but require design: outbound webhooks from GHL trigger on contact or opportunity events, and the receiving platform (Make, Zapier) parses the payload and routes accordingly. The design work is in defining which events need to leave GHL and where they need to go. Not every business needs webhook integrations — many GHL accounts can run entirely on native capabilities. But when a client has an existing CRM they are not ready to abandon, or a custom operations tool, the webhook path is the integration mechanism.