System Architecture

This is the most important page in the handbook. Everything about how CAPTURE scales — from onboarding a new club to launching 50 — comes back to the Master Snapshot.

Key Links

The Core Idea

All golf clubs are fundamentally the same.

Some are all-singing, all-dancing multi-venue operators — hotel, spa, weddings, restaurant, health club, golf. Others are traditional members clubs with 18 holes and a bar. But the underlying departments, enquiry types, and operational needs are shared across every single one.

That's why the system works. We don't rebuild CAPTURE from scratch for each club. We maintain one living template — the Master Snapshot — and deploy it to every new client. The more we improve that template, the faster and better every future launch becomes.

Work is never duplicated unnecessarily. If something gets built for one client and it's universally useful, it goes back into the Master Snapshot so no one ever has to build it again.

Two Things Must Stay In Sync

The entire operation depends on two things being perfectly mirrored:

1. The GHL Master Snapshot

This is the actual GoHighLevel sub-account called Capture Master Snapshot. It contains:

• All standard pipelines and stages
• All pre-built forms and their connected automations
• All email templates and SMS sequences
• All custom fields, tags, and custom values
• All workflow automations (staff alerts, confirmation emails, follow-up sequences)

When we launch a new client, we load this snapshot into a fresh sub-account. Everything comes across — pipelines, forms, automations, the lot. The new club starts with a fully working system from day one.

2. The Master Google Spreadsheet

Open the Master Spreadsheet

This is the documentation layer. It catalogues every single thing inside the snapshot:

• DNS record templates
• Every tag (with category and purpose)
• Every custom field (with type, allowed values, and which forms use it)
• Every custom value (club name, phone, staff names, brochure URLs, etc.)
• Every pipeline and its stages
• Every form
• Every email template
• Every conversation snippet
• Every Smart List
• Staff/user management structure
• Booking calendars

The spreadsheet must mirror the snapshot to the letter. If a tag exists in the snapshot, it's in the spreadsheet. If a custom field is in the spreadsheet, it's in the snapshot. No exceptions.

When we onboard a new client, we duplicate this spreadsheet and update it with their specific details. That becomes their client-specific record — the single reference for what's in their account.

Why both?

The snapshot is the thing that actually deploys. The spreadsheet is how humans track what's in it. You can't easily diff a GHL account against a previous version. The spreadsheet gives you that visibility.

If they drift apart, you lose the ability to trust either one.

Form Protocol

This is where things have gone wrong in the past. Freelancers build forms from scratch instead of using the ones in the snapshot. That breaks the automations connected to those forms and creates hours of rework.

The rule

If the form already exists in the Master Snapshot: Do not build it from scratch. Load it into the client's account and only update the CSS styling and copy. The underlying automation workflows stay intact.

If the form has never been built before: Build it from scratch. But once it's built and QA tested, add it to the Master Snapshot and log it in the Master Spreadsheet. No one should ever have to build that form again.

The end goal

There are perhaps 50 distinct forms a golf club could ever need. Contact us, membership enquiry, society booking, wedding enquiry, brochure downloads, newsletter sign-up, lesson booking, green fee enquiry, corporate event — and variations of each.

The objective is to have all 50 pre-built, fully functional, and stored inside the Master Snapshot. We're not there yet. There's a core set of fully functioning forms, plus a backlog of around 15 that were built recently and are in the snapshot but still need QA and tidying up.

Every form you build properly and add to the snapshot gets us closer to the point where launching a new client is purely configuration — no building.

Why this matters

Each form is connected to an automation. That automation:

1. Creates or updates the contact record
2. Applies the correct tags (source, interest, compliance)
3. Creates an opportunity in the right pipeline
4. Sends the customer a confirmation email
5. Sends the relevant staff member a notification

If you rebuild the form from scratch, none of those connections exist. You have to rewire the entire automation. That's hours of work and a high risk of something being missed — which means notification emails go nowhere and the club loses business.

Custom Field Rules

All custom fields must be uniform across every single account. This is non-negotiable.

The problem

When freelancers don't follow the rules, you end up with multiple custom fields doing the same thing. One form uses "Message" for the enquiry message. Another form uses "Customer Message". A third uses "Enquiry Details". Now you've got three fields tracking the same data, none of your filters work properly, and reporting is broken.

The rule

Every form that requires a message must use the exact same Contact Message custom field. Every form that captures a membership type must use the exact same Membership Type custom field. Every address, every city, every phone number — standardised.

