Feature Sets

Feature Sets

A feature set groups features into the bundle a customer buys.

Where to find it

Architect Panel → Subscriptions:

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

Why group at all

Because selling features individually produces a configurator rather than a product. Customers faced with twenty checkboxes cannot judge what they need, take longer to decide, and frequently decide not to.

Sets turn that into a choice between three or four things, which people can make.

Three or four tiers

Enough to serve different sizes of customer, few enough to compare on one screen. Beyond that, the comparison table stops being useful and prospects stall.

Each tier needs an obvious buyer

If you cannot describe who a tier is for in a sentence, it will not sell. "A small team getting started", "an organisation running this as its main system", "a group with several entities" — each of those is a person who recognises themselves.

A tier existing only to make another look reasonable is a pricing tactic customers see through.

Make the step up obvious

The reason to move up should be one or two features somebody can name, not a longer list of small things. Customers upgrade because they need a specific capability, and if they cannot say which, they will not.

Nest them

Each tier should include everything below it. Tiers where the middle one has something the top one lacks are genuinely confusing and produce support conversations rather than sales.

Do not put fundamentals in the top tier

Anything a customer needs to use the product safely — audit, access control, backup — belongs in every tier. Putting them above the entry level means your smallest customers run least safely, and they are the ones least able to judge that.

Expect to change them, and plan for it

Tiers evolve. Existing customers on an old arrangement need handling gracefully — usually by grandfathering rather than migrating them into something that gives them less.

Worked example

A product runs three tiers: Starter for a single small team, Standard for an organisation running it as its main system, and Group for multi-entity customers. The step from Starter to Standard is the API and single sign-on — two named things. Audit and permissions are in all three.

Recommendations

• Three or four tiers, nested.
• Each with a describable buyer.
• Make the upgrade reason nameable.
• Fundamentals in every tier.

Assigning Features to Tiers

A set links features to a tier. The mechanics are simple; the testing is what matters.

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 a package applies to

Test each tier as a customer

Not as an administrator, and not by reading the configuration. Sign in to an account on that tier and use the product.

This is the step that catches the two failures that matter: something that should be available and is not, and something that should not be and is. The second is revenue you are giving away, and neither is visible from the configuration screen.

The lowest tier deserves the most testing

Because development happens with everything on, so the entry tier is the one most likely to be broken — and it has the most customers and the least tolerance.

Check every boundary

Where two tiers differ, exercise that difference in both directions. A feature that fails ungracefully when absent is worse than one that is simply missing.

Changing a tier affects live customers

Adding a feature is usually safe and welcome. Removing one is a takeaway and needs deciding deliberately — including what happens to data reachable only through it.

Where you must remove, grandfather existing customers.

Watch for tier drift

Features get added to tiers to close a specific deal, and over time the tiers stop matching the published comparison. That produces customers who believe they have something they do not, and a sales team quoting from a table that is no longer true.

Review what each tier actually contains against what you publish, periodically.

One-off exceptions are debt

Granting one customer a feature outside their tier is easy and accumulates. Each is invisible, unreviewed, and will surprise somebody at renewal. If you do it, record it and revisit it.

Keep the published comparison honest

The comparison table is what customers buy from. If it says something a tier does not deliver, that is a dispute waiting to happen — and the customer's reading is the one that will be held to.

Worked example

A team tests all three tiers as real customer accounts before each release, entry tier first. A quarterly check compares actual tier contents against the published table, which found two features quietly granted to a middle-tier customer during a deal and never recorded — now documented as a deliberate exception with a renewal date.

Recommendations

• Test each tier as a customer, entry tier first.
• Exercise every boundary in both directions.
• Record one-off exceptions and revisit them.
• Reconcile tiers against the published table.