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.