From Product Feature to Priced Entitlement
Follow one SaaS feature from a product idea to a plan, allowance, price, entitlement check, usage event, and customer experience.
Updated 2026-08-14
Your team shipped AI-generated financial reports.
Customers love them. One report replaces an hour of manual work. Usage is climbing—and so is the model bill. Someone in Monday’s product meeting asks the question that sounds simple:
“Should AI reports be a paid feature?”
Engineering can add a boolean. Marketing can add a row to the pricing table. Finance can pick a number. None of those actions, alone, creates a product customers can understand or a billing system your team can operate.
This guide follows the decision all the way through. By the end, report number 87 will move through your product, Tirdad, and back to the customer—with every responsibility visible.
A feature becomes sellable through four decisions.
The code is only the capability. Customers experience the promise created around it.
Outcome
Finish a financial report in minutes, not hours.
Entitlement
Which customers may generate AI reports?
Allowance
How many reports are included each month?
Price
What happens after the included amount?
The meeting is asking four different questions
When someone says “price the feature,” separate the conversation:
- Value: why does a customer care?
- Access: which customers should receive it?
- Capacity: how much is included?
- Money: what happens when the included amount runs out?
Teams get into trouble when they jump directly from value to money. “Customers save time, therefore charge SAR 99” skips the design work between them.
For our example, the value is specific: a finance team completes a repeatable report in minutes rather than assembling it manually. That tells us more than “the model is expensive” ever could. Supplier cost constrains the price; customer value explains why anyone will pay it.
First decision: should it affect packaging at all?
Charging for every visible feature produces a product full of locks. Including every costly feature produces a business with no economic control. The useful answer comes from segmentation and cost.
Should this feature change the price?
Do not create friction where no meaningful segment exists.
Work through the tree with evidence:
- Small customers create five reports a month; finance teams create hundreds.
- The model cost grows with every successful report.
- Advanced reporting is not necessary to understand the core product.
- Teams that rely on reports already ask for governance and higher limits.
That combination points to a hybrid model: plan-gated access, an included monthly allowance, and a declared rule after the allowance.
The decision is not “make AI paid.” It is:
Growth customers receive 100 successful AI reports each month. Additional successful reports cost SAR 0.50. Starter customers can see what the workflow does but must upgrade to run it. Enterprise limits are contractual.
Now product, sales, finance, engineering, and the customer can discuss the same promise.
Turn the promise into a model
Create one feature identity: ai_reports.
Do not create starter_ai_reports, growth_ai_reports, and enterprise_ai_reports. Those names mix the thing you built with the packages that happen to sell it today. Plans change; the capability should remain stable.
One feature. Three plan promises.
Upgrade to access
SAR 0.50 after allowance
Custom allowance + controls
The model has distinct parts:
| Part | Question it answers | Example |
|---|---|---|
| Feature | What capability exists? | AI reports |
| Entitlement | May this customer use it? | Growth: yes |
| Allowance | How much is included? | 100 per month |
| Meter | What counts as consumption? | Successful report |
| Price | What happens after the allowance? | SAR 0.50 per report |
This separation is what makes future changes survivable. You can raise the Growth allowance without renaming the feature. You can add an Enterprise control without changing the meter. You can test a new overage price without rebuilding access logic.
Define “one report” before engineering does it for you
The most dangerous billing rules are implied rules.
Write the event definition as if a customer were disputing an invoice:
One unit is recorded when an AI report reaches the
completedstate and becomes available to the customer. A failed generation records no unit. Retrying the same report uses the same event identifier and cannot create another unit.
That sentence resolves four implementation questions:
- clicking “Generate” is not billable;
- a completed report is billable;
- a failed model call is not billable;
- an infrastructure retry must not double bill.
Choose the stable identifier from the business object—report_87—not from the delivery attempt. The first attempt and the retry describe the same economic event.
What actually happens at runtime
The customer has used 86 of 100 included reports. They click Generate report.
What happens when the customer generates report 87?
A sequence diagram should expose responsibilities and failure points—not merely show boxes connected by arrows.
The customer starts the business action.
Ask before spending compute or exposing the workflow.
Access and current allowance come from the purchased plan.
Your application performs the product-specific work.
A stable event ID makes retries safe.
The product can update the allowance immediately.
The customer sees value and commercial context together.
The report workflow, AI job, success criteria, and customer experience.
Plan entitlement, allowance, usage ledger, overage rule, and invoice effect.
Notice the boundary:
- Tirdad does not generate the report. That is the product customers chose you for.
- Your application does not calculate plan allowances or reconstruct billing state. That is the commercial system customers bought through.
- The payment provider is not in this sequence. No money moves when an included report is consumed.
The sequence also shows why “just add a feature flag” is incomplete. A flag can hide a workflow, but it does not know what the customer purchased, how much remains, whether the period reset, or what the next unit costs.
Design the four moments the customer will remember
The commercial model is experienced through product copy and behavior—not through your database schema.
1. Before access
Do not show a dead button with a lock icon. Let Starter customers understand the outcome:
Generate finance-ready reports in minutes
Included in Growth with 100 reports each month.
The upgrade is connected to value, not punishment.
2. While using the allowance
Show context near the action when it matters:
14 reports remaining · resets 1 September
Do not make customers search a billing portal to understand whether the next click changes their bill.
3. Near the limit
At a meaningful threshold, explain the consequence:
10 reports remain. Additional reports are SAR 0.50 each. Set a monthly cap →
An alert without a next action only moves anxiety earlier.
4. After the limit
Choose one policy and state it plainly: block, top up, accept an overage, or request approval. “Contact support” should not be the accidental fallback for a commercial decision nobody made.
The implementation contract
Before the work is considered complete, the team should be able to point to one answer for each row:
| Decision | Owner | Source of truth |
|---|---|---|
| Customer outcome and name | Product | Product brief |
| Which plan includes access | Product + commercial | Tirdad entitlement |
| Included monthly amount | Commercial | Tirdad plan configuration |
| Definition of successful use | Product + engineering | Event contract |
| Current consumption | Billing runtime | Tirdad meter |
| Overage rule | Finance + commercial | Tirdad price |
| What the customer sees | Product design | Your application |
If two systems claim the same row, you have a synchronization problem waiting to happen. If no owner claims it, support will eventually make the policy one ticket at a time.
Test the story, not just the endpoint
A useful acceptance test reads like a customer journey:
- A Starter customer cannot generate a report and sees the Growth promise.
- They upgrade; access becomes available at the documented effective time.
- Their first completed report records one unit.
- A failed report records nothing.
- Retrying the first event does not change usage.
- Report 100 consumes the final included unit and explains what comes next.
- Report 101 follows the declared overage or limit policy.
- The invoice quantity can be traced back to the completed report records.
- A downgrade changes future access without rewriting historical usage.
That is considerably more valuable than checking whether GET /entitlements/ai_reports returned true once.
Return to Monday’s question
“Should AI reports be a paid feature?” was too small a question.
The team needed to decide what customers value, which segment receives it, how much is included, what counts as use, what the product shows, and which system owns every decision. Once those answers exist, the technical implementation becomes a faithful expression of the business model.
The finished result is not a locked button and a price. It is a promise that survives the entire journey—from the pricing page to report number 87 to the invoice.