> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.zenskar.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 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:

1. **Definition:** You define the phases, products, and features that constitute the standard offering.
2. **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.
3. **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?