> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stigg.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Subscription downgrades

A **downgrade**, is the switch to a lower-priced option, including:

1. Switching to a lower tier.
2. Switching to a shorter commitment.
3. Reducing the unit quantity (e.g. reducing seats).
4. Removing an add-on.
5. Reducing the quantity of a specific add-on.

In SaaS there are 2 common best-practices:

1. **Downgrade immediately and grant a prorated amount of credits** for the remaining time of the billing period, like [Slack](https://slack.com/help/articles/218915077-Slacks-Fair-Billing-Policy#how-inactive-deactivated-members-affect-billing), or Notion.
2. **Schedule a downgrade** to take place at the end of the current billing period, like [Zoom](https://support.zoom.us/hc/en-us/articles/207597883-Upgrading-your-account-and-add-ons), [Trello](https://support.atlassian.com/trello/docs/how-billing-works-with-trello-premium-and-standard/#How-adding-and-removing-Workspace-members-affects-billing), or [GitHub](https://docs.github.com/en/billing/managing-billing-for-your-github-account/how-does-upgrading-or-downgrading-affect-the-billing-process#example-of-removing-paid-seats-from-your-organization).

Allowing customers to downgrade immediately and granting them a **prorated** amount credits they can redeem in the upcoming invoice may be perceived better by your customers. Slack calls it '[fair billing](https://slack.com/help/articles/218915077-Slacks-Fair-Billing-Policy)’. However, this option is much less favorable to your business as this is a loss in revenue.

Every [product](../../modeling-your-pricing-in-stigg/products/overview) in Stigg can be configured to follow either of these behaviors. By default, products in Stigg are configured to downgrade immediately. To change this behavior, edit the [Customer Journey configuration](../../modeling-your-pricing-in-stigg/products/defining-customer-journey) of the relevant product.

<img src="https://mintcdn.com/stigg/tWlJkHU9GfoKBEmJ/images/docs/63185b9-subscription_downgrade.png?fit=max&auto=format&n=tWlJkHU9GfoKBEmJ&q=85&s=f5073a02e3753bc1f71ca666d62d4ddf" alt="" width="1222" height="914" data-path="images/docs/63185b9-subscription_downgrade.png" />

## How plan downgrades are determined

When a customer switches from one plan to another, Stigg determines whether the transition is a downgrade using the following priority order:

1. **Plan inheritance** - If the customer's current plan inherits from the target plan, the transition is a downgrade.
2. **Price comparison** - If there's no inheritance relationship between the plans:
   * **Both paid plans**: the transition is a downgrade if the target plan has a lower starting price.
   * **Both custom-priced plans**: the downgrade direction is determined by the order of plans in the pricing table.
   * **Both free plans**: the transition is considered neither an upgrade nor a downgrade.

This determination affects:

* The `isUpgrade` and `isDowngrade` fields in webhooks such as `subscription.created` and `subscription.updated`
* The `SubscribeIntentionType.UPGRADE_PLAN` and `SubscribeIntentionType.DOWNGRADE_PLAN` intent types in the [pricing table widget](/documentation/snap-in-widgets/pricing-table)
* Whether a plan change follows the [immediate](./immediate-downgrades) or [scheduled](./scheduled-downgrades) downgrade behavior configured for the product