How to build Pylon support dashboards in Metabase

{
  "mcpServers": {
    "pylon": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.usepylon.com"]
    }
  }
}

# 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 Pylon CSV export — creates a table AND a model
mb upload csv --file pylon-issues.csv --collection root

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

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

Goal: Help support and customer success leaders understand volume, responsiveness,
account health, and contact drivers from Pylon data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Pylon tables and
  models). If durable Pylon data is already present — synced from a warehouse or
  uploaded earlier — use it and skip to Step 2.
- If nothing is there, pull it with the Pylon MCP server (keep the connection
  read-only): issues, accounts, contacts, and users. 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 names. Map the available raw tables into these
analytical concepts where possible: Issues, Accounts, Contacts, Users (team
members), Channels, Tags, and custom fields. Inspect the actual tables and column
names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Pylon — it reads a database or CLI-uploaded tables.
- Use medians (p50) and p90 for response times, never averages.
- B2B support is account-shaped — roll metrics up to the account where useful.
- If issue state history is missing, do not calculate reopen rate or
  time-in-status. Use a caveat instead.
- Only build a card if its underlying column/metric exists in the data.
- A single CSV is a point-in-time snapshot: reopen rate and time-in-status need
  history, so build trend cards only if a warehouse sync or multiple uploads
  provide it.

Dashboard title: Pylon Support Overview

Sections:
1. Executive summary (KPI cards): Issues created last 7 days; Resolved last 7
   days; Open backlog; Median time to first response; Accounts with open
   escalations; Volume by channel.
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
   Volume by channel.
3. Account health: Open issues by account; Accounts with rising volume; Top
   accounts by load; Escalations by account.
4. Response time: First response p50/p90 by week; Response time by account tier;
   Reopened by week (only if history exists).
5. Drivers: Volume by tag; Feature requests by account; Top contact drivers.

Filters: Account, Channel, Tag, Assignee, Status, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_pylon_issues, modeled_pylon_accounts,
modeled_pylon_contacts, and modeled_pylon_users.

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. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

The basic volume trend over the last 30 days.

SELECT
  date_trunc('day', i.created_at) AS day,
  COUNT(*)                                        AS created,
  COUNT(*) FILTER (WHERE i.state = 'closed')      AS resolved
FROM issues i
WHERE i.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

Where the support load concentrates across B2B accounts.

SELECT
  a.name             AS account,
  COUNT(*)           AS open_issues
FROM issues i
JOIN accounts a ON a.id = i.account_id
WHERE i.state <> 'closed'
GROUP BY a.name
ORDER BY open_issues DESC
LIMIT 25;

Median from the issue's first-response timestamp.

SELECT
  date_trunc('week', i.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (i.first_response_at - i.created_at)) / 60.0
  ) AS median_first_reply_min
FROM issues i
WHERE i.first_response_at IS NOT NULL
GROUP BY 1
ORDER BY 1;

Slack vs. Teams vs. email over the last 30 days.

SELECT
  i.channel,
  COUNT(*)           AS issues
FROM issues i
WHERE i.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY i.channel
ORDER BY issues DESC;