Master this essential documentation concept
An optional feature or module sold separately from a software platform's base subscription price, often used to unlock capabilities that competitors include as standard.
An optional feature or module sold separately from a software platform's base subscription price, often used to unlock capabilities that competitors include as standard.
When your team evaluates or onboards a HubSpot add-on — whether that's a reporting tier, a custom object expansion, or a dedicated support package — the explanation often lives in a sales call recording or an internal walkthrough video. Someone on the team does a screen share, walks through what the add-on unlocks, and that knowledge quietly disappears into a shared drive folder no one revisits.
The problem surfaces when a new team member needs to understand what your current subscription actually covers versus what requires an additional purchase. Scrubbing through a 45-minute onboarding video to find the two-minute segment explaining add-on capabilities is a real time cost — and it often means the question just goes unanswered, or worse, gets escalated unnecessarily.
Converting those training videos into structured documentation gives your team a reference they can actually use. A well-organized guide covering your active add-ons — what each one enables, how it was configured, and why it was purchased — becomes the single source of truth for procurement decisions, onboarding checklists, and internal audits. When someone asks whether a specific feature requires an add-on, the answer is a search query away instead of a meeting request.
If your team relies on HubSpot training videos to communicate this kind of subscription knowledge, see how you can turn those recordings into referenceable guides your whole team can use.
Enterprise customers expect Single Sign-On (SSO) to be a standard security feature, but the platform gates it behind an add-on purchase. Support and sales teams field repeated complaints when onboarding guides omit this distinction, leading to frustrated customers who discover the extra cost mid-implementation.
Clearly document SSO as a purchasable Add-On within the onboarding guide, including pricing context, activation steps, and a comparison callout showing what competitors bundle by default versus what requires an add-on purchase here.
["Add a dedicated 'Add-Ons Required' prerequisites section at the top of the SSO configuration guide, listing SKU name, estimated cost tier, and where to purchase in the admin portal.", "Insert a callout box labeled 'Add-On Required' using a visually distinct admonition (e.g., warning or note block) before any SSO configuration steps.", 'Create a comparison table in the Add-On documentation showing SSO availability across Free, Pro, and Enterprise tiers to set expectations before purchase.', "Link the SSO guide back to a master 'Add-Ons Catalog' page so customers can evaluate all optional modules in one place before committing."]
Support ticket volume related to 'unexpected SSO costs' drops measurably, and enterprise sales cycles shorten because procurement teams receive accurate cost documentation upfront.
Prospects evaluating the platform cannot easily determine which capabilities are included in the base plan versus sold separately. Sales engineers spend excessive time answering 'is X included?' questions that should be self-serviceable through documentation.
Create a structured Add-On Catalog documentation page that lists every available add-on with its name, description, included tier, pricing model, and a direct link to its configuration guide, enabling prospects and customers to self-serve answers.
["Audit all existing feature documentation to tag each feature as 'Included in Base' or 'Add-On Required', then compile the Add-On list into a single catalog page.", 'Structure each Add-On entry with a consistent schema: Add-On Name, What It Unlocks, Who Needs It (persona), Pricing Model (per seat / flat fee / usage-based), and Setup Guide link.', 'Add a filter or table with sortable columns (e.g., by category: Security, Analytics, Integrations) so different buyer personas can quickly find relevant add-ons.', 'Publish the catalog URL in the pricing page, onboarding emails, and the in-app upgrade prompts to create a single source of truth.']
Pre-sales documentation self-service rate increases, reducing repetitive questions to sales engineers and shortening time-to-close for deals where pricing clarity was a blocker.
Monthly release notes bundle core feature updates and add-on enhancements together without distinction. Customers on the base plan read about new capabilities, attempt to use them, and then discover they require an additional purchase — eroding trust in the changelog.
Implement a structured release note template that visually and categorically separates 'Base Plan Updates' from 'Add-On Updates', including the specific add-on name required for each enhancement.
["Define a release note taxonomy with two primary sections: 'Included in All Plans' and 'Add-On Enhancements', and apply this structure consistently to every release note published.", 'For each Add-On enhancement entry, include an inline badge or tag (e.g., [Advanced Analytics Add-On]) so the dependency is visible at a glance without requiring customers to click through.', 'Add a footer note in each release with a link to the Add-On Catalog page for customers who want to upgrade to access the new add-on capabilities.', 'Audit the previous 6 months of release notes and retroactively tag existing add-on entries to maintain historical consistency.']
Customer complaints about 'hidden features' in changelogs decrease, and add-on upgrade conversions from release notes become trackable as a measurable revenue signal.
A previously free feature is being moved to a paid Add-On in an upcoming platform version. Existing customers using the feature are unaware of the upcoming change, and there is no documentation explaining the migration path, cost implications, or opt-in deadline.
Produce a dedicated Add-On Migration Guide that explains the deprecation timeline, grandfathering policy (if any), steps to purchase and activate the new add-on, and what happens to data or configurations if the customer does not upgrade.
['Publish a migration guide page 60 days before the deprecation date, clearly stating the feature name, the new Add-On it maps to, the cutover date, and any grandfathering or grace period terms.', 'Add a deprecation banner to the existing feature documentation page that links directly to the migration guide and the add-on purchase flow.', 'Include a step-by-step section covering: how to check current usage of the feature, how to purchase the add-on, how to verify the add-on is active, and how to confirm existing configurations are preserved post-migration.', "Create an FAQ section addressing the top concerns: 'Will my data be lost?', 'Can I export before the cutover?', and 'What is the pricing for the replacement add-on?'"]
Customer churn attributable to surprise add-on migrations is reduced, and support escalations during the deprecation window drop because customers have a clear, proactive self-service resource.
When a feature requires an add-on, state that dependency at the very first point in the documentation where the feature is mentioned — not buried in a prerequisites section at the bottom of the page. Customers should never reach step 4 of a tutorial before discovering they need to make an additional purchase. Inline labeling prevents wasted implementation time and reduces support tickets.
Scattered references to add-ons across pricing pages, help articles, and onboarding guides create inconsistency and confusion when add-on names, prices, or availability change. A single canonical Add-On Catalog page that all other documentation links to ensures updates propagate cleanly and customers always find accurate information. This page should be versioned alongside the product.
Since add-ons often gate features that competitors include as standard, customers frequently feel frustrated by the pricing model. Documentation can acknowledge this reality factually — for example, noting the add-on provides enterprise-grade controls beyond standard offerings — without being defensive or misleading. Factual framing builds trust; marketing spin in technical docs erodes it.
Add-ons evolve — new capabilities are added, pricing tiers change, and some add-ons are eventually bundled into the base plan. If add-on documentation is not versioned and updated in sync with these changes, customers on older contracts or legacy plans will encounter documentation that no longer matches their experience. Treat add-on docs with the same release discipline as feature docs.
Many documentation teams only describe what an add-on enables, but fail to document what the degraded experience looks like for customers who do not purchase it. This creates confusion when users encounter locked UI elements, disabled API endpoints, or missing menu options and cannot find an explanation. Documenting both states — enabled and disabled — reduces support load and sets accurate expectations.
Join thousands of teams creating outstanding documentation
Start Free Trial