Add-ons

​

Overview

Add-ons represent separately billable functionality that extends specific paid and custom plans. As opposed to plans, customers can purchase multiple units of a specific add-on. Add-ons are dependent on the life-cycle of the plan that they extend; that is, when a subscription expires, customers also lose access to the plan’s add-ons. The functionality that’s included in each add-on is defined by a combination of features and their configuration (referred to as entitlements). Due to the fact that add-ons extend the functionality of plans, when customers purchase a subscription that includes both plans and add-ons that are defined using the same configuration or metered features, the value of each feature that customers will be entitled to will be the sum of the entitlements of that specific feature. For example: if a customer has a subscription for a plan, and as part of that plan they’re entitled to X units of a specific feature. If they’ll also purchase an add-on with Y units of the same feature, the customer will be entitled to X + Y units as part of their subscription. Moreover, if the customers pays for a quantity of Q add-ons as part of their subscription, they’ll be entitled to X + Y * Q units of that feature.

​

Viewing the list of add-ons

To view the list of add-ons of a specific product:

1. Select the relevant product from the Products sub-section of the Product Catalog.
2. Scroll down to the Pricing > Add-ons section of the selected product.

Viewing a flat list of all of the plans of all of the products is possible by selecting the Add-ons sub-section of the Product Catalog from the left navigation pane.

​

Creating add-ons

To add an add-on, click on the ”+ Add” button under the Add-ons section of the selected product. Enter the below details in the opened modal:

1. Name - the name of the add-on.
2. ID - will be auto-generated by Stigg. Use this ID to refer to the add-on in your application. To link an existing add-on, override the auto-generated value.
3. Description (optional) - the add-on’s description.
4. Add-on type
   1. Single instance - customers’ subscriptions can include only 1 instance of this add-on. This type is useful for add-ons such as: single sign-on (SSO), premium support, etc.
   2. Multiple instance - customers’ subscriptions can include multiple instances of this add-on. This type is useful for add-ons such as: additional API calls, additional credits, etc.

Confirm the action by clicking on the “Create” button. New add-ons are created as drafts. Add-ons must be published in order to be visible to customers and be included in subscriptions.

​

Defining the add-ons price

The price that’s defined in Stigg will be shown to customers in the pricing tables that are rendered using Stigg’s SDKs. When Stigg is integrated with a billing solution (for example: Stripe), subscriptions will be created in the billing solution using the price that was defined in Stigg. Click on the “Set” button under the Pricing section of the selected add-on. The first step would be to select the add-on type - paid or custom (free add-ons are not currently supported).

​

Paid add-ons

Paid add-ons in Stigg are intended to be used in order to allow your customers to subscribe to your product in a self-served manner. When an add-on is defined as a “Paid” plan, additional information is required. To set an add-on as “Paid”, select “Paid” as the add-on type and click “Continue”.

• To grant free add-ons, simply set the price of the add-ons to $0.

​

Billing period

The allowed intervals that customers will be billed at - monthly, annual or both. When customers subscribe to this plan, the billing period will also serve as subscription’s commitment length - when customers update their subscription or cancel it altogether they’ll be compensated in time or money according to the remaining time in the current billing period.

​

Charges

Charges refer to the line items that customers will be billed for when subscribing to this add-on. Currently, only a recurring fixed fee is supported. Enter the charge amount in US dollars in each of the allowed billing periods. Defining prices in other currencies can be done later by leveraging Stigg’s price localization capabilities. Click “Continue”.

​

Custom add-ons

Custom add-ons are intended to be used when the price and content of subscriptions is negotiated with each customer and therefore varies between different customers, as is usually the case in sales-led opportunities. Since add-ons extend plans, subscriptions to custom add-ons must also include a custom plan. When Stigg is integrated with a billing solution, subscriptions that include custom plans and add-ons will not be created in the billing solution. To set an ad-don as “Custom”, select “Custom” as the add-on type and click “Continue”.

​

Assigning features to add-ons

The functionality that’s included in each add-on is defined by a combination of features and their configuration, referred to in Stigg as entitlements. To add entitlements to an add-on, click on the ”+ Add” button under the Entitlements section of the selected add-on. Search for the features that you’d like to assign to the add-on and select them from the list. Apply the relevant configuration for the selected features (see below). Confirm the action by clicking on the “Add” button.

​

Boolean features

Boolean features don’t require any additional configuration. Simply adding them would grant subscribed customers access to the feature.

​

Configuration features

Configuration features must be defined with a numeric configuration value.

​

Metered features

Usage limits

Metered features can be defined with a limit or without one (unlimited).

Limit enforcement

When a limit is set, Stigg can be configured to enforce access when customers reach their limit or not. When a feature’s limit is enforced and the customer reaches their limit, Stigg will deny any additional attempts to access the feature. This concept is known as a “hard limit” and is the default configuration for all Stigg entitlements. When a feature’s limit is not enforced, Stigg will continue granting customers access to the feature even when they exceed their limit. This concept is known as a “soft limit”. The following table summarizes the differences between the two concepts:

	Hard limits	Soft limits
