Subscription Packages

Subscription Packages

A package is the commercial arrangement — what a customer is on, and therefore what they get.

Where to find it

Architect Panel → Subscriptions:

• Feature Sets — the groupings features are sold in
• Subscription Packages — the packages customers buy

Architect Panel → Configuration:

• Multitenancy — the tenants packages apply to

Architect Panel → Commercial:

• Carts — the payment side

What it ties together

• A feature set, deciding what is available.
• The commercial terms.
• A link to the tenant it applies to.

The package is the source of truth

What a customer can do should follow from their package rather than from anybody's memory or a note in a spreadsheet. If the two disagree, you have a customer receiving something they are not paying for, or paying for something they cannot use.

Both happen, and both are found at renewal, which is the worst moment.

Plan the lifecycle

• Starting — including any trial, and what happens when it ends.
• Upgrading — usually immediate and welcome.
• Downgrading — the one that needs thought.
• Lapsing — non-payment, expiry, cancellation.
• Ending — and what happens to their data.

Downgrade and lapse are where the problems are

Upgrades are easy. The questions that need answering before you have customers:

• What happens to data only the removed feature can reach?
• Do they keep read access, or lose it?
• How much warning do they get?

"Their data becomes inaccessible with no notice" is a decision, and it should be a deliberate one — it is the kind that ends up in a complaint.

Never delete data on lapse

Suspend access, and keep it for a defined period. A customer who lapses through an administrative oversight and loses everything is a customer you will not recover, and possibly a legal problem.

Publish the period so it is not a surprise.

Trials need an end state

Decide what a trial becomes: a lower tier, a suspended account, or a closed one. A trial that silently continues is revenue you are not collecting; one that vanishes without warning loses a prospect who was still deciding.

Keep it reconcilable

Somebody should be able to compare what customers are on against what is being billed. Where those diverge, the difference is money in one direction or the other.

Worked example

A product's packages link a feature set to a tenant. A lapsed subscription suspends access and retains data for 90 days, which is published. Trials convert to a suspended account with an explanation and a route to subscribe. A monthly reconciliation compares packages against billing.

Recommendations

• Make the package the source of truth.
• Decide downgrade and lapse behaviour before you have customers.
• Never delete on lapse — suspend and retain.
• Reconcile packages against billing.

Creating a Package

A package is created once and sold repeatedly, so it is worth getting right.

Where to find it

Architect Panel → Subscriptions:

• Feature Sets — the groupings features are sold in
• Subscription Packages — the packages customers buy

What to settle

1. Which feature set it grants.
2. The commercial terms.
3. Its name, as customers will see it.
4. What happens at the end of a term.

Name it as it appears on an invoice

The name reaches customers on invoices, in the interface and in sales material. An internal name — "Tier 2 rev B" — will end up in front of somebody, and renaming it later means changing published material and confusing existing customers.

Keep the number of packages small

Every package is a combination to support, test and explain. A handful of active packages is manageable; a long list accumulated from historical pricing is not, and it makes every support conversation start with "which package are you on?".

Retire, do not delete

Customers on an old package still need it to resolve. Mark it retired so it cannot be sold, and leave it in place for those who have it — the standard rule for anything referenced by existing records.

Test with a real customer account

Create a tenant on the package and use it. Confirm the right features are present, the wrong ones are not, and the interface reads correctly for somebody on that package.

Check the boundary with the tier above

Whatever distinguishes this package from the next is what a customer will run into. Exercise it, and make sure hitting the limit produces a clear explanation and a route to upgrade rather than something that looks broken.

Write down what it includes

Precisely. This is what a customer will hold you to, and vagueness is resolved in their favour — reasonably, since they did not write it.

Decide about mid-term changes

Upgrading mid-term is usually immediate; downgrading mid-term needs a rule — at renewal, or immediately with an adjustment. Deciding in advance avoids negotiating it individually with each customer who asks.

Worked example

A product runs three active packages and two retired ones still held by legacy customers. Each is named as it appears on invoices, and each was tested with a real tenant before being sold. Downgrades take effect at renewal, which is stated in the terms rather than decided per request.

Recommendations

• Name it as customers will see it.
• Keep active packages few; retire rather than delete.
• Test with a real tenant before selling it.
• Decide mid-term changes in advance.

Linking to a Tenant

A package applies to a tenant. That link is what turns a commercial arrangement into what the software actually does.

Where to find it

Architect Panel → Subscriptions:

• Feature Sets — the groupings features are sold in
• Subscription Packages — the packages customers buy

Architect Panel → Configuration:

• Multitenancy — the tenants themselves

This is the join that must be right

Everything else is configuration; this is what connects it to a paying customer. A wrong link means somebody has the wrong features — either more than they are paying for, or less.

Neither is discovered quickly. Too much is silent; too little is reported as a fault rather than as a billing question.

One package per tenant

Keep it unambiguous. If a tenant appears to have two, entitlement depends on how that is resolved, which is exactly the kind of thing nobody wants to reason about during a support call.

Check it at the start of the relationship

When a customer is onboarded, confirm their tenant is on the package they bought — by signing in and looking, not by reading the record. Getting this wrong at the start means the whole relationship is on the wrong footing.

When entitlement looks wrong

Work through it in order:

1. Which package is the tenant actually linked to?
2. Which feature set does that package grant?
3. Does that set contain the feature?
4. Is the user's permission the problem rather than the feature?

The fourth catches a good proportion. A customer whose tier includes something, whose staff cannot use it, has a permissions question rather than a subscription one — and support will otherwise escalate it as billing.

Changes need to take effect predictably

When a customer upgrades, they expect the feature promptly. Know how quickly a change applies and whether anybody needs to sign out — and tell the customer, rather than leaving them refreshing.

Reconcile periodically

Compare tenants against packages against billing. Divergence is money, and it accumulates quietly through trials that were extended, deals with exceptions, and migrations that missed one.

Record exceptions where they exist

If a tenant is deliberately on non-standard terms, that should be recorded against them rather than living in somebody's memory. Undocumented exceptions surface at renewal, usually in front of the customer.

Worked example

An onboarding checklist includes confirming the tenant's package by signing in as a customer user. A monthly reconciliation compares tenants, packages and billing — which found one tenant left on a trial package eight months after converting, and one deliberate exception now recorded with its renewal date.

Recommendations

• Confirm the link at onboarding, by looking.
• One package per tenant.
• Check permissions before concluding it is a subscription problem.
• Reconcile monthly — divergence is money.