Product Catalog & Pricing Reference
Product Catalog & Pricing Reference
Complete configuration of Prolifi’s product catalog — from defining products and plans through to pricing models, entitlement structure, plan variants, grandfathering, and acquisition strategy.
What this covers
This reference document covers the complete configuration of Prolifi’s product catalog — from defining products and plans through to pricing models, entitlement structure, plan variants, grandfathering, and acquisition strategy. This document is the single reference for understanding how everything you sell is structured in Prolifi.
Prerequisites
Before configuring the product catalog:
- Account setup is complete
- Operating entities are configured (required for multi-currency pricing) — See: Getting Started: Finance, Section 1
- Tax settings are configured per entity (required for correct invoice tax calculation) — See: Tax Management Reference
1. Product Catalog Structure
Prolifi’s product catalog is organised in a four-level hierarchy:
1.1 Product groups
Product groups are an optional organisational layer for catalogues with many products. They allow you to group related products together for display, reporting, and navigation purposes. A product group has no direct billing function — it is purely organisational.
Example product groups:
- “Platform” (containing all SaaS platform products)
- “Professional Services” (containing service-based products)
- “Add-ons” (containing all standalone add-on products)
1.2 Products
A Product (Glossary: Product) is the root entity in the catalog. Every plan, entitlement, and subscription references a product.
Product attributes:
Product status lifecycle:
- Draft: Product is being configured; not visible for subscription creation
- Active: Product is live; subscriptions can be created
- Archived: Product is no longer sold; existing subscriptions continue but no new ones can be created
1.3 Features
Features are the specific capabilities or access rights associated with a product. Define features at the product level before configuring plans, because plans reference features when configuring entitlements.
Features can be:
- Binary: Feature is either included (on) or not (off) for a given plan
- Quantified: Feature is included at a defined quantity (e.g., “up to 10 users”, “100 GB storage”)
Feature examples:
- “API Access” (binary)
- “Advanced Reporting” (binary)
- “User Seats” (quantified)
- “Storage (GB)” (quantified)
- “API Calls per Month” (quantified, usage-tracked)
2. Plans
A Plan (Glossary: Plan) is the commercially packaged, priced version of a product. A product typically has multiple plans representing different tiers or configurations.
2.1 Plan attributes
2.2 Plan variants and alternate pricing
A single plan can have multiple pricing variants, each representing a different pricing option for the same plan configuration. Common use cases:
- Currency variants: The same plan priced in GBP, USD, EUR separately
- Billing frequency variants: Monthly pricing vs. annual pricing at a discount
- Customer segment variants: Standard pricing vs. partner pricing vs. enterprise pricing
Plan variants share the same entitlements and billing model but have different pricing configurations.
2.3 Add-ons
Add-ons (Glossary: Add-on) are separate products that are sold alongside a base subscription. They extend the base subscription’s capabilities without requiring a plan upgrade.
Add-on configuration:
- Add-ons are products in their own right — they have their own product record, pricing plan, and optionally their own entitlements
- Add-ons are linked to base subscription plans to define which add-ons are available with which base plans
- Add-ons can be priced independently of the base subscription (their own billing cycle and model)
- Add-on invoices can be included in the base subscription invoice (consolidated billing) or issued separately
3. Pricing Models
Prolifi supports eight pricing model types. The pricing model determines how the billable amount for each charge period is calculated.
3.1 Fixed Pricing
How it works: A fixed amount, charged every billing period regardless of usage.
Configuration:
- Amount: The fixed charge per billing period (e.g., £500/month)
- Currency: The billing currency
Example: Enterprise SaaS plan at £1,200/month. Every month, the invoice is for exactly £1,200.
3.2 Per-Unit Pricing
How it works: A price per unit multiplied by the quantity of units. The total charge scales linearly with quantity.
Configuration:
- Unit price: The charge per single unit (e.g., £50 per seat)
- Value metric: The unit being priced (e.g., “user seats”)
- Quantity: Fixed quantity on the subscription, or variable (set by the customer or updated by usage events)
Example: SaaS platform at £50 per seat. A customer with 8 seats pays £400/month.
3.3 Volume Pricing
How it works: The total quantity determines which rate band applies, and that rate is applied to the entire quantity.
Configuration:
- Price bands: Define quantity thresholds and the rate per unit for each band
- Bands are evaluated by looking at the total quantity and finding which band it falls in
Example:
Customer uses 200 units → falls in 101–500 band → pays 200 x £0.80 = £160. Customer uses 600 units → falls in 501+ band → pays 600 x £0.60 = £360.
3.4 Tiered Pricing
How it works: Each portion of usage is priced at the rate for the tier it falls within. Units in tier 1 are priced at tier 1’s rate; units in tier 2 are priced at tier 2’s rate.
Configuration:
- Tiers: Define quantity thresholds and the rate per unit within each tier
- All units within a tier are charged at that tier’s rate
Example:
Customer uses 600 units:
- Tier 1: 100 x £1.00 = £100
- Tier 2: 400 x £0.80 = £320
- Tier 3: 100 x £0.60 = £60
- Total: £480
3.5 Stair-Step Pricing
(Glossary: Stair-Step Pricing)
How it works: The total quantity determines a pricing band, and the customer pays the flat price for that band — regardless of how many units they actually use within the band.
Configuration:
- Steps: Define quantity thresholds and a flat price for each step
Example:
Customer uses 101 units → in Step 2 → pays £300 (not £100 + marginal rate on 1 unit). Customer uses 499 units → still in Step 2 → pays £300.
Stair-step pricing creates a strong incentive for customers to manage usage just below a threshold, and a strong upsell signal when they approach the top of a step.
3.6 Dynamic Pricing
How it works: The price per unit or total charge is determined by a rules engine that evaluates conditions at billing time rather than a static configuration.
Configuration:
- Rules: Define conditions and the pricing outcome when each condition is met
- Conditions may include: time of day, day of week, customer segment, geography, external variable inputs
Use cases: Time-of-use pricing for utilities (peak/off-peak rates), demand-based pricing for cloud resources, segment-specific pricing applied at billing time rather than plan level.
3.7 Usage-Based Pricing
(Glossary: Usage-Based Pricing)
How it works: The charge is calculated from metered usage events. Events are aggregated over the billing period and the aggregated total is applied to a pricing calculation (per-unit, tiered, volume, etc.).
Configuration:
- Usage metric: The metric to aggregate (references a configured usage metric definition)
- Aggregation method: Sum, count, max, last value, or percentile
- Pricing applied to aggregated total: Per-unit, tiered, volume, or stair-step
Example: AI API service charges £0.002 per token. A customer uses 2,500,000 tokens in a month. Invoice amount: 2,500,000 x £0.002 = £5,000.
3.8 Hybrid Pricing
How it works: Multiple pricing components are combined in a single plan. Most commonly a fixed base amount plus a variable usage component.
Configuration:
- Component 1 (fixed): A fixed amount charged every period
- Component 2 (variable): A usage-based or per-unit amount charged based on consumption
- Included units: Whether some usage is included in the fixed component before variable billing begins
Example: £500/month base fee + £0.01 per API call above 50,000. A customer making 80,000 calls pays: £500 + (30,000 x £0.01) = £500 + £300 = £800.
4. Entitlement Management
Entitlements define what a customer can access or consume under a plan. Each plan has a set of entitlement definitions that are provisioned automatically when a subscription to that plan is created.
For full entitlement configuration detail, see the Entitlement Management Reference.
Summary of entitlement types:
5. Grandfathering
Grandfathering (Glossary: Grandfathering) is the practice of protecting existing customers from pricing or packaging changes that apply to new customers.
5.1 When to use grandfathering
- You are launching a new pricing model and want existing customers to stay on the old pricing indefinitely
- You are discontinuing a plan but existing customers should remain on it until they choose to change
- You want to reward long-standing customers by maintaining their original pricing
5.2 How grandfathering works in Prolifi
When a plan is grandfathered:
- The plan status is changed from “Active” to “Grandfathered”
- No new subscriptions can be created on the grandfathered plan
- Existing subscriptions on the grandfathered plan continue to renew and bill at the grandfathered plan’s pricing
- Customers on grandfathered plans can be migrated to a current plan at any time via a subscription plan change
Grandfathered plans remain visible in the system for operational purposes but are not available in the public plan catalog.
5.3 Migrating grandfathered customers
When you are ready to migrate grandfathered customers to a current plan:
- Use Prolifi’s bulk subscription update tool to migrate a defined cohort
- Configure whether the migration triggers proration or takes effect at the next billing period
- Consider whether a discount or communication campaign is appropriate to soften the pricing change for affected customers
6. Offers and Acquisition Strategy
6.1 Discounts
Prolifi supports three discount structures:
One-to-one: Applied to a specific customer’s subscription. Used for individually negotiated commercial terms.
One-to-many: A reusable discount code or campaign. Applied to multiple customers via a shared code or automatic application rules.
Targeted: Automatically applied to customers meeting defined criteria (segment, geography, plan type, signup date).
Discount configuration options:
- Type: Percentage off, fixed amount off, or fixed price override
- Duration: Once, N periods, or lifetime of subscription
- Scope: Specific products, specific plans, or any plan
- Stackability: Whether the discount can combine with other active discounts
- Expiry: An end date after which the discount code is no longer valid
6.2 Price ramps
A Price Ramp (Glossary: Price Ramp) schedules price changes over time. Configure at the plan level (for all customers on this plan) or at the subscription level (for a specific customer).
Price ramp configuration:
- Start price: The initial effective price
- Schedule: The dates (or period offsets) at which the price changes and the target price at each step
- Terminal price: The final price the ramp reaches
Price ramps are transparent to customers — the full ramp schedule should be communicated at the time of subscription to avoid unexpected price increases.
6.3 Free trials and promotional periods
Free trials are configured as a property of a plan:
- Trial length (days)
- Whether a payment method is required at trial start
- Entitlement behaviour during the trial (full access or restricted access)
- What happens at trial end (auto-convert to paid, require customer action)
Promotional periods (e.g., “first 3 months free” on an otherwise paid plan) can be configured as a 100% discount for a defined number of periods.
