The per-client config template: how senior GHL operators answer 80% of tickets in under 90 seconds

The single highest-leverage document a GoHighLevel whitelabel agency can build is not an SOP. It is not a playbook. It is a one-page per-client configuration sheet, kept current and accessible to every operator on your team.

The right per-client doc lets a senior GHL operator answer 80% of incoming tickets in under 90 seconds, with no context-rebuild and no founder escalation. Without it, every ticket starts with 10 minutes of digging through previous Slack threads, old onboarding notes, and the client's actual sub-account to figure out what they are running.

Here is the template that works, the fields that actually matter, and how to keep it current without it becoming a chore.

Why a generic CRM record is not enough

Every GHL whitelabel agency already has client records somewhere. HubSpot, GHL itself, Notion, Airtable, a Google Sheet. So why does ticket-answering still start with 10 minutes of digging?

Because the existing records track sales-relevant data (contact info, deal stage, MRR) but not support-relevant data (what snapshot, what custom workflows, what known issues). The support team needs a different shape of record.

The support-relevant record needs to answer four questions in 90 seconds:

1. What is this client running? (snapshot version, custom workflows, integrations)
2. What is their current state? (active campaigns, A2P registration status, throughput tier)
3. What history do we have? (last 3 escalations, recurring issues, custom decisions we made)
4. Who do we talk to? (primary contact, backup contact, communication preferences)

If your existing records do not answer all four, you need a per-client config doc.

The 12-field template

Here is the template, field by field. Each one earns its place because it shows up repeatedly in actual ticket answering.

=== [CLIENT NAME] · GHL Whitelabel Configuration ===

1. Sub-account ID: [GHL location ID]
2. Snapshot: [name + version, e.g., "Coach v3.2"]
3. Onboarded: [date]
4. Primary contact: [name + email + preferred comm method]
5. Backup contact: [name + email]

=== Active configuration ===

6. Active campaigns: [list of running automations]
7. A2P 10DLC: [brand status + campaign(s) + throughput tier + renewal date]
8. Custom workflows: [list of workflows that diverge from the snapshot]
9. Integrations: [Stripe / Calendly / Zapier / etc., with credential ownership]

=== Operational state ===

10. Last 3 escalations: [date + issue + resolution]
11. Known issues: [open items we are tracking]
12. Custom decisions: [non-standard things we agreed to do for this client]

That is the entire template. It fits on one screen. It reads in 90 seconds.

Why each field earns its place

Snapshot version and onboarding date let an operator immediately understand what this client is running and how stale that version might be. If you fix a snapshot bug today and this client was onboarded 8 months ago, they probably don't have the fix yet. Snapshot debugging at scale gets dramatically easier when you can answer “which clients are on which version” in seconds.

Active campaigns + A2P status is the single most-asked information in any GHL ticket. “Why isn't my SMS sending?” usually answers itself once you see the A2P registration is mid-renewal.

Custom workflows is the field most agencies forget. Over time, every long-running client accumulates customizations: workflows that diverge from the base snapshot. A new support engineer who doesn't know about these will give wrong answers based on the base snapshot.

Last 3 escalations is what separates a per-client doc from a CRM record. It is the conversational memory. When a client says “we had this issue last quarter,” the operator can verify the issue, the resolution, and what changed.

Known issues + custom decisions are the two fields that absorb tribal knowledge. The decisions that “we agreed in a call to handle this differently for them.” The bugs that “we have a workaround for, do not try to fix again.” Without this field, every new operator re-investigates problems that were already resolved.

The maintenance workflow

The config doc only works if it stays current. Most agencies build the doc, populate it at onboarding, and then never update it. Three months later it is wrong about three things and untrusted by the support team.

The pattern that keeps it current:

Trigger 1: every escalation updates the doc. When the POL or senior operator handles a Tier 2 or Tier 3 ticket, the last step of resolution is updating the “Last 3 escalations” field. This is part of the ticket workflow, not an optional admin task.

Trigger 2: every custom workflow change updates the doc. When the team builds a new automation for a client or modifies an existing one, the “Custom workflows” field gets updated. This requires a checklist item in your workflow-build SOP.

Trigger 3: monthly review. Once a month, every client config gets a 5-minute eyeball check. Renewal dates updated, stale “known issues” removed, contacts verified. This takes 5 minutes per client. At 100 clients, that is 8 hours a month, which is a half-day for one operator. Worth it.

Where this lives

Three reasonable homes:

Option 1: Notion database. One database, one record per client, with the 12 fields. Easy to share, easy to template, easy to filter. Most agencies we work with land here.

Option 2: GHL custom fields on the sub-account. Lives where the rest of the client data lives. Harder to read at a glance because GHL's custom-field UI was not designed for this.

Option 3: Airtable. Most flexible filtering and views (e.g., “show me all clients on Snapshot v3.x with A2P renewal in next 30 days”). Some learning curve.

For most agencies under 200 clients, Notion is the right pick. The data model is simpler than what Airtable optimizes for, and the readability is better than what GHL offers.

What this enables

Once the per-client config doc is in place and current:

• Tier 1 VAs can answer routine tickets without escalating
• New operators come up to speed on a client in 90 seconds, not 90 minutes
• The founder stops being asked “quick question, what does this client run?” in Slack
• Snapshot bugs get triaged across the client base in minutes
• Renewals happen on schedule because the dates are visible
• Churn risk becomes legible because last-3-escalations patterns show up

This is the operational document that distinguishes agencies that scale past 100 clients from agencies that hit the wall and stall.