How to build Plain support dashboards in Metabase

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

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

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

Create a polished Metabase dashboard for Plain 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,
SLA, tenant health, and contact drivers from Plain data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Plain tables and
  models). If durable Plain 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 Plain MCP server: threads, timeline
  entries, customers, and tenants. 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: Threads, Timeline entries (messages/events),
Customers, Tenants (companies), Labels, Thread fields, and SLA status if present.
Inspect the actual tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Plain — it reads a database or CLI-uploaded tables.
- Use medians (p50) and p90 for response times, never averages.
- Plain models companies as tenants — roll metrics up to the tenant where useful.
- Define "first response" as the first outbound message from a human or machine
  user, excluding internal notes.
- If timeline history is missing, do not calculate 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: only build trend cards if there is a
  usable date column or multiple periods have been uploaded.

Dashboard title: Plain Support Overview

Sections:
1. Executive summary (KPI cards): Threads created last 7 days; Resolved last 7
   days; Open backlog; Median time to first response; SLA status; Volume by
   channel.
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
   Volume by channel.
3. Tenant health: Open threads by tenant; Tenants with rising volume; Response
   time by tenant; Top tenants by load.
4. SLA & response time: SLA status breakdown; First response p50/p90 by week;
   Reopened by week (only if history exists).
5. Drivers: Volume by label; Threads by custom field; Feature requests by tenant.

Filters: Tenant, Channel, Label, Assignee, Status, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_plain_threads, modeled_plain_timeline_entries,
modeled_plain_customers, and modeled_plain_tenants.

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', t.created_at) AS day,
  COUNT(*)                                          AS created,
  COUNT(*) FILTER (WHERE t.status = 'done')         AS resolved
FROM threads t
WHERE t.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

Where the support load concentrates across B2B tenants.

SELECT
  tn.name            AS tenant,
  COUNT(*)           AS open_threads
FROM threads t
JOIN tenants tn ON tn.id = t.tenant_id
WHERE t.status <> 'done'
GROUP BY tn.name
ORDER BY open_threads DESC
LIMIT 25;

Median from the first outbound timeline message per thread.

WITH first_outbound AS (
  SELECT
    e.thread_id,
    MIN(e.created_at) AS first_reply_at
  FROM timeline_entries e
  WHERE e.entry_type = 'message'
    AND e.direction = 'outbound'
  GROUP BY e.thread_id
)
SELECT
  date_trunc('week', t.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - t.created_at)) / 60.0
  ) AS median_first_reply_min
FROM threads t
JOIN first_outbound f ON f.thread_id = t.id
GROUP BY 1
ORDER BY 1;

Top contact drivers over the last 90 days.

SELECT
  l.label_type       AS label,
  COUNT(*)           AS threads
FROM threads t
JOIN thread_labels tl ON tl.thread_id = t.id
JOIN labels l ON l.id = tl.label_id
WHERE t.created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY l.label_type
ORDER BY threads DESC
LIMIT 20;