The Master Spreadsheet defines what these fields are, what type they are (text, dropdown, checkbox, etc.), and what their allowed values are. If you're building or editing a form, check the spreadsheet first.

Adding new custom fields

If you genuinely need a new field that doesn't exist:

1. Check the Master Spreadsheet to confirm it doesn't already exist under a different name
2. Add it to the spreadsheet first (define the name, type, allowed values, and which folder it belongs to)
3. Add it to the Master Snapshot in GHL
4. Then deploy it to client accounts as needed

Never add a field to a client account without adding it to the master first. That's how drift starts.

Client Onboarding Flow

The trigger

In the GHL Albatross account, moving a prospect to "Sale" in the Golf Club Sales pipeline triggers the onboarding automation. This sends the client two onboarding forms to collect their details.

Data collection

The client fills out the two onboarding forms. The data pushes into ClickUp, generating a new profile in the Client Info list (ClickUp workspace: Capture Ops > Ops and Clients > Client Directory).

Environment creation

Two things happen concurrently:

1. Spreadsheet: Duplicate the Master Google Spreadsheet. Update it with the new client's details from the onboarding forms — staff names, contact details, brochure URLs, custom values, etc.
2. Snapshot: Load the GHL Master Snapshot to create the client's sub-account.

Configuration

With the sub-account live and the spreadsheet updated:

1. Update custom values with the client's specific details
2. Create user accounts for their staff
3. Select which forms the client needs and style them (CSS and copy only)
4. Embed forms on the client's website
5. Set up DNS records for email sending (SPF, DKIM, DMARC)
6. Activate workflows
7. Run QA (see below)
8. Deliver training
9. Capture the first real enquiry

A club is considered live once all steps are complete and the first real enquiry has been captured.

Keeping the client spreadsheet current

When you make changes to a client's account — adding new tags, new forms, new custom fields — update their spreadsheet. When Rae or anyone else adds client-specific tags (like Cottesmore-specific interest tags), those go into the client's spreadsheet, not the master.

If a change is universally useful and should apply to all future clients, it also goes into the Master Snapshot and Master Spreadsheet.

Quality Assurance

QA is critical. Half-finished setups mean notification emails route incorrectly, which directly loses business for the club. If their events team doesn't get the notification when someone enquires about a wedding, that's a lost booking.

The process

For every client launch, before going live:

1. Add a test email to the notification settings for every department
2. Fill out every form through every possible route — every enquiry type, every department, every option in every dropdown
3. Verify receipt — check that the test email arrived for each route
4. Contact the client's departments directly — email each department (pro shop, events, membership, spa, etc.) and explicitly ask them to confirm they received the test submission
5. Log the results — tick off each department as confirmed in the client's spreadsheet

What you're checking

For each form submission:

• Contact record created correctly in GHL
• Correct tags applied (source, interest, compliance)
• Opportunity created in the correct pipeline
• Customer confirmation email sent and received
• Staff notification email sent to the correct department
• Custom field data mapped correctly

The forms backlog

The Master Snapshot currently contains a batch of forms (built around January) that are in the system but haven't been QA checked or added to the Master Spreadsheet. These need to be worked through — tested, tidied up (CSS and copy), and either promoted to the master list or removed.

Auditing the Snapshot

The Master Spreadsheet and the GHL Snapshot can drift apart — especially when multiple people are making changes or when work gets interrupted. Regular audits catch this before it causes problems.

How to audit

1. Open the Master Google Spreadsheet
2. Open the GHL Capture Master Snapshot sub-account
3. Go through each tab line by line:

4. For every item: confirm it exists in both places, with the same name and configuration
5. Fix discrepancies directly in GHL if you're confident. If you're not sure, flag it on Slack and ask before changing anything.

When to audit

• Before every new client launch — you need to trust that what you're deploying is correct
• Monthly — as a general hygiene check
• After any batch of changes — if forms have been added or fields changed, verify the sync

How This Scales

Today we have around 10 clients. The backlog has 3-4 more waiting to be onboarded. The goal is to get to a point where launching a new club takes days, not weeks.

The more complete the Master Snapshot becomes — more forms, more automations, more email templates — the less work each new launch requires. Eventually, onboarding a new club is:

1. Duplicate the spreadsheet
2. Load the snapshot
3. Update the custom values
4. Style the forms
5. QA test
6. Go live

No building. No automation wiring. No custom field creation. Just configuration.

That's the whole point. Every hour spent improving the Master Snapshot pays dividends across every future client.