Guide 3 of 3 · Client Ready

Client Ready: How to onboard a client without making them the test case.

Client setup comes after your own system works. This guide covers repeatable client delivery — intake, verification, sub-account setup, QA, handover and support boundaries.

Client Ready is not "I got a sale"

Getting a client and being ready to onboard a client are different things. Getting a sale before your delivery process exists means you will build it in front of the person paying you.

The client should feel like they are entering a process, not becoming your experiment.

This guide assumes you have completed Agency Ready and Sales Ready. If you have not, start there.

The client should feel like they are entering a process, not becoming your experiment.

1. The client intake pack

Before you start work, you need specific information from the client. Define this before the first client pays — not the day they do.

Business details Legal business name, ABN (AU), trading name, industry, primary contact. Required for GHL sub-account setup and any compliance docs.
Domain details Their primary domain, DNS provider login (or willingness to delegate DNS management), and any existing subdomains in use.
Existing accounts to connect Google Business Profile, Facebook Page, existing email accounts, payment processors. Access details or admin invitations required before you can connect them.
Communication channels Which channels they will use: email, SMS or both. Their preference for how clients reach them and how they want to send.
Goals and scope confirmation Written confirmation of what the engagement covers and what it does not. Both parties sign off before work starts.

2. Client verification docs (AU)

In Australia, several GHL features require documentation before setup. Know what is needed before onboarding day.

Regulatory Compliance Bundle Required for purchasing a GHL phone number in Australia. The client must provide proof they are a legitimate business user of that number. Collect this before purchasing the number.
SMS Sender ID registration (if applicable) If the client will use a branded SMS sender ID, they must register it on the ACMA Sender ID Register (from 1 July 2026). This takes time — start early.
Email consent documentation How the client's contact list was collected, when, and under what consent. Required before importing any list into GHL.
Privacy policy on client website The client must have a privacy policy that covers how data collected through GHL forms is used. Check before building forms.

3. Client domain plan

Each client sub-account needs its own domain strategy. Use a consistent pattern across all clients.

Purpose Example
Client website clientdomain.com.au
Campaign / landing pages go.clientdomain.com.au
Branded system links ops.clientdomain.com.au
Email sending domain send.clientdomain.com.au
Client portal (if used) portal.clientdomain.com.au

Cloudflare and Domain Connect: Where the client's domain is on Cloudflare, GoDaddy or Google Domains, HighLevel's Domain Connect can automate much of the DNS setup. For other providers, manual DNS configuration is required. Either way, agree on who owns and manages the client's DNS before starting.

4. Sub-account build checklist

Create sub-account in agency account Under your own agency GHL account. Client has a sub-account — you own the agency account.
Connect and verify sending domain Set up SPF/DKIM/DMARC for the client's sending subdomain. Verify before sending any email.
Set up branded links Configure the API/branded domain for the client sub-account — Trigger Links, calendar links and form URLs on the client's subdomain.
Calendar connected and tested End-to-end booking test completed for the client's calendar before going live.
Pipeline configured Client-specific pipeline stages that match their sales process.
Phone / SMS configured (if applicable) Number purchased, Regulatory Compliance Bundle submitted and approved (AU), opt-out messaging in place.
Payments connected (if applicable) Stripe or payment processor connected and tested with a real or test transaction.

5. Permissions and access model

Decide what access clients get in their sub-account before creating it. This is much harder to change after the fact.

Client user roles Which roles and permissions clients (and their staff) will have. Admin, standard user, limited view — decided before you create their login.
What clients can and cannot change Automations, workflows, contacts — define which areas are client-accessible and which you manage exclusively.
Billing and usage ownership Who pays for GHL usage costs (SMS, email, phone numbers). Documented in the client agreement before setup.

6. Launch QA script

Before anything goes live for a client, run through this checklist. If you do not have a written QA process, you are doing QA in front of the client.

All landing page links open and load correctlyOn desktop and mobile.
Form submission fires correctlyTest contact appears in CRM. Automations trigger as expected.
Calendar booking end-to-end testBooking, confirmation email, calendar entry and reminder all confirmed.
Follow-up sequence reviewedEvery message checked for content, timing and personalisation tokens.
Email inbox placement testTest email lands in inbox, not spam.
SMS test (if applicable)Test SMS received with correct sender ID and opt-out language.
Payment test (if applicable)Test transaction completed and refunded.
All branded links on client domainNo default GHL links in any live asset.

7. Handover pack

At the end of the engagement, what does the client receive? Document this before you start the engagement.

Sub-account access Client has their own login. They can access their account independently of you.
Documentation of what was built A written description of every asset delivered: pages, workflows, pipelines, automations. What each one does and where to find it.
Credentials and access log List of all connected accounts, where to find login details, and any credentials stored on behalf of the client.
What happens next What is included in ongoing support (if any), what is not, and how the client reaches you for help.

8. Support boundaries

Define your support terms before you take money. Ambiguity here becomes conflict later.

What is included Specific support you provide: bug fixes, minor changes, responses to questions about what was built.
What is not included New features, changes to scope, GHL platform issues outside your control, training beyond what was agreed.
How to reach you One channel. Response time expectation. Not "you can message me anytime."
When support ends If the engagement has a fixed term, when does included support expire? What replaces it?

All three stages

Know which stage you're on? Step Zero tells you.

Take the three-stage check and get a four-column action map — specific to where you are in the ready-to-trade sequence.

Take the Step Zero Check Get the Ready-to-Trade Toolbox