Traditional Recurring Subscription

this guide explains how to implement a subscription only pricing model in this model, customers pay a fixed recurring fee for access to your product there is no usage based billing or overages the scenario you are building a saas product that charges customers based on seats your pricing model $500 per month includes up to 10 seats there are no overage charges in this version the subscription fee covers access to the product core concept fixed monthly fee → access to product → no usage based charges this is the simplest pricing model step 1 define what the subscription represents even though billing is not usage based, it is still important to define what the customer is paying for in this example the subscription includes 10 seats you may still track seat usage internally, but it is not required for billing in this model step 2 create a pricing plan where to configure go to pricing create a new pricing plan configure name team plan billing period monthly step 3 add a subscription rate where to configure add a subscription rate (previously called flat rate) configure label team plan subscription rate $500 billing options select beginning of billing period this ensures the subscription is charged at the start of each cycle step 4 assign the plan to a customer where to configure go to customers select a customer assign the pricing plan once assigned, the customer will be billed the subscription amount each billing period example outcome a customer is subscribed for one full billing period billing calculation monthly subscription = $500 there are no additional charges, regardless of how the product is used optional tracking seats even though seats are not used for billing in this example, you may still want to track them you can do this by creating a seats meter sending usage events when seats are added or removed this allows you to monitor usage enforce limits externally prepare for future pricing changes when to use this model subscription only pricing is best when usage is predictable you want simple, predictable billing you are early in product development you do not need granular usage based pricing understanding cost behind the subscription even if you are not billing based on usage, your system is still generating cost you can (and should) meter the underlying activity that drives your product, such as api calls llm tokens background processing jobs infrastructure usage this data is not used for billing in this model, but it is critical for understanding the true cost of your plans measuring margins identifying inefficiencies making pricing decisions over time these usage signals can be attributed to internal systems and analyzed separately from billing for internal cost tracking and attribution, see workloads docid\ xtorhvsoi2aok1bzpwfdu how this can evolve many products start with subscription only pricing and later expand to subscription + overages usage based pricing tiered pricing see the hybrid subscription guide for adding included usage and overage billing this model provides simplicity and predictability, while still allowing you to understand the underlying cost structure of your product