Are we keeping and growing the revenue we have, and what renews next?
Which features are used, which are ignored, and what broke?
How fast do new accounts reach value, and who is ready to expand?
Who needs attention this week, and did our fixes stick?
Escalations → durable fixes
Running the programme
/ you · median of companies your size · top 25% of them
The SQL behind every chart
Raw exports were cleaned in Python, loaded into SQLite, and every chart is one of these queries. The same clean tables are loaded here in an in-browser SQL engine: edit a query and press Run.
Design notes
Method & datahow the numbers were made and the workbook
The data is synthetic (240 accounts from a seeded generator) but it arrived the way real usage exports arrive — messy — and every number on this page was produced by the pipeline below. The workbook has the raw export, the cleaning log, the SQL, and a reconciliation sheet whose Excel formulas recompute the KPIs from the clean tables.
The four tables after cleaning
Account-month grain, the way a usage warehouse serves it to Metabase or Looker. Every query joins on account_id.
accountsaccount_id, account_name, segment, region, erp_system, licensed_seats, arr_usd, signup_month, card_program_live, six feature flags, status, churn_month, next_renewal_month, seats_imputedaccount_month_usageaccount_id, month, active_submitters, expense_reports, mobile_reports, receipts, ocr_receipts, card_txns, automatch_eligible_txns, auto_matched_txns, card_spend_usd, reimbursed_spend_usd, auto_approved_reports, erp_jobs, erp_failedsupport_ticketsaccount_id, month, category (7 values), ticketscontract_arraccount_id, month, arr_usd, prior_arr_usd, change_type (new / renewal_flat / expansion / contraction / churn)account_healthderived by the health_scores query: score, band, and the four inputs per accountCustomer health score
A 0–100 score, four inputs, weights chosen so usage dominates: a customer who logs in but has no integrations is still a customer; a customer with every feature on and nobody submitting is about to churn.
What I would not trust yet
Things I would flag in the first review before anyone acts on the dashboard.
- Auto-match rate only counts accounts with auto-match switched on. The headline looks good while a third of card accounts never turned it on — the adoption bar tells that story, the rate does not.
- Activation uses licensed seats as the denominator. Customers who over-bought seats look under-activated; I would add a "seats assigned" column before comparing segments.
- Ticket categories are set by Support at triage. The card-feed spike in Feb–Mar was first logged as "policy" for two weeks; category drift is the first thing to check when a line moves.
- Sep 2026 is excluded because the month is not complete. Partial months make every trend look like a cliff.
- Six accounts had no licensed-seat count in the export. I imputed it from their best month (max active ÷ 0.8) and flagged them; their utilisation is an estimate.
What the dashboard is for
A spend-management product needs dashboards for Product, Growth and Leadership; escalations turned into durable improvements; usage data turned into prioritisation; and comfort querying data directly.
- Three audiences, one dataset. Same tables, different questions per tab, so nobody argues about whose number is right.
- Escalation → fix → proof. The Health tab pairs each escalation with the product fix, the process fix, and the before/after ticket count.
- Data → recommendation. Each tab closes with a ranked "what I would do", with the expected size of the prize shown as arithmetic.
- Every number is traceable. every chart links to its query in the Query tab, which runs the same SQL, so an analyst can check my work and Support can reuse it.
Built by Sid Nyati as a portfolio piece. Not affiliated with any company; all figures are generated. The 2026 incidents on the Health tab are illustrative and modelled on the shape of real escalations I have handled in payments platforms.