How to build Vitally customer success dashboards in Metabase

# No vendor MCP server exists. Export directly from the REST API:
curl -s "https://$SUBDOMAIN.rest.vitally.io/resources/accounts?limit=100" \
  -u "$VITALLY_API_KEY:" \
  | jq -r '.results[] | [.id, .name, .mrr, .createdAt,
      (.traits.segment // "")] | @csv' \
  > vitally-accounts.csv

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a accounts export — creates a table AND a model
mb upload csv --file vitally-accounts.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file vitally-accounts.csv

Create a polished Metabase dashboard for Vitally customer success analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help customer success and revenue leaders understand health score distribution, the accounts moving most, NPS by segment, and CSM workload from Vitally data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for vitally tables and
  models). If durable Vitally data is already present — a warehouse sync or
  an earlier upload — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export by scripting the Vitally REST API:
  accounts and their health scores, plus users, conversations and notes, tasks and playbooks.
  Prefer one row per account per snapshot date over raw activity
  feeds. Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available fields, owners,
segments, statuses, and date ranges before creating trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Vitally — it reads a database or CLI-uploaded tables.
- State which health score a card uses and when it was captured. Vendor scores
  are opaque composites and get redefined without notice.
- A single CSV is a point-in-time snapshot: health scores, phases, and renewal
  dates are current-state fields, so only build trend cards once several dated
  snapshots exist.
- Reconcile ARR against billing data, not against the Vitally record — CS
  platforms hold a projection of CRM, billing, and product data.
- Only compute retention where subscription or license values exist. Gross
  revenue retention excludes expansion and can never exceed 100%; net revenue
  retention includes it and can.

Dashboard title: Vitally Customer Success Overview

Sections:
1. Executive summary: Accounts by risk tier; MRR at risk; Median health
   score; NPS; Accounts with no conversation in 30 days.
2. Health: Risk tier distribution; MRR by tier; median score by segment.
3. Movers: Biggest gains and drops; accounts crossing into at risk.
4. Voice of the customer: NPS by segment; NPS trend; response rate.
5. Workload: Accounts and MRR per CSM; open tasks by age; completion rate.

Filters: Date range, CSM owner, Segment, Risk tier, Lifecycle stage.

Output: Build the dashboard if you have permission; otherwise provide the exact
questions, SQL, model definitions, and layout. Include caveats for any metric
that cannot be calculated from the available data.

One named score, bucketed, with annualized MRR per tier.

WITH latest AS (
  SELECT DISTINCT ON (account_id)
    account_id,
    score_value
  FROM account_health_scores
  WHERE score_name = 'Overall Health'
  ORDER BY account_id, snapshot_date DESC
)
SELECT
  CASE
    WHEN l.score_value >= 80 THEN 'healthy'
    WHEN l.score_value >= 60 THEN 'watch'
    ELSE 'at risk'
  END AS risk_tier,
  COUNT(*) AS accounts,
  ROUND(SUM(a.mrr) * 12, 0) AS annualized_mrr
FROM latest l
JOIN cs_accounts a ON a.account_id = l.account_id
WHERE a.churned_at IS NULL
GROUP BY 1
ORDER BY MIN(l.score_value);

Month-end values compared, ranked by absolute change.

WITH month_end AS (
  SELECT DISTINCT ON (account_id, date_trunc('month', snapshot_date))
    account_id,
    date_trunc('month', snapshot_date) AS month,
    score_value
  FROM account_health_scores
  WHERE score_name = 'Overall Health'
  ORDER BY account_id, 2, snapshot_date DESC
),
movement AS (
  SELECT
    account_id,
    month,
    score_value,
    LAG(score_value) OVER (PARTITION BY account_id ORDER BY month)
      AS prior_value
  FROM month_end
)
SELECT
  a.name,
  a.csm_owner,
  a.mrr,
  mv.prior_value,
  mv.score_value AS current_value,
  ROUND((mv.score_value - mv.prior_value)::numeric, 1) AS score_change
FROM movement mv
JOIN cs_accounts a ON a.account_id = mv.account_id
WHERE mv.month = date_trunc('month', CURRENT_DATE)
  AND mv.prior_value IS NOT NULL
  AND a.churned_at IS NULL
ORDER BY ABS(mv.score_value - mv.prior_value) DESC
LIMIT 25;

The reality check: does the score match what accounts actually do?

WITH latest AS (
  SELECT DISTINCT ON (account_id)
    account_id,
    score_value
  FROM account_health_scores
  WHERE score_name = 'Overall Health'
  ORDER BY account_id, snapshot_date DESC
),
usage AS (
  SELECT
    account_id,
    COUNT(*) FILTER (WHERE active_users > 0) AS active_days_30d,
    AVG(active_users) AS avg_daily_active_users
  FROM product_usage_daily
  WHERE usage_date >= CURRENT_DATE - INTERVAL '30 days'
  GROUP BY account_id
)
SELECT
  CASE
    WHEN l.score_value >= 80 THEN 'healthy'
    WHEN l.score_value >= 60 THEN 'watch'
    ELSE 'at risk'
  END AS risk_tier,
  COUNT(*) AS accounts,
  ROUND(AVG(COALESCE(u.active_days_30d, 0))::numeric, 1) AS avg_active_days_30d,
  ROUND(AVG(COALESCE(u.avg_daily_active_users, 0))::numeric, 1) AS avg_dau
FROM latest l
JOIN cs_accounts a ON a.account_id = l.account_id
LEFT JOIN usage u ON u.account_id = l.account_id
WHERE a.churned_at IS NULL
GROUP BY 1
ORDER BY MIN(l.score_value);