--- name: pricing-subscriptions-checks description: 16 rules from the Noesa course "Pricing and subscriptions, understood". For anyone who sets, integrates or has to explain what a customer is charged — and who now has AI computing those numbers alongside them. --- # Pricing and subscriptions, understood — the rules Use with: Claude Code or Claude (save as a skill), Cursor (save under .cursor/rules as .mdc), ChatGPT or any other assistant (paste the text below into custom instructions or a project's instructions). 16 rules, taken from the course at https://noesa.leafsoft.online/c/pricing-subscriptions Each heading is one thing the course teaches. Most are checks to run on your own output before presenting it as done; a few are background you are expected to have. 10 also name a mistake models make by default, under "Watch for". Apply these to the thing you are producing — the type, the schema, the query, the copy — not only to how you explain it. Where a rule names a field, a format or an identifier, that name belongs in the output. ## Separate the product from the price Take any charge and name its three separate layers: what the thing is, what it is sold as, and what this customer owes. **Watch for:** If you asked an AI to design a pricing table for a subscription product, what would it likely get wrong? It will return tiers with prices attached and stop there, because that is what a pricing *page* looks like in its training data — and a pricing page is the product layer only. What is missing is the sellable shape underneath: no SKU, no term, no unit, no rule for what happens when the quantity changes mid-period. That table cannot be ordered against or renewed from. Ask what identifier a renewal would point at, and the gap becomes obvious immediately. ## Design part numbers that survive Say what belongs inside a SKU and what must never be encoded in one. **Watch for:** If you asked an AI to generate a SKU scheme for your product catalogue, what would it likely get wrong? It produces richly descriptive codes — price, currency, region, year all encoded — because a SKU in its training data looks like a compact description of the item, and more description reads as more useful. That optimises for a human reading the code once, and against every future price change, since each encoded fact freezes at the first order. Ask it which of its fields would force a new SKU when the value changes, and most of them will. ## Choose a model from how value scales Pick between per-seat, usage, tiered and flat pricing by asking how the customer's value actually grows. ## Model the lifecycle as states Draw your subscription lifecycle as named states with the events that move between them, and say which states still grant access. **Watch for:** If you asked an AI to design the states for a subscription billing system, what would it likely get wrong? It returns the tidy path — trialing, active, cancelled, expired — because that is the sequence described in most documentation, and documentation describes the intended flow rather than the operational one. What it omits is the dunning middle: past due, suspended, and the decision about who keeps access while a payment is retried. Those states carry the money, so ask specifically what happens between a failed charge and a locked account. ## Drive the lifecycle without losing money Name the three places a subscription API loses money, and the property that closes each. **Watch for:** If you asked an AI to write the integration that syncs subscription changes to your product, what would it likely get wrong? It writes the happy path and stops: receive the event, apply the change, return 200. Idempotency, effective dates and reconciliation are operational scar tissue rather than the shape of the task, so they are absent from the pattern it is completing. Their absence produces no test failure and no error, only double charges and quiet divergence weeks later. Ask explicitly what happens on duplicate, late and missing delivery. ## Compute a proration you can defend Produce a prorated amount line by line, and say when not to prorate at all. **Watch for:** If you asked an AI to calculate a mid-term proration for a subscription change, what would it likely get wrong? It returns a single confident number, having silently chosen a denominator, an inclusivity rule and a rounding point — usually a flat thirty-day month, because that is the most common worked example. The arithmetic will be right and the policy may not be yours, and nothing in the answer will indicate a choice was made. Ask it to show the units and state its denominator, then check that against what your billing system actually does. ## Cancel, refund, and what you owe back Say what a cancellation owes the customer, and distinguish cancelling now from cancelling at period end. **Watch for:** If you asked an AI to design a subscription cancellation flow, what would it likely get wrong? It builds the cancel path — confirm, revoke access, mark cancelled — and treats the money as an afterthought or omits it entirely, because cancellation reads as an access problem in most examples. The commercially important decisions are the ones it skips: whether access continues to period end, whether the unused portion is refunded, and what the confirmation tells the customer before they commit. Specify the policy yourself; it cannot infer which of three legitimate ones is yours. ## Change a plan mid-term Specify an upgrade and a downgrade separately, and say when each takes effect. **Watch for:** If you asked an AI to implement plan upgrades and downgrades, what would it likely get wrong? It implements them symmetrically — one change-plan function, prorate in both directions, effective immediately — because that is the elegant shape and the asymmetry is commercial rather than technical. The result quietly converts annual commitments into monthly ones, and nothing in the code looks wrong. State the two rules separately and treat them as different operations. ## Give a discount you can withdraw Specify a discount with a scope, a duration and an expiry, and predict what it costs at renewal. ## Separate entitlement from billing Explain why entitlement and billing are different systems, and what happens when they disagree. **Watch for:** If you asked an AI to design how customer permissions follow a subscription, what would it likely get wrong? It tends to collapse the two, deriving permissions directly from the current plan, because that is the clean model and it is right most of the time. What it loses is every grant that did not come from a purchase — trials, courtesy seats, support fixes, grandfathered features — which then vanish silently the next time entitlement is rebuilt from billing. Ask where a manually granted seat is recorded and what happens to it at renewal. ## Activate and revoke a licence Describe the window between payment and access, and what must happen if either side fails. ## Raise a price without losing the account Plan a price rise with a cohort, a notice period, and a decision about who is exempt. ## Write the price-change message Write a price-change notice a customer forwards to their finance team rather than to their lawyer. **Watch for:** If you asked an AI to write a price increase email to your customers, what would it likely get wrong? It produces the corporate register — excited to share, continued investment, delivering value — and buries or omits the actual figures, because that is overwhelmingly what price-change emails in its training data look like. The genre it is imitating is the one customers have learned to distrust. Give it the two numbers, the date and the total, and tell it to open with them. ## Hand the ledger what it needs List the fields accounting needs from every billing event, and say what each one prevents. ## Publish a price a machine can read Say what an AI agent reads when it quotes your price, and which of your prices it will get wrong. **Watch for:** If you asked an AI what a specific software product costs for a given number of users, what would it likely get wrong? It answers with the most prominent number it can find and multiplies. It does that because a pricing page reads as a price list, and the qualifying conditions — term, currency, entity, band, what is excluded — are usually in prose the page assumed a salesperson would explain. The result is a confident quote missing every condition that makes it true, delivered to a customer who now believes it came from you. Publish the conditions with the number, and check what an assistant currently says about your own product. ## Run one SKU end to end Take one sellable thing from catalogue entry to activated, discounted, prorated, booked and renewed, and find the step your system cannot do.