A GoHighLevel setup checklist for home service businesses.

This checklist is deliberately usable by someone configuring their own account. Nothing in it is a secret, and none of it requires an agency. What it does require is that a set of operating decisions is made before any toggle is touched — because most of what goes wrong in a GoHighLevel build is not a mis-set option, it is an option set to represent a rule nobody had agreed.

The distinction that runs through the whole list: a BUSINESS RULE is something the company decides and would still be true on a different platform. A PLATFORM SETTING is where that rule is recorded here. Rules survive migrations. Settings do not.

Aevrion does not resell GoHighLevel, takes no platform commission, and holds no HighLevel certification, partnership or reseller status. Where this article describes platform behaviour it cites HighLevel's own documentation, listed at the end.

Write the answers down somewhere outside the platform. If the account is ever rebuilt, migrated or handed to someone else, this document is the thing worth keeping.

• Lead sources

  Every route by which an enquiry can arrive — phone, web form, chat, marketplace, referral, the number on the van. List them all, including the ones that currently reach a personal mobile, because those are the ones that vanish from every report.

• Pipeline states

  The states an opportunity can occupy, each verifiable from the record by somebody who was not on the call. If two people would place the same job differently, the state is not defined yet.

• Owner rules

  How each opportunity gets exactly one named owner, and what happens when that person is on a roof, on leave or has left. A rule that can resolve to nobody is the rule that loses work.

• Response expectations

  What a caller, a form submission and an after-hours enquiry should each receive, and within what time. This decides which automation is necessary, not the other way round.

• Urgency classification

  What separates an emergency from a scheduled job from a quote request. Each one deserves a different speed and often a different person.

• Estimate states

  What a quote can be: sent, viewed, discussed, awaiting a decision, awaiting finance, accepted, declined, deferred with a date. Deferred without a date is the state that silently becomes lost.

• Stopping conditions

  What ends or changes an automated sequence — a reply, an acceptance, a decline, a request for time, an opt-out. Decide these before choosing any cadence.

• Handoff points

  Where the system stops and a person takes over, with the context already assembled. Pricing an awkward job and handling a complaint are on this list.

• The three numbers you will act on

  Not a dashboard. The small set of figures that would actually change a decision this month — usually where work comes from, what is sitting unowned, and what stalled after a quote.

The mapping below is the checklist proper. Read the middle column first. The right-hand column is only where the answer is stored, and it is the column that changes when the platform changes.

Sending text messages from a standard ten-digit US number is not a setting you switch on. HighLevel documents that A2P 10DLC registration is required, and that it has two parts: a Brand, which identifies the business to the carriers, and a Campaign, which describes the kind of messages it will send. The submission happens through the platform's Trust Center, but HighLevel is explicit that approval is decided by the US carriers and their registration partners, not by HighLevel.

Two practical consequences for a home service business. First, this takes time and can be rejected, so it belongs at the start of a project rather than the week before launch. Second, the consent story you describe during registration has to match what the business actually does — the opt-in language on the form, the messages that follow, and the way opt-outs are handled are one system, not three separate tasks.

Consent then has a home in the platform. HighLevel's DND settings can be applied globally or per channel, its documentation states that a contact replying with an opt-out keyword such as STOP or UNSUBSCRIBE enables DND, and a contact marked DND is excluded from receiving communications on the channels their DND settings name. Treat that as the floor rather than the strategy: the useful question is not whether the platform will stop a message, but whether the business would be comfortable explaining why it was sent.

Messaging rules, consent requirements and record-keeping obligations vary by jurisdiction and by how a business acquires its contacts. This is an operating description, not legal advice — confirm your obligations with qualified counsel and with your messaging provider.

The order matters for a mundane reason: several of these steps reference the ones above them. A workflow cannot route to an owner before ownership is defined, and a report cannot be built before the stages exist.

1. 01

   Account and sub-account structure

   Decides

   Whether this business is one account or several, and who has access to what.

   Output

   A structure that matches how the business is actually run, with user roles assigned on least-required access.

2. 02

   Contact and field architecture

   Decides

   What a contact record must carry before anyone can act on it.

   Output

   A field set where every required field has a decision attached, and nothing exists because it might be useful later.

3. 03

   Pipeline and stages

   Decides

   The observable states an opportunity moves through.

   Output

   A pipeline whose stages a second person can verify from the record alone.

4. 04

   Ownership and assignment

   Decides

   The rule that produces one named owner, and its fallback.

   Output

   Assignment configured on creation and maintained on stage change, with no path that resolves to nobody.

5. 05

   Capture — forms and inbound channels

   Decides

   How each lead source becomes a structured record with its origin attached.

   Output

   Every listed source landing in the account without retyping, source intact and testable.

6. 06

   Phone, voicemail and missed-call response

   Decides

   What a missed caller receives, and how repeat calls are handled.

   Output

   Missed-call response configured, with the duplicate behaviour handled deliberately rather than discovered later.

7. 07

   Calendars and booking

   Decides

   What can be booked, by whom, with what notice and buffer.

   Output

   Calendars that cannot produce a booking the business is unable to serve.

8. 08

   Workflows and stopping conditions

   Decides

   Which sequences exist, what each is for, and what ends it.

   Output

   Workflows whose exit conditions were written before their message content.

9. 09

   Estimates, reviews and reactivation

   Decides

   What happens after a quote, after a completed job, and after a deferred decision.

   Output

   Three sequences with owners and stopping conditions, not three sequences that send regardless.

10. 10

    Reporting, testing and handoff

    Decides

    What the business will look at, and who can change the build.

    Output

    Views answering the agreed questions, real historical cases run through end to end, and a named internal owner.

A build tested with invented tidy records passes and then fails in the first busy week. The cases worth running are the ones the business already finds difficult: the customer who calls three times in ten minutes, the enquiry that arrives by form and phone from the same person, the quote that goes quiet, the customer who replies stop, the job booked and then cancelled.

For each, ask what the record says afterwards. Is there one opportunity or three? Does it have an owner? Did any sequence continue after the customer replied? Would the report count this as work the business won, lost, or never resolved? A build that answers those cleanly is finished. A build that cannot is not yet an operating system, whatever is switched on inside it.

Working through the decisions above sometimes produces the conclusion that this platform is not the right home for the work. That is a legitimate outcome, and reaching it before a migration is cheaper than reaching it after one. The usual signals: the business already runs a field-service platform that owns jobs, scheduling and invoicing, and moving the customer record away from it would create a synchronisation problem larger than the one being solved; or the operating rules depend on something the platform does not represent well; or nobody internally will own the build.

The decisions themselves are portable. Stages, ownership rules, stopping conditions and required fields are business property, and they transfer to whatever system ends up holding them. That is the argument for writing them down outside the account, and the reason this checklist starts where it does.

1. A business rule is something the company decides and would still be true on another platform. A platform setting is only where that rule is recorded.
2. Settle the nine decisions before configuring anything, and keep the answers in a document outside the account.
3. A pipeline stage is real only if a second person can verify it from the record. Anything describing a feeling makes reporting meaningless.
4. US SMS from a standard ten-digit number needs A2P 10DLC Brand and Campaign registration, and HighLevel documents that carriers decide the outcome — start it early, not at launch.
5. Missed Call Text Back sends on every missed call, including repeat calls from the same person, so decide the duplicate behaviour deliberately.
6. Write the stopping condition of a sequence before writing its content.
7. Test with the cases that already go wrong. A build tested only on clean records fails in the first busy week.
8. Concluding that this is the wrong platform is a valid result, and the decisions you made getting there transfer to whichever system replaces it.