GoHighLevel SaaS Mode setup for a controlled agency launch

Write the SaaS launch contract before configuring a plan

Start with one observable promise: When an approved buyer selects [named offer], pays through [current provider path], and supplies [required intake], HighLevel should create [sub-account rule], apply [plan and snapshot rule], invite [named user role], fund or rebill [listed services], start [onboarding path], and retain [launch evidence]. Name the intended customer, currency, setup fee or trial rule, recurring package, included and excluded features, support boundary, cancellation path, and accountable owner. Do not let a settings screen define the commercial offer after it has already been sold.

HighLevel's current SaaS Configurator documentation separates plan categories, currencies, features, snapshots, add-ons, apps, trials, credits, and usage settings across a guided plan-building path. The available version, payment-provider route, reseller controls, and interface can vary by account and change over time. Verify current agency eligibility and the live documentation before committing public pricing, tax treatment, feature availability, or client delivery dates.

Keep commercial, platform, and operational decisions separate

The agency owns its offer, pricing, terms, support model, refunds, client promises, and legal review. HighLevel and the selected payment provider own current platform capabilities, eligibility, processing behavior, and account-specific restrictions. The implementation owner connects approved decisions to the plan, snapshot, provisioning, onboarding, wallet, and recovery path. Mixing these responsibilities creates silent risk: a technician can configure a field but cannot authorize a business promise, tax position, payment policy, messaging registration, or legal term.

Use evidence labels such as approved, configured, tested, observed, unknown, owner review, and hold. Avoid "done" when only the plan editor has been saved. A controlled launch needs one traceable test from the commercial entry through the resulting sub-account, user access, reusable assets, billing state, first customer action, and exception path. The eight gates below keep those states distinct.

Gate 1: approve the offer and operating boundary

Record the public package name, intended buyer, jurisdiction or selling boundary, currency, recurring amount, setup fee, trial rule, included features, usage allowances, add-ons, exclusions, support channel, response expectation, upgrade and downgrade rules, cancellation, refund owner, and planned launch date. Keep current platform costs and eligibility in a separate dated evidence note so a documentation change does not silently invalidate the offer. HighLevel's pricing guide and SaaS FAQ are useful inputs, but the agency must confirm its own account, contract, provider, tax, and legal decisions.

Translate each sales promise into a deliverable object. "Automated follow-up" should name the form or event, contact state, workflow, sender, message boundary, stop rule, and proof. "Website included" should name the actual pages, content owner, domain work, and exclusions. "Unlimited" should not appear unless the responsible owner has defined a technically and commercially supportable limit. Separate reusable baseline configuration from client-specific implementation so a SaaS plan does not promise bespoke work that the provisioning path cannot create.

Gate 2: confirm the current configurator and payment-provider path

Open the current agency account and record the SaaS Configurator version or interface, authorized agency user, connected payment provider, supported currency path, account eligibility, and who owns provider credentials, disputes, payouts, tax settings, and reconciliation. Official HighLevel documentation distinguishes SaaS Configurator versions and describes both native and custom payment-provider paths. Do not assume a tutorial written for another version, provider, agency plan, or date matches the current account.

Capture screenshots or a private configuration note without exposing keys, bank information, customer data, or full payment records. Confirm whether the buyer enters through a funnel, order form, payment link, or another supported route and how that route maps to the intended SaaS plan. The technical owner may verify fields and behavior, but payment terms, tax settings, legal text, and the decision to process real money remain with authorized business and provider owners.

Gate 3: map the plan, category, currency, features, and limits

Create a plan map before clicking through the wizard. Record the plan category, display name, internal owner, currency, recurring interval, setup fee or trial, included platform features, feature limits, snapshot, add-ons, apps, credits, usage items, and upgrade or downgrade relationships. Compare the map with the public offer sentence by sentence. If the plan editor allows a setting that the offer does not explain, either document it clearly or remove it from the launch scope.

Do not hardcode copied platform pricing into a long-lived operating document. Record the source URL, review date, current account value, approval owner, and recheck trigger instead. Plan names and feature labels should remain understandable to sales, implementation, support, and finance without relying on internal shorthand. Test currency and interval consistency across the sales surface, configurator, provider, invoice or receipt, and support documentation. A mismatch that appears cosmetic can become a failed checkout, incorrect promise, or reconciliation problem.

Gate 4: prepare the snapshot as a versioned reusable source

