# Scenario: full reference > Scenario connects to Stripe, QuickBooks, Xero, FreeAgent or Sage and gives founders a business health score, a trained revenue forecast and plain-English answers to what-if questions about pricing, churn, hiring and growth. Website: https://use-scenario.com. UK-based, prices in pounds. Contact: via https://use-scenario.com/help. ## In one line AI understands the question. Scenario does the maths: an AI works out what the founder is asking, and every figure comes from Scenario's own calculation engine on the business's real data, never from an AI's guess. ## Who it's for - Founders of subscription businesses that bill through Stripe (SaaS, memberships, subscription boxes). - UK small businesses that run their books in QuickBooks, Xero, FreeAgent or Sage (for example estate agents, agencies, consultancies), with income split into recurring and one-off. ## What it does - A business health score from 0 to 100 from up to seven parts (growth, keeping customers or steady income, getting paid, next month, customer spread, covering costs, runway), each with its reason and how many points fixing it would add. - Next month's revenue forecast with a likely range, trained on the business's own history and tested on months it wasn't trained on. - What-if scenarios (prices, churn, new customers, hires and costs), saved and compared side by side with their effect on runway (Scenario Studio). - Runway: a 24-month cash projection and whether the business is default alive or default dead, and when. - Stripe products and payments: revenue, subscribers and churn by product and price; payments collected, failures in plain words, money recovered by retries, refunds and disputes. - Customers by name: everyone paying, with a status (at risk, renewing soon, new, loyal), a profile with every payment, search, and a CSV export. Failed payments still unpaid and customers who just left are listed with a message ready to copy. - The assistant can look up a customer, the newest payments, or search Stripe by email, card's last four digits or amount; draft a message to a customer; save a revenue goal; and add a hire, cost or funding to the runway plan. Customer names and emails are never sent to the AI: it sees a reference, and the name is shown on the founder's screen. It can't make changes in Stripe. - Without Stripe or accounting software: three rough numbers (money in, money out, cash) give a runway at once, or a CSV bank statement is sorted into monthly totals (the transactions aren't kept). - Scenario Analytics: cookieless website analytics on every plan (Free 1 site, Solo 2, Growth 5, Team 20). Visitors, sources, pages, countries, devices, real-user Core Web Vitals and an on-demand speed test. No cookies, no IP addresses or browser details stored, one line to install. - A daily brief, monthly investor update drafts, and an assistant that answers questions in plain English and remembers what the founder tells it. - Use inside ChatGPT, Claude, Gemini and Cursor on paid plans (MCP). ## Data and trust - Read-only connections: Scenario can't make charges, issue refunds or change subscriptions. - Customer names are replaced with aliases before any AI sees them. - Figures are estimates from the business's data and stated assumptions, not financial advice. - Scenario is not affiliated with, endorsed by or sponsored by Stripe, Inc. ## Pricing (GBP) - Try Free: £0, no card needed, 20 credits a month. - Solo: £12 a month or £120 a year; 200 credits a month. For founders making regular decisions. - Growth: £29 a month or £288 a year; 600 credits a month. For a business that wants a closer view. - Team: £79 a month or £780 a year; 2,000 credits a month. For more questions across the business. ## Benchmarks Simulated businesses, each replayed with only the data known at the time, forecasting revenue 30 days ahead. Only measures that held on every run are stated: - Against GPT‑6‑Astra (OpenAI's frontier model, at medium reasoning, given the same figures): real revenue inside the forecast range: Scenario 84%, GPT‑6‑Astra 77%; forecasts within 5% of the real figure: Scenario 55%, GPT‑6‑Astra 53%. 3 runs, 456 forecasts of revenue 30 days ahead on simulated businesses, each replayed with only the data known at the time. GPT‑6‑Astra at medium reasoning, given the same figures. Head to head and on average miss the two were even. Simulated data, 29 Sept 2026. Your results will vary. - Against a plain AI (gpt-oss-120b) (an open model given the same figures): real revenue inside the forecast range: Scenario 84%, Plain AI 50%; forecasts answered: Scenario 100%, Plain AI 87%. 3 runs, 528 forecasts of revenue 30 days ahead on simulated businesses, each replayed with only the data known at the time. Plain AI: gpt-oss-120b given the same figures. Simulated data, 27 Sept 2026. Your results will vary. ## Help centre ### What is Scenario? Scenario is an AI finance partner for founders. It connects to your Stripe account or your accounting software and gives you a business health score, a forecast for next month's revenue and plain-English answers to what-if questions about pricing, churn, hiring and growth. ### Which tools does Scenario connect to? Stripe for subscription revenue, and QuickBooks, Xero, FreeAgent or Sage for income, costs, profit and cash. Every connection is read-only. You can also upload files and tell Scenario things in chat, such as your monthly costs or a quiet season. ### Does it work if my business doesn't use Stripe subscriptions? Yes. Connect your accounting software and Scenario reads your income by account, splits it into recurring income (such as lettings fees or retainers) and one-off income (such as commission or projects), and forecasts both. ### What is the business health score? A score from 0 to 100 built from parts such as growth, keeping customers or steady income, getting paid, next month's outlook, covering costs and runway. Each part shows its reason and how many points it could add, so you can see what to fix first. ### How does Scenario forecast next month? From your own history. For subscriptions it learns who renews and pays; for your accounts it picks the method that has predicted each income stream best. It is tested on past months it was not trained on, and shows a likely range with how far off it has typically been. ### How does a what-if scenario work? Ask a question such as “What if I raise prices by 15%?” or “What if I hire someone at £2,500 a month?”. Scenario runs it through its engine on your numbers and shows the difference, with the assumptions it made. Nothing is changed or saved. ### Can Scenario change anything in my Stripe account? No. The Stripe connection is read-only. Scenario cannot make charges, issue refunds or change subscriptions. ### Can I see my customers and payments, not just totals? Yes. With Stripe connected, Customers lists everyone paying you by name with a status (at risk, renewing soon, new, loyal), Products shows revenue by plan and price, and Payments shows what was collected, what failed and why. Failed payments still unpaid and customers who just left appear under Needs attention, each with a message ready to copy. ### Does the AI see my customers' names? No. Customer names and emails are never sent to an AI. The assistant refers to each customer by a reference such as C-7K2QFM, and the real name is filled in on your screen. When you search by a name or email, the matching happens on Scenario's server. ### What is Scenario Analytics? Cookieless website analytics, built into Scenario. Add one line to your site and see visitors, where they came from, top pages and real visitors' page speed, next to the new subscribers you got on the same days. It stores no IP addresses or cookies. Paid plans also check your site is up every 5 minutes. ### I don't use Stripe or accounting software. Can I still use Scenario? Yes. On Home, type what comes in and goes out each month and your cash in the bank, and Scenario shows what's left over and how long your cash lasts. Or import a CSV bank statement: Scenario sorts your spending into kinds and keeps only the monthly totals, never the transactions. ### Is this financial advice? No. Scenario's figures are estimates from your data and stated assumptions. They cannot predict what customers will do or replace advice from a qualified professional. ### How do I get started? Create a free account, connect Stripe or your accounting software from Integrations, and ask Scenario a question. With Stripe, your revenue, customers and latest payments show straight away; the health score and forecast follow once there are two months of history. No Stripe? Type three rough numbers or import a bank statement for a first picture. ### How do I download or delete my data? In Settings, “Download your data” gives you everything Scenario holds as one file, and “Delete account” permanently removes your account and business data, cancelling any Scenario subscription first. ## Blog ### Customer lifetime value (LTV): how to work it out simply https://use-scenario.com/blog/customer-lifetime-value · 1 October 2026 Short answer: Customer lifetime value is what an average customer pays you before they leave. For a subscription business, divide what a customer pays a month by your monthly churn rate. At £30 a month and 5% churn, that's £30 ÷ 0.05 = £600. **Customer lifetime value** (LTV) is what an average customer pays you before they leave. For a subscription business the simple version needs two numbers you probably already know: what a customer pays a month, and your monthly churn rate. Divide the first by the second. A customer paying £30 a month, at 5% monthly churn, is worth about £30 ÷ 0.05 = **£600**. That number answers questions founders ask every week: how much can I spend to win a customer, is a cheaper plan worth it, and what is keeping a customer for a few more months actually worth? #### The simple formula **Lifetime value = average monthly revenue per customer ÷ monthly churn rate** It works because 1 ÷ churn is the average number of months a customer stays. At 5% monthly churn, the average customer stays 1 ÷ 0.05 = 20 months, so a £30-a-month customer pays about 20 × £30 = £600. If you don't know your churn rate yet, our guide on [how to calculate churn rate](/blog/how-to-calculate-churn-rate) shows how, and the free [churn calculator](/saas-churn-calculator) works out churn, lifetime and lifetime value together. #### Why churn matters more than price Look at what happens to the same hypothetical customer at different churn rates: | Monthly churn | Average lifetime | LTV at £30 a month | |---|---|---| | 10% | 10 months | £300 | | 7% | about 14 months | about £430 | | 5% | 20 months | £600 | | 3% | about 33 months | about £1,000 | Going from 5% to 3% churn adds about £400 to every customer's value, without changing your price at all. To get the same lift from pricing alone, you'd need to raise the price by about two thirds, from £30 to £50, and keep every customer. That's why reducing churn is usually the cheapest growth there is. It's also why lifetime value is such a sensitive number: small changes in churn swing it a lot, so work it out from a few months of churn, not one. #### Gross margin: the honest version Revenue isn't all yours to keep. If each customer costs you something to serve (hosting, payment fees, support time), the more honest lifetime value uses **gross margin**: the share of revenue left after those costs. **Lifetime value (margin) = monthly revenue per customer × gross margin ÷ monthly churn rate** Say the same £30-a-month customer costs about £6 a month to serve, so your gross margin is 80%. Their margin-based lifetime value is £30 × 0.8 ÷ 0.05 = **£480**. It's this number you should compare with what you spend to win a customer. #### Using LTV: what can you spend to win a customer? The cost of winning a customer, **customer acquisition cost** (CAC), is everything you spend on marketing and sales in a month divided by the new customers you got that month. If lifetime value is well above acquisition cost, every new customer pays for themselves and then some, and spending more on growth makes sense. If the two are close, each new customer barely pays back what they cost, and growing faster just burns cash faster. The other thing to watch is **payback**: how many months of a customer's payments it takes to cover what you spent to win them. For a small business without much cash, a short payback matters as much as a high lifetime value, because the money has to come back before you run out. The [runway calculator](/runway-calculator) shows how long your cash lasts while you wait. #### Common mistakes - **Using a churn rate from one good month.** It makes lifetime value look far higher than it is. Average three to six months. - **Mixing monthly and annual customers.** Annual customers churn on a different rhythm. Work their lifetime value out separately, or convert everything to monthly carefully. - **Forgetting that new customers behave differently.** Many subscription businesses lose more customers in the first month or two than later on. If that's you, a lifetime value from overall churn will be too low for customers who stick around and too high for brand-new ones. - **Treating it as a promise.** Lifetime value is an average from the past, not a forecast of any one customer. #### Doing it automatically Scenario connects to Stripe, read-only, and works out revenue per customer, churn and how long customers stay from your real subscription history, by plan as well as overall. You can see what each plan brings in on a sample business in the [live demo](/demo/products). #### The takeaway Divide what a customer pays a month by your monthly churn rate, and use gross margin if serving customers costs you much. Then put most of your effort into churn: a couple of points less churn is worth more than almost any price rise, and it makes every customer you win worth more. --- ### How to calculate churn rate, and what it really costs you https://use-scenario.com/blog/how-to-calculate-churn-rate · 1 October 2026 Short answer: Divide the customers who cancelled in a month by the customers you had at the start of that month. 10 cancellations from 200 customers is 5% monthly churn. Divide 1 by that to get how many months a customer stays on average. Here's how to calculate churn rate: take the customers who cancelled during a month and divide by the customers you had at the start of it. If you started the month with 200 paying customers and 10 cancelled, your monthly churn is 10 ÷ 200, or **5%**. That one number tells you more about the health of a subscription business than almost any other, because it decides how hard you have to run just to stay where you are. This guide covers the two kinds of churn worth tracking, the mistakes that make the number lie, and how to turn churn into the figure founders actually care about: what a customer is worth. #### Customer churn: the simple version Customer churn counts people, not money. **Monthly customer churn = customers who cancelled in the month ÷ customers at the start of the month** A few rules keep it honest: - **Use the count at the start of the month.** New customers who joined and left in the same month are a separate problem (usually onboarding), and including them in the bottom of the sum flatters the result. - **Count a cancellation when the paying stops,** not when someone clicks a button. A customer who cancels on the 3rd but is paid up to the 28th leaves when the period ends. - **Leave out failed payments that recover.** A card that fails on Monday and goes through on Thursday isn't churn. One that stays unpaid until the subscription ends is. Say you run a booking tool for dentists with 200 customers at the start of September. 10 cancel during the month and 18 new ones join. Customer churn is 10 ÷ 200 = 5%, whatever happened with the new sign-ups. You grew to 208 customers, but you lost 5% of the ones you had. #### Revenue churn: the version your bank account feels Customers don't all pay the same. Losing your biggest customer hurts far more than losing your smallest, and customer churn can't tell the difference. Revenue churn can. **Monthly revenue churn = monthly recurring revenue lost to cancellations and downgrades ÷ monthly recurring revenue at the start of the month** Take the same hypothetical business with £6,000 of monthly recurring revenue (MRR) at the start of September. The 10 customers who left were mostly on the cheaper plan and paid £240 a month between them. Revenue churn is £240 ÷ £6,000 = **4%**, lower than the 5% customer churn because the customers who left were smaller than average. If the opposite were true, and the leavers were your bigger customers, revenue churn would be higher than customer churn. That's the more dangerous pattern, and it's easy to miss if you only watch the customer count. ### Net revenue churn Some businesses also track **net** revenue churn, which takes away the extra revenue from existing customers who upgraded. If the same business gained £300 from upgrades, net revenue churn would be (£240 − £300) ÷ £6,000, which is negative: revenue from existing customers grew even after the cancellations. That's a strong sign customers get more value over time. #### What churn costs you: lifetime and lifetime value Churn becomes much easier to reason about once you turn it into time. **Average customer lifetime (months) = 1 ÷ monthly churn** At 5% monthly churn, the average customer stays 1 ÷ 0.05 = **20 months**. At 3%, about 33 months. At 7%, about 14. Multiply that by what a customer pays and you get **lifetime value (LTV)**: what an average customer brings in before they leave. **Lifetime value = average monthly revenue per customer × average lifetime in months** In the example, customers pay £30 a month on average, so at 5% churn each one is worth about £30 × 20 = **£600**. Cut churn to 4% and the lifetime becomes 25 months, worth £750. Nothing else changed: same price, same product, a quarter more value from every customer. That's why churn deserves attention before most other growth work. It quietly sets the ceiling on what you can afford to spend to win a customer. #### How churn compounds over a year Monthly churn looks small. Over a year it isn't. | Monthly churn | Customers left after 12 months (from 100, with no new sign-ups) | |---|---| | 2% | 78 | | 5% | 54 | | 7% | 42 | | 10% | 28 | At 5% a month, almost half of today's customers are gone within a year. Every one of them has to be replaced by a new sign-up before you've grown at all. If your new sign-ups only just cover your churn, the business can feel busy and still stand still. You can try your own numbers in the free [churn calculator](/saas-churn-calculator), which works out customer churn, revenue churn, lifetime and lifetime value in one go. #### Mistakes that make churn look better than it is - **Averaging over a quarter without saying so.** Three months of cancellations divided by one month's customer count makes churn look three times worse. Three months divided by the count at the start of the quarter, then reported as "monthly", makes it look better than it is. Pick monthly and stick to it. - **Ignoring annual plans.** A customer on a yearly plan can only churn once a year. If a third of your customers are annual, a calm month may just mean few renewals were due. Look at churn for monthly and annual customers separately. - **Counting paused accounts as active.** If someone isn't paying, they aren't a customer this month. - **Looking at one month.** One bad month can be noise. A rising line over three or four months isn't. #### What to do about it Start with who's leaving and when. Churn that clusters in the first one or two months is usually an onboarding problem: customers never got the value they signed up for. Churn spread evenly over time is more often about price, a competitor, or the product not keeping up. Two cheap fixes help almost every subscription business: 1. **Chase failed payments quickly.** Some churn isn't a decision at all, just an expired card. A short, friendly message asking a customer to update their details often saves the subscription. 2. **Ask everyone who leaves why.** One sentence, sent personally. The answers are the most useful product research you'll get. Scenario does both from your Stripe data: it shows which customers are at risk, flags failed payments, and drafts the message for you. You can see how it works on the [live demo](/demo). #### The takeaway Calculate churn every month, the same way each time: cancellations ÷ customers at the start of the month. Track revenue churn next to it, turn it into a lifetime with 1 ÷ churn, and remember that a point of churn saved is worth months of extra revenue from every customer you already have. --- ### How to calculate MRR (monthly recurring revenue) properly https://use-scenario.com/blog/how-to-calculate-mrr · 1 October 2026 Short answer: MRR is the monthly value of every active subscription today. Add up what each paying customer pays per month, turning annual plans into a monthly figure (divide by 12), and leave out one-off charges, unpaid trials and customers who have already cancelled. Here's how to calculate MRR, or monthly recurring revenue: add up what every active subscription is worth per month, today. If 40 customers pay £29 a month and 5 pay £290 a year, your MRR is (40 × £29) + (5 × £290 ÷ 12), which is £1,160 + about £121, or roughly **£1,281**. That's it. The hard part isn't the sum, it's deciding what counts. This guide covers what belongs in MRR, what doesn't, and how to break it down so it tells you why it moved. #### What counts as MRR MRR is a snapshot of recurring revenue you can expect next month if nothing changes. So it includes: - **Every active, paying subscription,** at what the customer actually pays after any discount. - **Annual and quarterly plans, turned into a monthly figure.** A £290 yearly plan is about £24 a month of MRR, not £290 in the month it was paid. - **Add-ons and extra seats** that bill every period. It leaves out: - **One-off charges:** setup fees, consulting, a one-time purchase. They're revenue, but not recurring. - **Free trials and unpaid accounts.** A trial becomes MRR when the first payment goes through. - **Customers who have already cancelled,** even if their paid period hasn't ended yet. Many founders count them until the period ends; either is defensible, but pick one rule and keep it. - **Tax.** VAT you collect belongs to HMRC, not to you. ### Discounts and coupons Use the price the customer actually pays. If a customer is on £29 a month with a 50% discount for three months, they contribute £14.50 of MRR now and £29 once the discount ends. Counting the full price makes MRR look better than your bank balance will. #### Why MRR moves: the four parts A single MRR number tells you where you are. Splitting the change into parts tells you why. | Part | What it is | |---|---| | **New MRR** | From customers who started paying this month | | **Expansion MRR** | Extra from existing customers who upgraded or added seats | | **Contraction MRR** | Lost from existing customers who downgraded | | **Churned MRR** | Lost from customers who stopped paying | **This month's MRR = last month's MRR + new + expansion − contraction − churned** Say a hypothetical design tool started September at £4,000 of MRR. It gained £600 from new customers and £150 from upgrades, lost £50 to downgrades and £300 to cancellations. September ends at £4,000 + £600 + £150 − £50 − £300 = **£4,400**. The headline says MRR grew 10%. The parts say more: new sales are doing the work, and cancellations are taking back half of them. That points to where to spend the next month, and it's invisible in the single number. If cancellations are the big leak, our guide on [how to calculate churn rate](/blog/how-to-calculate-churn-rate) shows how to measure it properly. #### Common mistakes - **Counting annual payments in full.** A £1,200 annual plan paid in March makes March look huge and every other month look empty. Divide by 12. - **Mixing currencies without converting.** If you bill in pounds and dollars, convert to one currency at a consistent rate before adding. - **Counting failed payments as MRR for months.** A subscription whose payment keeps failing isn't really paying. Decide after how long it stops counting, usually when the subscription is cancelled for non-payment. - **Using revenue from your bank statement.** Payouts arrive late, in batches, minus fees. MRR is about subscriptions, not deposits. #### MRR, ARR and runway **ARR (annual recurring revenue)** is MRR × 12. It's useful for talking to investors and for businesses with mostly annual plans. Day to day, MRR moves faster and shows problems sooner. MRR also feeds the question that keeps founders up at night: how long will the cash last? Once you know MRR and your monthly costs, try the [runway calculator](/runway-calculator) to see when the lines cross. And when you hit a round number, it's worth marking. The [milestone card maker](/mrr-milestone-card) makes a clean image for your first £1k, £5k or £10k of MRR. #### Doing it automatically Working out MRR by hand from a spreadsheet is fine at 20 customers and painful at 200, especially once upgrades, discounts and annual plans mix in. Scenario connects to Stripe, read-only, and keeps MRR up to date every day, split into new, expansion, contraction and churn, with revenue by product and a forecast for next month. You can see it on a sample business in the [live demo](/demo). #### The takeaway MRR is the monthly value of every active subscription today, at the price people actually pay, with annual plans divided by 12 and one-offs left out. Track how it splits into new, expansion, contraction and churned every month, because the parts tell you what to do next, and the total only tells you where you are. --- ### Stripe failed payments: why they happen and how to win them back https://use-scenario.com/blog/stripe-failed-payments · 1 October 2026 Short answer: Most Stripe failed payments on subscriptions aren't customers leaving: the card expired, the account was short that day, or the bank wanted extra verification. Turn on retries, send a short personal message to anyone whose payment is still unpaid after a few days, and check the decline reason first. Stripe failed payments are one of the quietest ways a subscription business loses money. A customer who never meant to leave has a payment declined, nobody notices, the retries run out and the subscription is cancelled. In the numbers it looks exactly like churn. In reality it's a card that needed updating. This guide explains why payments fail, what the decline reasons mean, and a short routine to win more of them back. #### Why subscription payments fail When Stripe charges a card, the customer's bank decides whether to approve it. When it says no, Stripe records a **decline code** explaining why, as far as the bank is willing to say. Stripe's documentation lists [every decline code and what it means](https://docs.stripe.com/declines/codes). For subscriptions, a handful come up again and again: | Decline reason | What it usually means | What helps | |---|---|---| | `insufficient_funds` | Not enough money in the account that day | A retry a few days later, often after payday | | `expired_card` | The card on file has expired | Asking the customer to update their card | | `card_declined` / `generic_decline` / `do_not_honor` | The bank declined without saying why | A retry, then a message if it keeps failing | | `authentication_required` | The bank wants the customer to confirm (3D Secure) | Sending the customer a link to confirm the payment | | `processing_error` | Something went wrong between the banks | Usually a retry fixes it | | `lost_card` / `stolen_card` | The card has been cancelled | A new card from the customer | The pattern to notice: very few of these are the customer deciding to leave. They're timing, admin and security checks. #### Step 1: let Stripe retry for you Stripe Billing can retry failed subscription payments automatically. Its [Smart Retries](https://docs.stripe.com/billing/revenue-recovery/smart-retries) choose when to try again, rather than on a fixed schedule. Check it's turned on in your Stripe Billing settings, and check what happens when the retries run out: whether the subscription is cancelled, marked unpaid, or left past due. Retries alone recover the timing problems, like `insufficient_funds` and `processing_error`. They can't fix an expired card. #### Step 2: tell customers, early and personally Stripe can also email customers when a payment fails, with a link to update their card. Turn that on too. But automated emails are easy to ignore, and a short personal note from the founder often gets a reply where the automatic one didn't. Keep it short, friendly and blame-free: > Hi Sam, a quick heads-up: your latest payment of £29 didn't go through. Could you update your card details when you get a moment? Thanks! Send it after the first retry fails, not after the last. The earlier the customer knows, the more time there is to fix it before the subscription ends. #### Step 3: look at the reason before you chase The decline reason tells you what to say: - **Expired card:** ask for new card details. There's no point waiting for a retry. - **Insufficient funds:** be gentle. A retry after a few days often works by itself, and a pushy message can lose a customer who was going to pay anyway. - **Authentication required:** the customer needs to approve the payment. Send them the link to do it. - **Lost or stolen card:** they'll need to add a new card. A short message saying so is helpful, not awkward. #### Step 4: watch the trend, not just the list A few failed payments every month is normal for any subscription business. What matters is whether it's changing. Keep an eye on: - **The share of payments that go through,** month on month. A drop can point to a problem on your side, such as a payment method that's stopped working or a checkout change. - **Money recovered by retries.** It shows whether your retry settings are doing their job. - **Failed payments that turned into cancellations.** That's the churn you could have prevented, and it's worth counting separately from customers who chose to leave. Our guide on [how to calculate churn rate](/blog/how-to-calculate-churn-rate) explains why mixing the two makes churn harder to fix. #### How Scenario helps Scenario reads your Stripe payments (read-only) and puts this routine in one place. The Payments page shows how many payments went through, what failed and why in plain words, and how much retries recovered. A "Needs attention" list shows each failed payment that's still unpaid, with a short message ready to copy and a link to the invoice in Stripe. You can see it on a sample business in the [live demo](/demo/payments). #### The takeaway Most failed payments are fixable. Turn on retries, read the decline reason, and send a short personal message to anyone still unpaid after the first retry. Then track recovered payments separately from real cancellations, so your churn number tells you about customers who chose to leave, not cards that expired. --- ### AI revenue forecasting: how a calculator beat GPT-6-Astra https://use-scenario.com/blog/ai-revenue-forecasting-gpt-6-astra · 29 September 2026 Short answer: Over three runs and 456 forecasts on simulated businesses, real revenue landed inside Scenario's forecast range 84% of the time vs 77% for GPT-6-Astra, and within 5% slightly more often (55% vs 53%). Head to head, they were even. AI revenue forecasting sounds like a job for the biggest model you can find. Give it your numbers, ask what next month looks like, get an answer. We tested that idea against Scenario's own forecast engine, lost the first round to a free model, rebuilt the engine, and then beat OpenAI's GPT-6-Astra on the measure that had beaten us. This is the whole story, including the bit where we lost. #### How the test works Forecasts are easy to make and hard to check. Anyone can say "next month will be £12,000". The question is how often that kind of statement turns out right, and you only find out by testing on months the forecaster hasn't seen. So the benchmark replays businesses month by month. At each point, everyone gets only the data that existed at that moment: the subscriptions, the invoices, the payments so far. Nobody can peek at what happened next. Then everyone forecasts revenue 30 days ahead, and we compare each forecast with what really happened. The businesses are simulated: ten made-up subscription businesses with realistic patterns (growth, cancellations, failed payments, the odd bad month), generated from a fixed seed so the test can be repeated exactly. Simulated data is a limitation, and we'll say so every time we quote a figure. It's also the only way to run a fair test before you have years of real customer history. Two simple yardsticks run alongside, because any forecast worth having should beat them: - **Nothing changes:** next month equals this month. - **The recent trend carries on:** whatever the last few months did, keep doing it. #### Round one: a free AI beat us On 27 September we ran the first version of the engine against gpt-oss-120b, a free, open model, given exactly the same figures. Some of it went well. Across three runs and 528 forecasts, the real revenue landed inside Scenario's forecast range 84% of the time, against 50% for the AI. And Scenario gave a usable forecast every time, while the AI failed to produce one 13% of the time. But on the number most people care about, how close the forecast lands, the free model won. It landed within 5% of the real figure 54% of the time. Our engine managed 49%. That stung, and it was useful. A forecast engine that can't beat a general-purpose chatbot on its own job needs work, whatever else it does well. #### What we changed Scenario's forecast doesn't ask anyone to guess a total. For a subscription business it works from the bottom up. For every subscription it asks two questions: will this invoice get paid, and will this customer renew? It learns both chances from the business's own history. Then it adds new customers at the pace the business has recently been winning them, and blends the result with the two yardsticks above, in proportions learned from what has worked best for that business. Version two tightened how those chances are learned and how the blend is chosen, so the engine leans on whichever approach has actually predicted that business well, month by month. Same principle, better calibrated. #### Round two: Scenario vs GPT-6-Astra On 29 September we tested the new engine against GPT-6-Astra, OpenAI's frontier model, at medium reasoning. Same ten simulated businesses, same replay, same figures for both. One run, 104 forecasts. | Measure | Scenario | GPT-6-Astra | |---|---|---| | Within 5% of the real figure | **56.7%** | 49.0% | | Closer to the real figure, head to head | **55.8%** | 44.2% | | Real figure inside the stated range | 86.5% | 80.8% | | Average miss | 7.9% | 8.4% | In plain English: Scenario's forecasts landed within 5% of the real figure 57% of the time, vs 49% for GPT-6-Astra given the same data. Head to head, Scenario's forecast was the closer one in 56% of cases. It wasn't a landslide, and we won't pretend it was. The average miss was close: 7.9% against 8.4%. GPT-6-Astra is a genuinely capable model, and it did far better than the "nothing changes" yardstick. But on the measure that beat us two days earlier, the engine went from 49% to 57%, and the frontier model came in at 49%. *One run, 104 forecasts on simulated businesses, 29 September 2026. Your results will vary.* #### Update: we ran it twice more One run can flatter you, so later the same day we ran the test twice more, on two new sets of ten simulated businesses. Three runs, 456 forecasts in all, pooled: | Measure | Scenario | GPT-6-Astra | |---|---|---| | Real figure inside the stated range | **84%** | 77% | | Within 5% of the real figure | **55%** | 53% | | Closer to the real figure, head to head | 51% | 49% | | Average miss | 8.0% | 8.0% | The first run was the best of the three for us. Across all three, the head-to-head result is a coin flip and the average miss is identical. Two things held up in every run: Scenario landed within 5% more often (narrowly), and its range held the real figure clearly more often. That second one matters most. A forecast you can plan around is one whose range you can trust. *Three runs, 456 forecasts on simulated businesses, 29 September 2026. Your results will vary.* #### Why a calculator can beat a frontier model It isn't that the AI is bad at maths. It's that forecasting revenue isn't really a language problem. A language model reads your figures and writes the most plausible continuation. It's very good at that, and it will often land somewhere sensible. But it isn't learning each customer's chance of renewing from your history, it isn't testing itself on your past months, and it gives a slightly different answer each time you ask. A forecast engine does the boring parts properly. It counts every subscription. It measures how often invoices really get paid. It checks which method would have worked on your last few months before trusting it with the next one. And it gives the same answer for the same data, every time, which matters when you're about to make a decision on it. That's why Scenario is built the way it is: **the AI understands the question, and the engine does the maths.** You can ask in plain English, "what does next month look like if I lose my two biggest customers?", and the numbers in the answer still come from the calculation, not from a guess. #### What the numbers don't say A few honest limits: - **Simulated businesses aren't your business.** Real businesses have launches, bad weeks and one customer who pays annually in March. The engine can't foresee a change nobody told it about, which is why you can tell Scenario about launches, holidays and quiet seasons. - **One run is one run.** The GPT-6-Astra result is a single run of 104 forecasts. We'll rerun it, and we'll publish the result either way. - **Better isn't perfect.** Hitting within 5% more than half the time is good for a 30-day revenue forecast. It still means a range matters more than any single number. #### The takeaway If you're forecasting revenue with a chatbot, it will give you a sensible-sounding number. Ask it for a range, ask how it would have done on your last three months, and ask it again tomorrow to see if the answer moves. Those three questions tell you more than the forecast itself. If you'd rather see it done on a real set of numbers, the [live demo](/demo) runs Scenario's forecast on a sample business, no sign-up needed. And if a price rise is the decision on your mind, the [price increase calculator](/saas-price-increase-calculator) is free. --- ### Default alive or default dead? How to check in five minutes https://use-scenario.com/blog/default-alive-or-default-dead · 29 September 2026 Short answer: You're default alive if revenue will overtake costs before the cash runs out, with no new funding. Roll revenue forward at its current growth rate, subtract costs each month from cash, and see which comes first. You're **default alive** if your business will reach profitability before its cash runs out, assuming nothing changes: no new funding, costs carrying on as planned, revenue growing at its current pace. If it won't, you're default dead. The idea comes from Paul Graham's essay [Default Alive or Default Dead?](https://paulgraham.com/aord.html), and it's the most useful five-minute check a founder can do. Here's how to do it. #### Why this question beats "how's it going?" Most founders know their revenue. Fewer know their runway. Very few have put the two together and asked the question that actually decides whether the company survives: do the lines cross in time? Revenue growth feels like progress, and it is. But if costs are growing too, or growth is slowing, a business can add customers every month and still be heading for the wall. Default alive turns a vague feeling into a yes or a no, with a date attached. It also changes what you do next. A default-alive business can take its time: raise money if it wants to, not because it has to. A default-dead one needs to change something now, while there's still room to. #### What you need Four numbers. Rough is fine for a first pass. 1. **Cash in the bank today.** Actual cash, not revenue booked. Leave out money that isn't yours, such as VAT you've collected for HMRC. 2. **Monthly revenue.** What actually came in last month. 3. **Monthly costs.** Everything going out: salaries, contractors, software, rent, your own pay if you take one. 4. **Monthly revenue growth.** The average over the last three to six months. If revenue went from £8,000 to £9,000 over three months, that's about 4% a month. #### The worked example Say you run a small SaaS business. These are hypothetical numbers: - Cash: **£60,000** - Revenue: £8,000 a month - Costs: £13,000 a month - Growth: 4% a month, and costs stay flat Today you're burning £5,000 a month (£13,000 out, £8,000 in). Divide cash by burn and you get 12 months of runway, but that assumes revenue stays flat, which it won't. Instead, roll it forward month by month. Revenue grows 4% each month: £8,000, then £8,320, then about £8,650, and so on. Burn shrinks as revenue catches up. Each month, take the burn away from cash. | Month | Revenue | Burn | Cash left | |---|---|---|---| | 1 | £8,000 | £5,000 | £55,000 | | 4 | £9,000 | £4,000 | £42,000 | | 7 | £10,120 | £2,880 | £32,200 | | 10 | £11,390 | £1,610 | £26,000 | | 12 | £12,320 | £680 | £24,200 | | 13 | £12,810 | £190 | £24,000 | | 14 | £13,320 | none | £24,300 | Revenue passes costs in month 14, with about £24,000 still in the bank. **This business is default alive.** (The figures are rounded; a spreadsheet will give you slightly different pennies.) Now change one thing. Say growth is 2% a month instead of 4%. Revenue only passes £13,000 in month 26, but the cash runs out in month 17. Same business, same costs, half the growth: default dead, with about 16 months to fix it. That's the point of the check. The difference between alive and dead is often one number, and it's rarely the one founders are watching. #### The traps **Counting revenue you haven't collected.** If customers pay on invoice, some of them will pay late and a few won't pay at all. Use cash received, or knock a realistic share off. **Assuming growth holds.** Growth usually slows as a business gets bigger. If your last three months were unusually good, use a more cautious rate for the check. **Forgetting planned costs.** A hire you're about to make, a price rise from a supplier, an annual software bill due in March. Add them in the month they land. **Mixing up profit and cash.** A business can be profitable on paper and short of cash, for example if customers pay annually in advance and you've already spent it. Default alive is a cash question. **Ignoring seasonality.** If your income has a busy and a quiet season (estate agents, for example, often have a slow winter for sales), a straight growth rate will mislead you. Compare with the same month last year. #### What to do with the answer If you're default alive, write down the month you reach profitability and check it again every month. The date moving later is an early warning. If you're default dead, you have three levers, and it's worth modelling each before you pull one: - **Grow revenue faster:** a price rise, better conversion, less churn. The [price increase calculator](/saas-price-increase-calculator) shows how many customers a rise could cost you before it stops paying. - **Cut costs:** usually the fastest lever and the least pleasant. - **Raise money:** which buys time, but only if you can raise it before you need it. Most businesses end up using a mix. The useful question is which mix gets you to "alive" with the most room to spare. #### Checking it on your own numbers The five-minute version above works, but it goes stale the day your numbers change. Scenario's Runway page does this continuously from your Stripe or accounting data: a 24-month cash projection, the default alive or default dead verdict and the month it flips, with planned hires, costs and funding added in. You can see it on a sample business in the [live demo](/demo), no sign-up. #### The takeaway Four numbers, one question: do revenue and costs cross before the cash runs out? Work it out today, write down the date, and check it again next month. If the answer is no, you've found out while there's still time to change it, which is the whole point. --- ### How to raise SaaS prices without losing revenue https://use-scenario.com/blog/how-to-raise-saas-prices · 29 September 2026 Short answer: A price rise pays off as long as the customers it costs you are fewer than r ÷ (1 + r) of your base: about 9% for a 10% rise. Know your normal churn, start with new customers if unsure, and announce it plainly. Most founders who raise SaaS prices worry about the wrong number. They worry about how many customers will complain. The number that matters is how many customers you can lose before the rise stops making you money, and it's usually far more than you'd think. A 10% price rise pays off as long as you lose fewer than about 9% of your customers because of it. Here's the maths, a worked example, and how to do it without a wave of cancellations. #### The break-even rule When you raise prices, two things happen at once. Every customer who stays pays more. Some customers leave who wouldn't have left otherwise. The rise pays off if the first effect is bigger than the second. The break-even point has a simple formula. If you raise prices by a share *r*, you can lose up to *r ÷ (1 + r)* of your customers and still take the same revenue. | Price rise | Customers you can lose and still break even | |---|---| | 5% | 4.8% | | 10% | 9.1% | | 15% | 13.0% | | 20% | 16.7% | | 30% | 23.1% | Anything under those figures and the rise earns you more. Anything over, and you'd have been better off leaving prices alone. #### A worked example Say you run a SaaS product with 200 customers paying £30 a month. That's **£6,000** of monthly recurring revenue (MRR). These numbers are hypothetical. You raise the price 10%, to £33. - To match £6,000 at £33, you need about 182 customers. So you can lose 18 customers to the rise and break even. - If 10 customers leave, you have 190 paying £33: £6,270 a month, **£270 more** than before. - If 25 leave, you have 175 paying £33: £5,775 a month, £225 less. Most price rises for a product people genuinely use land nearer the first case than the second. But "most" isn't "yours", which is why it's worth working out your own break-even before you announce anything. #### Count the right cancellations Only the *extra* cancellations caused by the rise count against it. If you normally lose 4% of customers a month and you lose 6% in the month after the rise, the rise cost you about 2%, not 6%. That means you need to know your normal churn first. Look at the last three to six months: how many customers cancelled each month, as a share of the customers you started the month with. If it jumps around, use the average. And watch the next two or three months, not just the first. Some customers leave when the new price first hits their card, not when you announce it. Annual customers only feel it at renewal. #### Who to raise prices for You don't have to raise everyone's price at once. - **New customers only.** The safest option. Existing customers keep their price (this is called grandfathering), and the new price applies to sign-ups from today. Revenue grows more slowly, but churn barely moves. - **Everyone, with notice.** The fastest option. Give at least 30 days' notice, longer for annual plans, and check your terms say you can. - **Everyone, over time.** Move existing customers to the new price at their next renewal, or after six months. A middle path. If you're nervous, start with new customers. You'll learn whether the new price hurts sign-ups before you touch anyone's existing bill. #### How to announce it Most of the churn from a price rise comes from how it's announced, not the size of it. - **Say it plainly.** "From 1 November, the Pro plan goes from £30 to £33 a month." Put the numbers in the first sentence. - **Say why, briefly and honestly.** What you've shipped this year, what's coming, what it costs to run. One short paragraph. Don't apologise. - **Give a real notice period** and a date. - **Offer a way to lock in the old price,** such as switching to an annual plan before the date. It turns a price rise into a cash boost, and annual customers cancel less. - **Make it easy to ask questions.** A reply-to address that a person reads. Don't bury it in a newsletter, and don't announce it in the same email as an outage apology. #### What stops a price rise working A price rise is a bet that your product is worth more than you charge. It goes wrong in predictable ways: - **Customers who were already on their way out.** A rise gives them a reason to leave now. Check cancellations were steady before the rise, so you don't blame the price for churn that was coming anyway. - **A product people don't use.** If a big share of your customers haven't logged in for a month, fix that first. - **Your biggest customers.** If three customers make up a third of your revenue, talk to them before the announcement, not after. #### Work it out before you announce it The break-even table tells you where the line is. What it doesn't tell you is where *your* customers are likely to land, which depends on your churn, your customer spread and how many of your customers pay annually. The free [SaaS price increase calculator](/saas-price-increase-calculator) works out your break-even and a likely outcome in a minute, no account needed. If you'd rather test it on your real subscriptions, Scenario connects to Stripe read-only and lets you ask "what if I raise prices 10%?" before your customers ever see a new number; you can try it on a sample business in the [live demo](/demo). #### The takeaway Work out your break-even before anything else: a 10% rise pays off as long as it costs you fewer than about 9% of customers. Know your normal churn so you can measure the real effect. Start with new customers if you're unsure, announce it plainly with the numbers up front, and watch cancellations for two or three months, not one.