GoHighLevel Scope of Work: A Copy-and-Fill Template With Tests

A GoHighLevel scope of work you can copy: deliverables with acceptance tests, exclusions, change rules, handover and milestones, plus how to read the reply.

By Carlos Familia, CRM & AI automation expert. Updated October 16, 2026. 7 min.

An HVAC company in California first hired me for one thing: a phone receptionist that books service calls into a dispatch board. Once that worked, the owner wanted the CRM filled in as well. That second job grew to 25 logic workflows and 39 emails, with 31 workflows active in the end.

The surprises along the way were small, and each one was a decision nobody had written down. The texting registration came back rejected, so texting was put on hold and email led. The owner disliked waits labeled "1440 minutes". Long dashes in the copy came out as garbage characters after passing through a proxy, so every message was redone in plain characters.

A GoHighLevel scope of work needs nine parts: accounts and access, a starting inventory, numbered deliverables with a test each, acceptance rules, things outside the builder's control, exclusions, change rules, a handover and payment milestones. Copy the block below, fill the brackets, and send it before anyone builds.

GOHIGHLEVEL SCOPE OF WORK

1. Accounts and access
- Business: [legal name]. Builder: [name].
- HighLevel agency that holds the sub-account: [business / builder].
  If the builder's: transfer to the business on written request within [10] days.
- Builder works from a user seat with: [list permissions]. No owner login is shared.
- Billing and the wallet card stay with the business.

2. Starting inventory (filled in during week 1, before any edits)
- Workflows: [count]. Active: [count]. Draft: [count].
- Pipelines: [count]. Calendars: [count]. Forms: [count].
- Connected tools: [list]. Texting registration: [not started / pending / approved / rejected].
- Backup taken on [date]. It contains: [configuration snapshot, contacts export, other].

3. Deliverables (each has an acceptance test)
D1. [Outcome, e.g. a new web lead hears back by text and email inside 60 seconds; a rep gets a task.]
    Test: [test contact, lead source, expected result].
D2. [Outcome.]  Test: [...]
D3. [Outcome.]  Test: [...]
Copy: written by [business / builder], approved by [name]. Plain characters only.
Names: waits and workflows in words a staff member would use.

4. Acceptance rules
- Tests run on contacts made for testing. No real customer gets a test message.
- Builder delivers the execution log for every branch and every exit.
- Re-entry is on for: [list]. Same contact tested twice.
- A real booking is made through each calendar link, then cancelled.

5. Outside the builder's control
- Carrier approval of texting. Builder files; no delivery date is promised.
- Until approved: [email first / chat only]. No step cancels anything when a text is not answered.
- Business supplies by [date]: [legal name and tax letter, privacy and terms pages, logo, copy approvals].

6. Not included
- [e.g. ad management, website redesign, new pipelines, AI voice, data entry, anything after D3.]

7. Changes
- Anything not in section 3 is a change request: written, with time and price, before work starts.
- Edits to live workflows happen after a backup and are logged.

8. Handover
- One-page map: folders, workflows, triggers, what each changes.
- Recorded walkthrough, under [20] minutes.
- Test report with logs.
- Fix window: [30] days for defects in D1 to D3. First response within [1 business day].

9. Payment
- M1 inventory and backup. M2 first deliverable. M3 remaining deliverables. M4 handover.
- Each milestone is paid after its tests pass.

How do you fill in the brackets?

Section 2 is a count, not an opinion. How many workflows exist and how many are live, then pipelines, calendars, forms and connected tools. For the backup line, be exact about what it holds. A configuration snapshot does not hold the people in the account, so the line should name a contact export too. My snapshot builder guide lists what a snapshot leaves out.

Section 3 is outcomes, not features. Write what has to be true when it is done. Two lines from the HVAC build show the style:

• A no-show gets a recovery sequence that runs weekly for 12 weeks and exits as soon as the person rebooks, replies or changes stage.
• An estimate follow-up uses a sequence lock field, so two sequences never run on the same contact.

Each line needs a test. For the first, the test is a contact who books and then no-shows: the log shows the week 1 message, and a rebooking ends the loop.

The copy and naming lines look fussy. The naming line exists because of the owner's "1440 minutes" complaint, and the copy line because of the garbled dashes.

Section 4 holds the proof. The booking line catches failures that look like success. On a life insurance build, calendars created through the API had no slug, so the share link opened another company's calendar. A real booking through each link is the cheapest way to catch that before a customer does.

What does a filled-in deliverable look like?

Here is one based on my roofing build in Kentucky, written the way it would sit in section 3:

• D1. A homeowner who replies YES to an inspection reminder is confirmed, and a reply of NO cancels the appointment.
• Test. A test contact books an inspection, replies YES, and the log shows the confirmation. A second test contact replies NO, and the calendar shows the cancellation.
• Dependency. Section 5 applies. Until texting is approved, D1 is built and tested on test contacts only and stays off for real customers.

The example says what must be true, how it is proved, and what it waits on. A reader can tell at a glance why D1 is not live yet, and nobody has to argue about it.

Why is there a section for things outside the builder's control?

Because an acceptance test should never depend on a carrier. Texting needs registration, and HighLevel's brand approval guide says a brand review can take up to 7 business days when the trust score cannot be retrieved. A legal name that does not match the IRS record exactly is one of the rejection reasons it lists.

The scope should separate "built and tested" from "delivered by the carrier". Without that line, a rejected registration turns into an argument about whether the work is finished.

There is a second reason. On the same roofing build I held back a rule that cancelled an appointment when nobody answered a text. Until approval, no text is delivered, so that rule would have cancelled every booking. Section 5 states that rule up front. My notes on GoHighLevel A2P registration list what to prepare.

What does the builder's reply to the scope tell you?

Send the scope and read what comes back line by line.

If three rows land in the right-hand column, stop. The freelancer red flags explain the pattern, and the interview questions help you test the rest.

Is a paid discovery week worth it?

When the account already has history, make the first milestone a paid discovery week: the inventory, the backup and a written fix list. You cannot fill in section 2 until someone has counted, and section 3 gets sharper once they have.

The deliverable is a document, not a build. If the person cannot produce a clear inventory from an account they can already see, I doubt they will produce a clear build. For the full audit pattern, read how I rescue a broken GoHighLevel account.

How do the milestones line up with the scope?

Each payment closes a section of the document, so nobody argues about what "done" means.

The timing is a template. Real projects move with your answers on documents and approvals. If you are still choosing the person, start with the GoHighLevel expert checklist, and compare the money side in how much a GoHighLevel expert costs. After the fix window ends, the next question is GoHighLevel retainer vs project.

About the author

Carlos Familia, CRM & AI automation expert. GoHighLevel, n8n, AI agents, servers. Full-stack developer.

I build CRM systems in GoHighLevel, n8n automations on my own servers and AI voice and chat agents for service businesses. Full-stack developer: I write the workflow, the API integration, the database and the server it runs on, and I test every build with real journeys before handoff.