# Pricepilot backtest — Sun 15 Nov 2026

**Verdict:** At graduated tiers per api call your MRR goes from £4,240 to £3,715 (-12.4%). 0 customers neutral, 6 falling, 2 rising (biggest: Otter Analytics +27%).

New model: graduated tiers per api call. Currency: GBP (symbol only, no conversion). Metric: api calls.

## Per-customer bills (sorted by change % desc)

| Customer | Seats | api calls | Old | New | Change | % | Band | Capped yr-1 | Per seat | Per api call |
|---|---|---|---|---|---|---|---|---|---|---|
| Otter Analytics | 18 | 47000 | £720.00 | £916.00 | £196.00 | +27.2% | rising | £864.00 | £50.89 | £0.019489 |
| Finch Payments | 30 | 82000 | £1,200.00 | £1,354.00 | £154.00 | +12.8% | rising | £1,354.00 | £45.13 | £0.016512 |
| Heron Health API | 12 | 18300 | £480.00 | £399.40 | -£80.60 | -16.8% | falling | £399.40 | £33.28 | £0.021825 |
| Velvet Commerce | 22 | 29500 | £880.00 | £601.00 | -£279.00 | -31.7% | falling | £601.00 | £27.32 | £0.020373 |
| Sorrel Search | 9 | 9600 | £360.00 | £240.00 | -£120.00 | -33.3% | falling | £240.00 | £26.67 | £0.025 |
| Tansy Tracking | 7 | 5200 | £280.00 | £130.00 | -£150.00 | -53.6% | falling | £130.00 | £18.57 | £0.025 |
| Umber Utilities | 5 | 2100 | £200.00 | £52.50 | -£147.50 | -73.8% | falling | £52.50 | £10.50 | £0.025 |
| Wren Weather | 3 | 900 | £120.00 | £22.50 | -£97.50 | -81.3% | falling | £22.50 | £7.50 | £0.025 |

## Totals

- Old MRR £4,240.00 (ARR £50,880.00) → new MRR £3,715.40 (ARR £44,584.80), -12.4%
- Bands: 0 neutral, 6 falling, 2 rising (band and wave timings are labelled heuristics)
- Revenue at risk (rises on rising accounts): £350.00/month
- Cost of first-year cap: £52.00/month (£624.00/year); capped MRR £3,663.40
- Falling accounts: £1,445.40/month new revenue, down £874.60/month
- Concentration: top before Finch Payments 28.3%; top after Finch Payments 36.4%

## Migration plan (suggested)

- Wave 1 — neutral (suggested) — Mon 1 Feb 2027: 0 customers. Bills barely change; safest first. Fix every invoice question here before wave 2.
- Wave 2 — falling (suggested) — Mon 1 Mar 2027: 6 customers. These customers pay less. Confirm the revenue drop is the one in the backtest, not larger.
- Wave 3 — rising (suggested) — Thu 1 Apr 2027: 2 customers. Most reason to leave: give at least one full renewal cycle of notice and the first-year 20% increase cap shown in the table.

## Next steps

1. Sun 15 Nov 2026 — Agree the price from this backtest. Check the rising accounts by name; adjust rate, fee or included actions until the riser list is one you can defend.
2. Sun 15 Nov 2026 — Create the Stripe prices in test mode. Use the exported Price JSON as a starting point; replace prod_REPLACE and mtr_REPLACE, then test in Stripe test mode.
3. Tue 1 Dec 2026 — Send shadow invoice 1 and announce. Show each customer their new-model invoice alongside the real (old-price) invoice. Send the notice draft.
4. Fri 1 Jan 2027 — Send shadow invoice 2. Second shadow month; answer questions, confirm the cap for rising accounts in writing.
5. Mon 1 Feb 2027 — Cut over wave 1 (neutral). Move neutral customers to the new Stripe prices.
6. Mon 1 Mar 2027 — Cut over wave 2 (falling). Move falling customers; watch revenue against this backtest.
7. Thu 1 Apr 2027 — Cut over wave 3 (rising, capped). Move rising customers with the first-year 20% cap applied.

## Stripe set-up (starting point — test in Stripe test mode)

### Input price

