Tag: launch checklist

The implementation can be live and still not be ready for acceptance.

A form may submit. A pipeline may exist. Workflows may be published. The implementation partner can walk through the account and show that every major piece is there. None of that proves the customer path works under the conditions the business actually paid for.

A GoHighLevel launch checklist should give the buyer a way to test that claim before signing off. The test is simple in principle: create controlled leads, follow them through the agreed path, record what happened, and keep acceptance open when the result does not match the approved build.

“Live” tells you the system is turned on. “Accepted” should mean the business has evidence that the important paths work.

Sign-Off Starts After the Builder Says the Account Is Ready

BrandLyft’s GoHighLevel buildout timeline covers the earlier work: mapping the sales path, building the account, connecting lead sources, setting up calendars and workflows, and testing before real traffic depends on the setup.

This article begins at the other side of that process.

The provider says the build is ready. The buyer now has to decide whether to accept it.

That decision should not depend on a screen-share tour or a list of completed assets. Acceptance should compare the approved behavior with what actually happens when a controlled test lead enters the system.

If the scope says website leads should create an opportunity, preserve the source, route to the correct owner, send an acknowledgment, and offer the right booking path, test that exact sequence. If the build includes an outside lead source or operating platform, test that handoff too.

The acceptance test is not another build plan. It is proof that the agreed build behaves as promised.

Use the GoHighLevel Launch Checklist to Test Real Paths, Not Features

Start with the few customer paths that matter enough to stop sign-off when they fail.

A service business may have a website form, inbound phone line, missed-call recovery path, paid lead form, chat inquiry, and referral form. Another company may depend on calendar bookings or a third-party lead source. The acceptance test should follow the sources included in the actual implementation rather than testing every feature GoHighLevel offers.

The evidence column matters. A verbal “that worked” disappears as soon as the call ends. A named test record gives both sides something they can inspect again when a question comes up before acceptance.

Submit Every Major Lead Source and Inspect the Record It Creates

Do not accept a lead source because the integration shows connected.

Submit a controlled lead through each major source included in scope. Use a real email address and phone number you can access so the test can continue into communication and booking.

HighLevel’s Form Submitted workflow trigger can start automation when a selected form is submitted. That tells you how the platform can react to the event. Acceptance still needs to inspect the business result.

Open the contact. Confirm the expected name, email, phone, service or intake fields, and any data the sales team needs. Then open the opportunity. Check the pipeline, stage, owner, status, and any value or source field the approved build uses.

Test existing contacts too when the business expects repeat inquiries. A setup that works only for brand-new records may create duplicates or attach new work to the wrong opportunity once real customers return.

Source Preservation Needs a Record-Level Check

A dashboard can look convincing while the underlying source data is weak.

Use test URLs or source paths that make the expected origin clear, then inspect the contact record after submission. HighLevel stores first and latest attribution on contacts and can record UTM and session-source information for supported HighLevel entry points. Its current attribution documentation also notes that non-HighLevel events do not automatically capture the same attribution data.

That distinction matters during acceptance. A website form, Meta lead form, third-party connector, imported contact, and manually created record may not produce the same source trail.

Do not sign off on “attribution is set up” as a general statement. Pick the sources the business plans to measure and prove that the field or report used for those sources contains the evidence the team expects.

Routing Has to Work When the Easy Owner Is Not Available

A happy-path routing test proves very little when the first eligible user is online and available.

Run the normal route first. Confirm the correct user or location receives the lead, the opportunity reflects ownership, and the person receives the notification they are expected to act on.

Then test one agreed exception.

That may be an after-hours inquiry, a lead outside one rep’s territory, an unavailable calendar owner, or a route that should fall back to another person. The exact exception should come from the approved implementation rather than a random edge case invented during sign-off.

The buyer is checking one thing: does ownership remain clear when the first path cannot complete normally?

If the system quietly leaves the opportunity unassigned or sends an alert to somebody who is no longer responsible, keep that acceptance item open.

Book, Reschedule, Cancel, and Check the Messages Around the Appointment

A booking link working once does not prove the calendar path is ready.

Book a test appointment using the same public path a real lead will use. Confirm the date, time, calendar, assigned person, meeting location or link, opportunity movement, and internal notification.

HighLevel currently supports configurable appointment notifications for bookings, confirmations, cancellations, reschedules, reminders, and follow-up. Its calendar notification documentation also lets users send test SMS messages while setting up reminder behavior.

Use that capability as part of the build. Use the actual customer path for acceptance.

Reschedule the appointment. Cancel another test. If no-show handling is part of scope, run that state too. The customer should not receive an old reminder for a time that no longer exists, and the team should not have to guess which calendar record is current.

Replies Should Change the Automation When the Approved Build Says They Should

One of the easiest launch mistakes is testing outbound messages without testing what happens after somebody answers.

Reply to the test SMS or email. Confirm the conversation reaches the right place and the next automation step behaves as designed. If a customer’s response should stop or redirect nurture, prove it. If the system should create a task or alert a salesperson, look for the actual result.

HighLevel’s Customer Replied trigger can react to inbound replies. The User Replied event can also support paths where a staff response changes automation behavior. Those controls make reply-aware workflows possible, but the acceptance test needs to confirm the specific workflow in the account uses them correctly.

Do not approve a sequence after watching only the first automated text send.

Phone and Email Need Real Sending Tests