Name the source sub-account, snapshot ID or private identifier, version, creation date, owner, target niche, and approved reusable assets. Inventory workflows, funnels, websites, forms, surveys, calendars, pipelines, custom fields, custom values, tags, email templates, products, triggers, domains, integrations, users, phone settings, and other objects that may not transfer cleanly or should remain client-specific. HighLevel's snapshot documentation explains that snapshots package selected configuration for reuse; it does not make every external connection, account value, or operating assumption portable.

Use a clean source and record dependencies before attaching the snapshot to a plan. Replace client names, domains, addresses, emails, phone numbers, legal text, prices, tracking IDs, webhook destinations, calendars, users, and sender assumptions with controlled placeholders or explicit setup tasks. Define how future snapshot updates are created, reviewed, loaded, or pushed. A push can affect existing client accounts, so it requires a separate change boundary, impact review, owner approval, rollback note, and post-change test rather than becoming part of routine onboarding.

Gate 5: provision one controlled test sub-account

Use an approved test route and clearly labelled no-private-data QA values. Record the entry URL or payment-link path, selected plan, timestamp, provider result, created sub-account, assigned plan, applied snapshot, invited user, loaded assets, usage or credit state, and every manual step. Compare the resulting account with the plan and snapshot maps. Do not use a real prospect or client as the first provisioning test, and do not treat a successful charge alone as proof that the account is usable.

Open the created sub-account with the intended role. Verify the expected navigation, reusable assets, custom values, calendars, pipeline, forms, workflows, sender placeholders, and first customer journey. Test one core event such as a form submission or booking using approved QA values, then trace contact creation, owner, opportunity, workflow enrollment, notification, and customer-visible result. Record missing, duplicated, stale, or client-specific assets. Delete or pause the test account only under the approved cleanup path and retain the redacted launch evidence.

Gate 6: prove permissions, welcome, intake, and first login

Define the client administrator, standard user roles, assigned-data limits, module permissions, agency access, support access, and access-removal process. HighLevel provides granular sub-account roles and permissions; use least privilege and verify the resulting client view rather than assuming the role name is enough. Record which settings clients may change, which changes can break the reusable path, and which requests require agency review.

Review the welcome or onboarding email, sender, brand, login link, password or activation path, support route, intake form, first-login sequence, launchpad or checklist, and required setup dependencies. Name who owns domains, email sending, phone or SMS setup, registration or compliance prerequisites, calendars, integrations, content, and business hours. Do not tell a client that messaging, email delivery, domains, payments, or compliance are ready until the responsible platform or business owner has verified them. Test the invitation with an approved QA user and confirm that support can recover access without sharing credentials.

Gate 7: assign wallet, usage, rebilling, and reconciliation ownership

Document which services draw from an agency or sub-account wallet, which can be rebilled or resold in the current configuration, the approved markup or pass-through rule, any included credits, low-balance behavior, alerts, funding method, statement or invoice evidence, refund or adjustment owner, and review cadence. HighLevel distinguishes wallets, rebilling, and reselling concepts, and its SaaS wallet documentation describes sub-account credit management. Verify the current account because provider, version, feature, and regional behavior can change.

Run a controlled non-production reconciliation for the planned services. The plan map, customer-facing terms, provider transaction, HighLevel wallet or usage record, agency accounting record, and support response should tell the same story. Avoid promising that all usage is automatically covered, marked up, or collected. Define what happens when credits run out, an add-on changes, usage spikes, a provider transaction is disputed, a rebill fails, or a client asks for the underlying calculation. Assign one finance or operations owner rather than leaving exceptions to the implementer who first notices them.

Gate 8: test failed-payment, pause, recovery, cancellation, and handoff

Map the current provider and HighLevel behavior for an initial payment failure, recurring subscription failure, configured retry schedule, notices, grace period, feature or account access, wallet exposure, pause or resume, cancellation, data retention, export, refund request, and support escalation. Official HighLevel documentation covers subscription failure behavior, retry settings, and pausing or resuming sub-accounts, but the final policy must match the agency's approved terms and current account. Do not invent a dunning or suspension promise from a generic article.

Test the safe parts in a QA environment or provider test mode where available. Where an end-to-end failure cannot be simulated safely, review the current settings and document the untested boundary. Finish with a launch handoff containing the offer map, current configurator and provider, plan map, snapshot version, test evidence, user roles, onboarding owner, wallet and rebilling owner, recovery matrix, unresolved holds, rollback or pause path, access-removal status, and review date. Launch only when one accountable owner signs off on each open risk.