← Back to skumetrica.com

Reference

Billing

What this account actually pays, why the price is what it is, and how close its own order volume sits to the next tier — measured from the account's own orders, the same way the rest of the dashboard counts them, rather than anything metered separately.

+ Claude

The monthly price for this plan with Claude's Conclusions included — the written analysis on top of the dashboard, rather than the dashboard alone.

Good: Compare against Dashboard beside it in the same row — the gap between the two columns is what Claude's Conclusions itself costs on top of that tier.

From: Billing::PLANS[key]['brief'] in src/Billing.php, the price charged whenever the brief is switched on.

Dashboard

The monthly price for this plan without Claude's Conclusions — every screen, every marketplace, every export and the full order history, just with nobody reading it for you.

Good: Compare against the + Claude column beside it for what the difference actually buys.

From: Billing::PLANS[key]['base'] in src/Billing.php.

Monthly

What this account is actually being charged a month, for the plan and the + Claude setting it currently has.

Good: Not a figure to judge against anything — read the note beneath it for what it depends on: whether the account is still on its trial, and when the next charge or the next tier change lands.

From: Billing::monthlyPrice($plan, $brief) in src/Billing.php: the account's own base or brief price.

Orders a month

The ceiling built into each plan — how many distinct orders a month it covers before a heavier tier is needed.

Good: Not a target to hit — a limit. Selling more than a plan's ceiling never restricts anything on the dashboard; it only moves the account towards the next tier, and only after the notice period the page describes further up, never mid-month.

From: Billing::PLANS[key]['orders'] in src/Billing.php.

Orders, last 30 days

How many distinct orders this account placed in its own last complete 30-day window, cancellations excluded — the same count the tier itself is decided from.

Good: Read against the note beneath it, the plan's own ceiling, and the meter bar for how close that is. Going over does not restrict anything — see the note further down the page about how a tier change is announced before it is ever applied.

From: Billing::volume() by way of Billing::evaluate() in src/Billing.php: COUNT(DISTINCT amazon_order_id), cancellations excluded, over Billing::window() — the account's own local 30 days, not the calendar's.

Plan

The name of the subscription tier this account is on, in the KPI tile, or being offered, in the table further down the page.

Good: Not a figure — the KPI tile also carries the + Claude mark once that is switched on, and the tier table marks the current row and any row a pending change is heading towards.

From: tenant_billing.plan via Billing::row() in src/Billing.php, matched against Billing::PLANS.

Status

What the account may actually do right now — trial, active, payment late, paused, or not billed at all — rather than the raw status Stripe stores, which can go on saying something that has since gone stale.

Good: Anything other than "payment late" or "paused" needs no action. "payment late" is not yet a lockout — Stripe is still retrying, and the note beneath it says so; "paused" is, and the banner at the top of the page takes over until a plan is chosen.

From: Billing::access() in src/Billing.php, which derives the state from the stored status, the trial end date and the period end, rather than reading status directly.

← Back to the course map