Settings screens are not delivery tests.

Place an inbound call to the number the business will advertise. Check routing, caller experience, missed-call behavior when relevant, voicemail or forwarding, and the internal record that appears afterward. HighLevel exposes phone-number settings for inbound and outbound behavior, including forwarding and timeout controls.

Send an outbound SMS from the path staff will actually use. For U.S. businesses sending application-to-person messages over 10-digit local numbers, verify the required A2P registration status before treating SMS as launch-ready. HighLevel’s current A2P documentation describes that registration requirement.

Email needs the same treatment. A configured From address is not proof that the message lands correctly. Send a real workflow or one-to-one test through the intended sending setup. If the account uses LC Email with a dedicated sending domain, confirm the domain is verified and inspect the real received message rather than stopping at a green DNS screen.

Connected Systems Need an End-to-End Handoff Test

An integration should not pass acceptance because somebody can see a successful connection badge.

Create a test record that should cross into the connected platform. Confirm the destination receives the correct person or job, the shared identifier survives, and the fields that matter to the next team arrive usable.

If the approved design includes a return event, complete the test on the other side. Change the status or outcome that is supposed to return to GHL, then verify the correct contact or opportunity updates without creating a duplicate.

Run one controlled failure case when the connection is important enough to affect lead handling or revenue reporting. The failure might be a record missing an agreed required value or another safe condition the implementation team has prepared for QA. The purpose is not to break production. It is to prove the business can see a failed handoff instead of discovering it days later.

BrandLyft’s restoration CRM-to-dispatch article shows why this matters: a sending system can look healthy while the receiving system never creates or updates the business record the team depends on.

Check Reporting Against the Test Records You Already Know

Do not validate reporting by asking whether the dashboard looks reasonable.

You already created controlled records during acceptance. Use them.

If the test form came from a known source, find it in the contact and reporting views. If the opportunity moved from New Lead to Booked, confirm the report reflects the event the business intends to count. When a dashboard separates first and latest attribution, check the correct one rather than assuming the label means what the team thinks it means.

HighLevel supports first and latest attribution filters in contact and opportunity reporting. That can help with source reporting, but the dashboard is only as trustworthy as the records feeding it.

Acceptance should connect one known test event to the number or status leadership expects to see later.

Log In as the People Who Will Actually Use the Account

An admin view can hide user-access problems.

Ask at least one real user from each important role to sign in with their own account. A salesperson should see the leads they need and the actions they are responsible for. A manager should have the wider view the operating model requires. Someone who should not edit workflows or view unrelated data should not receive that access by accident.

HighLevel’s current sub-account permissions documentation supports role, module, granular permission, and assigned-data controls. Acceptance should verify the configured result from the user’s login rather than reading the permission settings from an admin screen.

This is also a good point to confirm the team knows the few daily actions the build expects from them. A technically correct account can still fail acceptance if the promised operating path depends on staff doing something nobody was shown.

Run a Failed-Path Test Before You Sign

The build should not collapse into silence when something goes wrong.

Choose one or two failure conditions that matter to the approved scope. Let a test lead reply while an automated sequence is active. Use a calendar condition that should trigger a fallback. Submit a controlled record that cannot complete an integration handoff. Test the route used when the normal owner is unavailable.

The expected result does not always need to be automatic recovery.

Sometimes the correct result is a visible exception, a task, an alert, or a record that stays in a review queue until a person decides what to do. What matters is that the business can see the failure and knows who owns the next action.

A silent failure should not receive a passing mark because the rest of the path looked good.

Known Exceptions Belong in the Acceptance Record

No serious implementation needs to pretend every possible edge case is perfect on day one.

A provider and buyer may agree to launch with a known limitation, a third-party dependency, or a lower-priority item scheduled for a later phase. That can be reasonable when both sides can see the boundary.

Write it down before sign-off.

The acceptance record should name the exception, affected path, business impact, temporary handling, owner, and agreed next step. It should also separate an accepted limitation from a failed requirement the original scope said would work.

This protects the buyer from signing away an unresolved defect. It also protects the implementation team from having a new feature request described later as something that was always part of launch.

Acceptance Evidence Should Make the Decision Easy to Revisit

The final acceptance record does not need to become a giant technical binder.

Keep enough evidence to reconstruct the decision.

Record the test date, build or workflow version when relevant, test contact IDs, major paths tested, screenshots or log references that prove important outcomes, known exceptions, and the person who approved the result. If a test failed and was corrected, record the retest rather than replacing the history with a clean final screenshot.

The purpose is not paperwork.

Two weeks later, if somebody says “this never worked,” the business should be able to see what was tested, what passed, what remained open, and what changed after acceptance.

A GoHighLevel Launch Checklist Should End With a Sign-Off Decision

The buyer does not need to prove every feature inside GoHighLevel.

The buyer needs to prove the paths the implementation was hired to build.

Major lead sources should create usable records. Ownership should remain clear. Appointments should behave correctly when they change. Replies should alter automation when the approved logic says they should. Phone and email should work outside the settings screen. Connected systems should complete the agreed handoff. Reporting should recognize the known test records. Real users should have the access they need. Failed paths should become visible instead of disappearing.

If those tests pass, sign-off has evidence behind it.

If one of the important paths still fails, keep that acceptance item open. “Almost ready” may be enough to continue testing. It is not the same as accepted.