Independent HighLevel affiliate publication. We may earn a commission if you buy through links on this page, at no extra cost to you.

Practical guide

Build a client-plan feature matrix

Last materially reviewed 2026-09-27

Quick answerMap each promised feature to actual subaccount access, a responsible user and a verification step.
What to know

Translate the offer into a matrix

List each promised capability as a row. Add columns for plan inclusion, subaccount access, user role, required connection and evidence of usability. Keep service work in a separate column rather than assuming that enabling a feature performs the work. This matrix connects the client-facing plan to the actual arrangement without requiring a large feature checklist that nobody maintains.

What to know

Apply the documented distinction

HighLevel separates subaccount feature permissions from individual user permissions. A person cannot gain a feature solely through their user role if it is unavailable to the subaccount. Our matrix therefore checks both levels. Do not solve missing access by granting everything: identify the required capability and the intended person, then choose the smallest suitable permission set.

What to know

Use one fictional row

Suppose a client plan includes a calendar but excludes campaign management. The calendar row should identify the authorized user, any required connection and a harmless task that confirms usability. The excluded campaign row should be visibly outside the offer, not merely absent by accident. This is an original planning example, not a claim that we tested a particular customer account or a complete HighLevel configuration.

What to know

Maintain the matrix through changes

Review it when changing a plan, adding an administrator or removing an extra. Preserve the previous version and note the effective date. If the client cannot use a promised capability, record the actual failure before making broad changes. A matrix is only useful when its claims are checked; a row marked included is not proof of functional access, correct configuration or completed service delivery. At the next handoff, choose one included and one excluded capability for review. Both should agree with the plan sheet, helping reveal accidental over-permission as well as missing access.

Continue when useful

Next: Feature access and user permissions are separate checks

Check what the subaccount includes before changing what an individual user may do.

Open Feature access and user permissions are separate checks →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. Subaccount feature permissions — Merchant documentation · help.gohighlevel.com · Merchant-controlled · checked 2026-09-27