Licensing and tenancy
Objective. Explain how entitlement works at a practical level - which applications and capabilities a customer is entitled to, kept separate from configuration and usage - so you scope deals and diagnose adoption correctly, and route packaging, pricing and tenancy specifics to the commercial owner.
Licensing is where adoption diagnosis and expansion conversations start, and where over-promising on packaging creates problems at renewal. This teaches the entitlement-versus-configuration-versus-usage distinction, what is safe to say, and the hard line at approved packaging, pricing and tenancy architecture.
See it in the demo
What licensing and tenancy mean in Time Champ terms
Licensing is entitlement: which of the twelve applications and which capabilities a customer is contracted to use. It is deliberately distinct from two other things it is often confused with (C07): CONFIGURATION (whether a capability is set up) and USAGE (whether people actually use it). A customer can be entitled to an application, have it configured, and still not use it - three different problems with three different fixes.
Tenancy is how a customer's instance and data are separated from other customers'. For Sales and CSM, tenancy mostly surfaces as a security and architecture question ('is our data isolated?') that belongs with PLAT-06 and a specialist. The platform story (F01) is that the applications are separate but combinable, which maps naturally onto entitlement - a customer can start with one application and add others.
What a Sales or CSM person can say confidently
Safe to say for scoping (F10, S03): 'The applications are separate and combinable, so you can start with the smallest useful scope and add capabilities as you prove value.' Entitlement supports a land-and-expand motion honestly.
Safe for CSM adoption diagnosis (C07): always separate entitlement, configuration, usage and realised outcome. 'They are entitled but not using it' is an adoption problem; 'they want something they are not entitled to' is an expansion conversation - do not conflate them.
Safe for expansion (C09): qualify on an unmet objective plus evidence, and always run an included-feature check first - confirm whether the capability is already within entitlement before positioning it as new.
Do not quote prices, promise packaging, or commit to what is or is not included for a specific customer. Approved packaging and commercial facts live with the commercial owner.
What always escalates to security or product
Route to the commercial owner, product, or security as appropriate:
- Pricing, discounting and approved packaging for a specific customer (commercial owner - never improvise).
- Exactly what a given contract includes or excludes.
- Seat, volume and metering definitions and how they are counted.
- Tenancy architecture and data isolation between customers (security/product - a PLAT-06 question).
- Any contractual commitment, renewal term or true-up mechanic.
From F10: follow internal commercial ownership. An included-feature check for a customer is a CSM task; an approved price or packaging commitment is not yours to make.
The honest limit
Demo-supported / platform-true: the applications are separate and combinable, which maps to entitlement that can start small and grow; and entitlement, configuration and usage are genuinely different things.
Confirm with commercial/product/security: specific pricing and approved packaging, exact contract inclusions, seat and metering definitions, and tenancy/data-isolation architecture.
Separate cleanly: 'you can start with one application and add more as you prove value, and we will check what is already included before proposing anything new' (safe) from 'this is included at this price in your contract' (commercial owner). Diagnose entitlement confidently; commit packaging never.
Interpretation check
Entitlement, configuration and usage are three different things: a customer can be entitled to a capability, have it configured, and still not use it. Diagnosing which one is the problem is safe and essential; committing specific packaging or pricing is a commercial-owner decision.
In the field
In a large account like KnackGlobal, expansion conversations begin with an included-feature check and an adoption diagnosis (entitled but unused versus genuinely new) so the CSM qualifies expansion on evidence - while pricing and packaging stay with the commercial owner.
Practical task
For a sample account, write a one-paragraph adoption diagnosis that explicitly separates entitlement, configuration, usage and outcome, and name the intervention for each. Then list the licensing and tenancy questions (pricing, inclusions, metering, isolation) you would route to the commercial owner or a specialist.
Self-check
A customer is not getting value from a capability. How do you diagnose before acting?
Separate entitlement (are they contracted for it), configuration (is it set up), usage (do people use it) and outcome (is it realising value) - each points to a different intervention, and conflating them wastes the fix.
Before positioning a new capability as an expansion, what must a CSM check?
An included-feature check - whether the capability is already within the customer's entitlement - so you do not sell something they already own or miss that it is genuinely new.
A buyer asks what a specific package costs and includes. What do you do?
Route pricing, approved packaging and exact contract inclusions to the commercial owner; you can describe the separate-and-combinable model but not commit price or packaging.
Which licensing facts are safe and which escalate?
Safe: the separate-and-combinable model, land-and-expand framing, and the entitlement/configuration/usage distinction. Escalate: pricing, approved packaging, exact inclusions, seat/metering definitions and tenancy/data-isolation architecture.
Verified vs demo. The separate-and-combinable application model and the entitlement/configuration/usage distinction are platform-true and demonstrable; specific pricing, approved packaging, contract inclusions, metering definitions and tenancy/data-isolation architecture are commercial and product/security facts to confirm.