Plan
In Zenskar, a plan is a reusable blueprint that defines the commercial structure of a product or service. While a contract represents a specific agreement with a single customer, a plan acts as a standardized template used to generate multiple contracts with consistent pricing, phasing, and logic.
The primary purpose of a plan is to separate commercial logic (how you sell) from operational execution (to whom you sell). By using plans, you ensure that changes to your standard offerings can be managed centrally and deployed consistently across your customer base.
Hierarchical structure
The data architecture of a plan mirrors that of a contract. It is organized into a nested hierarchy that allows for complex, multi-stage commercial agreements.
- Plan: The top-level container for a standardized offering.
- Phases: Temporal segments within the plan. For example, a "Scale-up plan" might have an introductory phase for the first three months followed by a standard growth phase.
- Products: The specific units of value included in each phase, such as subscription seats or API units.
- Features: Modifiers applied to the products or the phase, such as localized tax rules (e.g., Avalara), volume discounts, or specific payment terms.
Plans versus contracts
The distinction between a plan and a contract is the difference between a blueprint and a physical building.
| Attribute | Plan (The blueprint) | Contract (The implementation) |
|---|---|---|
| Association | Customer-agnostic. | Linked to a specific customer entity. |
| Content | Standardized pricing and logic. | Individualized terms, unique discounts, and metadata. |
| Data | Contains no PII or transactional history. | Contains activation dates, billing history, and customer info. |
| Engine role | Used by the UI/API to populate new contracts. | Used by the billing and revenue engines for execution. |
The abstraction layer
Reusing a contract as a template for another customer is architecturally risky, as it carries over customer-specific metadata, billing cycles, and potentially sensitive custom terms. Plans provide an abstraction layer, allowing you to iterate on your "Premium annual" or "Usage-based" models without affecting the historical data of existing contracts.
The plan lifecycle
Plans follow a straightforward lifecycle designed to transition from a theoretical model to an active customer agreement:
- Definition: You define the phases, products, and features that constitute the standard offering.
- Importation: When a new customer signs, you import the relevant plan into a new contract. Zenskar automatically populates the contract with the plan's hierarchy.
- Specialization: Once imported, the contract can be customized. You can override specific pricing, add one-time setup fees, or adjust dates to fit the unique requirements of that customer without altering the original plan.
Next steps:
- To begin building your commercial templates, see the [How-to guide: creating and managing plans].
- To understand how to apply these templates to customers, see [Getting started: your first contract].
- Would you like me to draft a Reference document for the "Plan" object, detailing the specific API fields and data types?
Updated 6 days ago