```json
{
  "note": "Starting point — test in Stripe test mode. Replace prod_REPLACE with your Product ID and mtr_REPLACE with your meter ID.",
  "endpoint": "POST https://api.stripe.com/v1/prices",
  "prices": [
    {
      "nickname": "Tiered per action (graduated, metered)",
      "product": "prod_REPLACE",
      "currency": "gbp",
      "billing_scheme": "tiered",
      "tiers_mode": "graduated",
      "tiers": [
        {
          "up_to": 10000,
          "unit_amount_decimal": "2.5"
        },
        {
          "up_to": 50000,
          "unit_amount_decimal": "1.8"
        },
        {
          "up_to": "inf",
          "unit_amount_decimal": "1.2"
        }
      ],
      "recurring": {
        "interval": "month",
        "usage_type": "metered",
        "meter": "mtr_REPLACE"
      }
    }
  ]
}
```

## Customer notice draft

Subject: A change to how we charge — your projected bill is inside

Hi {customer} team,

I'm writing to tell you about a change to our pricing, and to show you exactly what it means for your bill before anything changes.

Today you pay per seat. From {cutover_date} we will charge based on api calls instead: graduated tiers per api call. We are making this change because teams are getting more done with fewer seats, and we think price should track the value you use, not headcount.

Your projected monthly bill on the new pricing (based on your recent usage): {new_bill} — you currently pay {old_bill}. {cap_line}

For the next two months you will see a "shadow" version of your invoice on the new pricing alongside your normal invoice, so there are no surprises. Nothing about your access changes, and you do not need to do anything.

If the projected number looks wrong, or you want to talk through your usage, reply to this email and I will look at your account personally.

Thank you for being a customer.

---
Fill in before sending (do not send this section):
- {cutover_date}: use the date for this customer's wave — neutral customers: Mon 1 Feb 2027; falling customers: Mon 1 Mar 2027; rising customers: Thu 1 Apr 2027 with the first-year cap.
- {cap_line}: rising customers only — replace it with "For the first year, your bill will not rise by more than 20% above what you pay today, whatever your usage does." For neutral and falling customers, delete {cap_line} (their bill is not rising, so do not promise them a cap).

## Internal summary

Backtest: 8 customers move from £4,240.00/month to £3,715.40/month (-12.4%); 2 rising accounts put £350.00/month of increases at risk, a first-year 20% increase cap costs £52.00/month (£624.00/year), and the top customer is Finch Payments at 36.4% of new MRR.

## Sources

- [Stripe — Set up tiered pricing (volume)](https://docs.stripe.com/subscriptions/pricing-models/tiered-pricing) (stripe): "With volume-based pricing, the subscription item bills at the tier corresponding to the amount of usage at the end of the period."
- [Stripe — Set up tiered pricing (graduated)](https://docs.stripe.com/subscriptions/pricing-models/tiered-pricing) (stripe): "Graduated pricing charges for the usage in each tier instead of applying a single price for overall usage."
- [Stripe — Add a flat rate (flat_amount)](https://docs.stripe.com/subscriptions/pricing-models/tiered-pricing) (stripe): "If `quantity` is `12` and `tiers_mode=volume`, the total amount billed is: 12 × 3 USD + 30 USD = 66 USD"
- [Stripe API — Create a price (tiers.up_to)](https://docs.stripe.com/api/prices/create) (stripe): "Specifies the upper bound of this tier. The lower bound of a tier is the upper bound of the previous tier adding one. Use `inf` to define a fallback tier."
- [Stripe API — Create a price (unit_amount_decimal)](https://docs.stripe.com/api/prices/create) (stripe): "Same as `unit_amount`, but accepts a decimal value in the smallest currency unit with at most 12 decimal places."
- [Stripe — Design a subscriptions integration (fixed fee and overage)](https://docs.stripe.com/billing/subscriptions/design-an-integration) (stripe): "Fixed fee and overage pricing: You charge 100 USD per month for usage of up to 100 tokens. If a customer uses more than 100 tokens in a month (overage), you also charge 2 USD for each token used beyond the initial 100."
- [Heuristic (third-party) — ±10% band](https://www.revenuebestpractices.com/p/migrate-seat-to-usage-pricing) (heuristic-third-party): "Rising. The usage bill is more than 10% above the seat bill. Neutral. The usage bill is within 10% either way."
- [Heuristic (third-party) — wave order neutral, falling, rising](https://www.revenuebestpractices.com/p/migrate-seat-to-usage-pricing) (heuristic-third-party): "Sequence the waves by risk, not by size or renewal date alone."
- [Heuristic (third-party) — shadow invoices](https://orvlin.com/blog/migrate-to-usage-based-pricing) (heuristic-third-party): "Generate shadow invoices on the new model alongside real invoices for one or two cycles"

Pricepilot · Daily Ships · Planning aid, not financial advice. Billing maths follows Stripe's published tiered, per-seat and usage-based examples (checked 15 Nov 2026); bands, caps and wave timings are labelled heuristics.