Intern
What you actually do
Day one: decide if brands share a sub-account or not. If they share, brand is a required field on every write-in. List assets per brand. Do not send a campaign until from-name is mapped.
Library / franchise systems / Multi-brand CRM
Licensed models fail when the snapshot is a zip file and a prayer.
Read it once, then stop negotiating with it. Multi-brand CRM for licensed coaching systems is a wiring job: see it → spec it → install it → review it. Objects, then edges, then one test conversion. You do not need a new tool to start. You need the first writer to land on one contact this week.
Licensed coaching systems do not have a Multi-brand CRM problem because they lack GoHighLevel. They have it because two brands share a database and contaminate both.
Wire these objects first: Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*.
Then these edges, in order: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B · Email/SMS from-name and domain → match brand field; assets do not leak · Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view · Staff user → permission to their brand's calendars and conversations only
Done looks like a test you can repeat: Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar.
Start here: Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
Licensed coaching systems already have GoHighLevel. The leak is not a missing feature. Two brands share a database and contaminate both. Software did not cause it. A missing write-in did: the person exists in one tool and not in the pipeline.
Here is how you actually wire it. Name the objects: Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*. Then connect these edges, in order: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B · Email/SMS from-name and domain → match brand field; assets do not leak · Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view · Staff user → permission to their brand's calendars and conversations only. If you skip an edge, the next one is decoration. If you add a GoHighLevel feature first, you usually skip an edge without noticing.
Prove it with a test, not a screenshot. Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar. How you know it worked on the board: Owner is named (or it will not run). If that number is a vibe, do not add traffic.
What to do this week, and only this week: Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched. An intern can run the objects page and one test conversion. A CEO should protect that from a second priority.
Intern
Day one: decide if brands share a sub-account or not. If they share, brand is a required field on every write-in. List assets per brand. Do not send a campaign until from-name is mapped.
Operator
You already feel two brands share a database and contaminate both. Licensed models fail when the snapshot is a zip file and a prayer. Protect one sequence for 90 days. The four moves are see it → spec it → install it → review it. The edges are Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B then Email/SMS from-name and domain → match brand field; assets do not leak. Training is part of rollout, not a Zoom after go-live.
CEO
This is a money leak, not a preference about tools. HQ has a beautiful snapshot. Until owner is a number you will defend, buying more traffic or more seats makes the leak more expensive. Refuse a second database: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B.
Before
Tuesday. Someone among licensed coaching systems. Licensed models fail when the snapshot is a zip file and a prayer. GoHighLevel is open. A colleague asks where a person sits. The answer is a screenshot, a Slack thread, or “I think they’re interested.” The writer (form, calendar, shop, or phone) and the pipeline are two databases.
After
Same Tuesday, after write-in exists. Training is part of rollout, not a Zoom after go-live. Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B The next move is written. That is the difference between a login and a system.
Keep it this plain. A person in licensed coaching systems already paid for GoHighLevel. Licensed models fail when the snapshot is a zip file and a prayer. They add a page, a form, a calendar. None of it writes into a spec. By Friday the calendar has ghosts and the pipeline still looks like the snapshot.
The fix is not a better template. Lock the core at HQ: pipelines, tags, routing, brand assets, definitions. Prove write-in: Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar. This week is one move: Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched. If that feels too small, that is the point. Operators fail by starting at move four.
The leak
HQ has a beautiful snapshot. Locations have WhatsApp. Updates break someone every quarter. Reporting is a negotiation. That is not multi-location. That is a zip file with extra steps.
The system
Lock the core at HQ: pipelines, tags, routing, brand assets, definitions. Allow local exceptions on purpose, named as local. Roll out through a real pilot, with training inside the snapshot, not a Zoom after.
If locations can edit the sacred pieces, they will, and you will not know. Governance is the product: change log, breaking vs safe, notify, rollback. Speed-to-lead is a number. Stolen leads are visible. Otherwise culture is just drift.
Brand is a first-class field. Assets do not leak.
Training is part of rollout, not a Zoom after go-live.
Two brands sharing a database contaminate both when brand is not a first-class object. A field plus a tag, required at write-in, on every form and calendar. Assets — templates, calendars, phone numbers, domains — are listed per brand. A 'quick' reuse of brand A's webinar page for brand B is how you email the wrong from-name. Reporting splits cleanly. A blended dashboard is allowed at HQ only if it is labeled blended.
Staff permissions match brand. A closer for brand A should not live in brand B's Conversations. Workflows enroll on brand tag, not on 'all contacts'. Pipelines can be separate or one pipeline with brand as a field — pick one and write it. Separate pipelines are cleaner for ops; one pipeline is cleaner for a tiny team. Either way, Won for brand A must not inflate brand B.
Two databases already: two brands pretending to be one. The failure mode is a third: a spreadsheet of 'which list is which'. The intern tests both forms the same afternoon. If a contact has no brand, it cannot be emailed. Make that a hard stop in the workflow, not a hope. Contamination is not a branding problem. It is a missing field.
Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*.
Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B
Email/SMS from-name and domain → match brand field; assets do not leak
Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view
Staff user → permission to their brand's calendars and conversations only
Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar.
Day one: decide if brands share a sub-account or not. If they share, brand is a required field on every write-in. List assets per brand. Do not send a campaign until from-name is mapped.
Brand is a first-class field
Assets do not leak
Reporting splits cleanly
Staff permissions match brand
On one line, for licensed coaching systems: Two brands share a database and contaminate both. Add who gets hurt (calendar, cash, inbox, or reputation). If two people write different sentences, you do not agree yet — stop and agree.
Why: Teams skip this and jump into settings. Then every person is fixing a different problem with the same login.
Done when: One sentence. Shared. No adjectives required.
Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*.
Why: If objects aren't named, software invents a second database.
Done when: A stranger can list them.
Brand is a first-class field Then wire: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B
Why: Licensed coaching systems cannot skip this edge. Two brands sharing a database contaminate both when brand is not a first-class object. If it is not true, GoHighLevel is already a second database.
Done when: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B is true on a test.
Assets do not leak Then wire: Email/SMS from-name and domain → match brand field; assets do not leak
Why: Licensed coaching systems skip this and the leak returns as a private language. Staff permissions match brand. Spec tags, fields, and states have to be the same objects the next workflow will read.
Done when: Email/SMS from-name and domain → match brand field; assets do not leak is true on a test.
Reporting splits cleanly Then wire: Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view
Why: Licensed coaching systems feel this as Two brands share a database and contaminate both. Two databases already: two brands pretending to be one.
Done when: Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view is true on a test.
Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar.
Why: Calendar full + pipeline empty means two databases.
Done when: One test conversion, one contact, right stage/state.
Every Monday, look at Owner (Or it will not run), then weekly number (Or reporting is theatre). Write one action or write “hold.” A dashboard with no action is theatre.
Why: What gets reviewed gets run. What only lives in a tool gets ignored the week someone is busy.
Done when: Three numbers. One owner. Fifteen minutes. Actions attach.
Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
Why: Operators fail by starting at move four. Interns fail by making a 40-item checklist. CEOs fail by adding a second priority. One proven write-in beats an elegant plan.
Done when: The move is true, or you can name the blocker in one sentence.
Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*.
If objects aren't named, software invents a second database.
Licensed models fail when the snapshot is a zip file and a prayer.
Brand is a first-class field Then wire: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B
Licensed coaching systems cannot skip this edge. Two brands sharing a database contaminate both when brand is not a first-class object. If it is not true, GoHighLevel is already a second database.
On GoHighLevel, this means the data model matches how licensed coaching systems actually work — not the snapshot demo. Edge: Email/SMS from-name and domain → match brand field; assets do not leak
Assets do not leak Then wire: Email/SMS from-name and domain → match brand field; assets do not leak
Licensed coaching systems skip this and the leak returns as a private language. Staff permissions match brand. Spec tags, fields, and states have to be the same objects the next workflow will read.
Training is part of rollout, not a Zoom after go-live.
Reporting splits cleanly Then wire: Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view
Licensed coaching systems feel this as Two brands share a database and contaminate both. Two databases already: two brands pretending to be one.
day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
Because the login already exists. HQ has a beautiful snapshot. Locations have WhatsApp. A new feature on a missing spec is a second database. Finish this edge first: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B.
Day one: decide if brands share a sub-account or not. If they share, brand is a required field on every write-in. List assets per brand. Do not send a campaign until from-name is mapped. Workflows on unnamed objects fire on folklore. Name contact (or profile), stage or state, and the writer (form, calendar, metric) before any on-switch.
A test conversion creates or updates one person, on the right stage or state, with the fields the next sequence will read. Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar. If you merge after the test, identity is wrong — fix that, do not add a dedupe automation.
If it is only in someone's head, a new hire needs a story, reporting cannot be defended, and automations fire on folklore. Writing is how two people mean the same object on Monday.
Because setup was a project, not a review. Stop rule (Or you will scale the leak) is how you stop the leak returning dressed as a new feature. If locations can edit the sacred pieces, they will, and you will not know. Governance is the product: change log, breaking vs safe, notify, rollback. Speed-to-lead is a number. Stolen leads are visible. Otherwise culture is just drift.
More leads into a leak is a more expensive leak. Training is part of rollout, not a Zoom after go-live. Watch owner before you buy traffic. If that number is folklore, acquisition is a vanity spend.
Then you only have time for the objects page and one test conversion. Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched. That is the intern version of strategy. Protect it from a second priority for seven days.
Skip this
Leaving objects unnamed because GoHighLevel is “set up”.
Do this
Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*.
Skip this
Building a workflow or flow before a writer lands on one contact.
Do this
Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B
Skip this
Calling it done because a screenshot looks busy.
Do this
Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar.
Skip this
Leaving “Review it” to chance.
Do this
Staff permissions match brand
The usual miss
Calling GoHighLevel “set up” because someone logged in and imported a snapshot.
Do this instead
Brand is a first-class field Then prove write-in: Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline.
The usual miss
Building the workflow or flow before the writer (form, calendar, shop event) lands on one contact.
Do this instead
Connect Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B first. Automations on a missing writer invent a second database.
The usual miss
Adding a page, form, flow, or campaign every time last week hurt.
Do this instead
Name which edge is missing. Fix that edge. Hurt is usually a skipped write-in, not a missing asset.
The usual miss
Reporting that nobody will defend in a meeting — screenshots, vanity opens, 'interested' counts.
Do this instead
Owner: Named. Or it will not run. If you cannot say it out loud, it is not a scoreboard.
The usual miss
Hiring or retaining an agency to invent the spec while also running the calendar.
Do this instead
Hands on a known sequence are useful. Hands inside a missing spec pick the louder job (the calendar) and the leak stays.
Owner
Named
Or it will not run
Weekly number
Believed
Or reporting is theatre
Stop rule
Written
Or you will scale the leak
This week
day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
UK operators · UK hours. The CRM is often inherited from an agency; the spec still has to be written here.
Brand is a first-class field
Assets do not leak
Reporting splits cleanly
Staff permissions match brand
Want the longer lesson, not the page for this niche? A CRM login is not a system ↗
Working notes
What HQ should lock, what locations can change, and how rollout actually works. Request the file. It arrives by email — not a public dump, not a drip of slogans.
Licensed coaching systems do not have a Multi-brand CRM problem because they lack GoHighLevel. They have it because two brands share a database and contaminate both. Wire these objects first: Brand as first-class custom field, separate assets (forms, calendars, from-names), contact, pipeline per brand or brand+stage, permissions, reporting split, tag brand:*. Then these edges, in order: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B · Email/SMS from-name and domain → match brand field; assets do not leak · Pipeline filter / reporting → splits on brand; blended 'all brands' is an HQ-only view · Staff user → permission to their brand's calendars and conversations only Done looks like a test you can repeat: Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar. Start here: Day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
HQ has a beautiful snapshot. Locations have WhatsApp. Updates break someone every quarter. Reporting is a negotiation. That is not multi-location. That is a zip file with extra steps. Training is part of rollout, not a Zoom after go-live.
Before: Tuesday. Someone among licensed coaching systems. Licensed models fail when the snapshot is a zip file and a prayer. GoHighLevel is open. A colleague asks where a person sits. The answer is a screenshot, a Slack thread, or “I think they’re interested.” The writer (form, calendar, shop, or phone) and the pipeline are two databases. After: Same Tuesday, after write-in exists. Training is part of rollout, not a Zoom after go-live. Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B The next move is written. That is the difference between a login and a system.
Leaving objects unnamed because GoHighLevel is “set up”. Building a workflow or flow before a writer lands on one contact. Do the four moves instead: see it → spec it → install it → review it.
Owner: Named — Or it will not run. Then weekly number (Or reporting is theatre). If those are folklore, do not add another GoHighLevel workflow.
day-1 checklist for licensees. Sample pipeline preloaded. HQ sees who actually launched.
Because the login already exists. HQ has a beautiful snapshot. Locations have WhatsApp. A new feature on a missing spec is a second database. Finish this edge first: Form on brand A → contact brand field A + tag brand:a; never a silent default to brand B.
Day one: decide if brands share a sub-account or not. If they share, brand is a required field on every write-in. List assets per brand. Do not send a campaign until from-name is mapped. Workflows on unnamed objects fire on folklore. Name contact (or profile), stage or state, and the writer (form, calendar, metric) before any on-switch.
A test conversion creates or updates one person, on the right stage or state, with the fields the next sequence will read. Submit brand A's form and brand B's form with the same test email if you must share a database — confirm brand field, from-name of the first email, and pipeline. Send a test SMS: the wrong brand name is a fail. A brand-A user must not see brand-B's calendar. If you merge after the test, identity is wrong — fix that, do not add a dedupe automation.
If it is only in someone's head, a new hire needs a story, reporting cannot be defended, and automations fire on folklore. Writing is how two people mean the same object on Monday.
The CRM is open. The operating system is not.
Read ↗Stages are labels. Nobody knows what 'won' requires.
Read ↗Tags multiply. Insight does not.
Read ↗The quiz converts. The follow-up is a spreadsheet.
Read ↗Traffic hits a page. The journey after that is improvised.
Read ↗Email and WhatsApp stay open. A call is for installing the system — not for a tour of tools.