Customers can exceed the defined limit	❌	✅
Useful for	1. Enforcing access in free plans.2. Driving conversions, upsells and expansions.	1. In enterprise plans, to prevent disruptions to customers’ business - excessive usage is commonly leveraged for discussions with sales, CS and account executives about expansion and increased commitment. 2. When implementing an automatic smart upgrade flow to a higher tier based on customer usage instead of charging for overage - upgrades help increase recurring revenue, where overage charges are less predictable.3. During the initial integration with Stigg - companies that already have soft limits defined today and want to gradually rollout the integration with Stigg, can do so while activating enforcement at a later stage without any additional code changes.

Usage reset

Stigg can optionally automatically reset the measured usage every predefined period (yearly, monthly, weekly, daily, or hourly), which is helpful for representing features, such as the number of API calls per month.

​

Entitlement behavior

By default, add-on entitlement increase the plan limit, for example: if plan includes access to 10 seats, purchasing an add-on for 20 seats would result in a seat limit of 10 + 20 = 30 seats; however, there are cases where vendors would like the add-on entitlement to override the plan limit. Luckily, you can control this configuration using no-code for every entitlement that’s included in an add-on. To do so, when adding an entitlement to an add-on or updating an existing one you can specify the entitlement behavior - whether to increment the plan limit or override it.

​

Controlling the add-on visibility

By default, all published add-ons are visible to customers in pricing tables that are rendered using Stigg (either using Stigg’s pricing table widget or custom widgets). Add-on visibility can be changed by clicking on the “Edit” button that appears under the “Add-on details” section. In the opened modal, update the add-on’s customer visibility and click “Save changes”.

​

Storing metadata

It’s possible to store metadata on each add-on. The metadata can then be leveraged by the hosting application and third-party solutions via the Stigg SDKs, API and webhooks to implement custom functionality. To store metadata on a specific add-on, under the “Metadata” section of selected add-on click on the “Add” (if there’s no metadata) or “Edit” buttons. Enter the relevant keys and values. Click “Add” (if there was previously no metadata) or “Save changes” buttons to apply the changes.

​

Publishing add-ons

After defining the basic details, entitlements and pricing of draft add-ons, publish the add-on. To do so, click on the “Publish” button in the add-on’s header. After the add-on is published, make sure to mark it as compatible with the relevant plans in order to allow customers to create subscriptions that include a combination of the plan with the compatible add-on.

​

Defining add-on compatibility with specific plans

Defining add-ons as “compatible” with specific plans represents the fact that the add-on can extend that plan. If an add-on is not compatible with a specific plan, it will not be possible to create a subscription that includes the plan and the incompatible add-on. To mark an add-on as compatible with a specific plan:

1. Select the relevant plan that you’d like to make the add-on compatible with from the Plans sub-section of the Product Catalog.
2. If the plan was already published, first edit it.
3. Under the Compatible Add-ons section click on ”+ Add”.
4. Select the relevant add-ons in the opened modal.
5. Confirm the action by clicking on the “Add” button.

​

Editing published add-ons

Stigg’s allows product managers and growth team members to make frequent and rapid changes to add-ons without requiring additional engineering changes. Changes can be rolled out to both existing and new subscriptions (for example: when adding or removing an entitlement from an add-on), or only to new subscriptions (for example: when changing the add-on’s price). Stigg uses a versioning mechanism to support this functionality - every time an add-on is edited a new version is created. Changes to the add-on can be published or discarded. To edit an add-on, click on the dotted menu icon of the relevant add-on, and select the “Edit” action. Apply the relevant changes to the add-on.

​

Reviewing changes

To review the changes to the add-on since the last published add-on version, click on “review changes” or “Review & publish” in the add-on’s header. In the change review modal:

1. Green backgrounds represent items that were added since the last published version.
2. Orange backgrounds represent items that were updated since the last published version.
3. Red backgrounds represent items that were removed since the last published version.

​

Publishing changes

To publish changes, in the change review modal select the target audience to which the changes will be applied:

1. New subscriptions - the changes will only affect subscriptions that are created after the new add-on version is published.
2. Both existing and new subscriptions - in addition to (1), existing active subscriptions will be migrated to use the new add-on version.

When applying changes also to existing subscriptions, an acknowledgment of a series of disclaimers is required.

​

Discarding changes

To discard pending changes from an add-on, click on “Discard changes” in the add-on’s header. Confirm the action in the opened dialog.

​

Archiving add-ons

To archive an add-on, click on the dotted menu icon of the relevant add-on, and select the “Archive” action. Confirm the action by entering the add-on name and clicking on the “Archive” button in the opened modal.

​

Unarchiving add-ons

Plans can be unarchived using the unarchiveAddon mutation of Stigg’s GraphQL API.