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.