How to build Kustomer support dashboards in Metabase

{
  "mcpServers": {
    "kustomer": {
      "command": "npx",
      "args": ["-y", "@kustomer/mcp-server"],
      "env": {
        "KUSTOMER_API_KEY": "your-bearer-token"
      }
    }
  }
}

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

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

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

Goal: Help support leaders understand omnichannel volume, responsiveness, CSAT,
queue health, and agent workload from Kustomer data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for Kustomer tables and
  models). If durable Kustomer 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 read-only Kustomer MCP server:
  conversations, messages, customers, users (agents), queues, and satisfaction /
  custom objects (Klasses). 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: Conversations, Messages, Customers,
Companies, Users (agents), Teams, Queues, and Satisfaction / custom objects
(Klasses) if present. Inspect the actual tables and column names first.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Kustomer — it reads a database or CLI-uploaded tables.
- Use medians (p50) and p90 for response times, never averages.
- Define "first response" as the first outbound agent message, excluding internal
  notes and automated messages.
- Kustomer is timeline/event-driven; if message-level history is missing, do not
  calculate response time. 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: Kustomer Support Overview

Sections:
1. Executive summary (KPI cards): Conversations created last 7 days; Done last 7
   days; Open backlog; Median time to first response; CSAT % (only if satisfaction
   data exists); Volume by channel.
2. Volume & backlog: Created vs done by day; Open by status; Backlog aging;
   Volume by channel.
3. Queues & response time: First response p50/p90 by week; Open by queue; Reopened
   by week (only if history exists).
4. CSAT & quality: CSAT by week; Satisfaction by channel; Volume by tag; Repeat
   contacts.
5. Agent & team: Done by agent; Median handle time by team; Open assigned by agent;
   Volume by queue.

Filters: Channel, Queue, Team, Agent, Tag, Status, Date range.

Reuse the models Metabase auto-created from uploaded CSVs, or (for a warehouse)
create reusable models: modeled_kustomer_conversations, modeled_kustomer_messages,
modeled_kustomer_customers, modeled_kustomer_users, and modeled_kustomer_queues.

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

Median from the first outbound message per conversation.

WITH first_outbound AS (
  SELECT
    m.conversation_id,
    MIN(m.created_at) AS first_reply_at
  FROM messages m
  WHERE m.direction = 'out'
    AND m.is_note = false
  GROUP BY m.conversation_id
)
SELECT
  date_trunc('week', c.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - c.created_at)) / 60.0
  ) AS median_first_reply_min
FROM conversations c
JOIN first_outbound f ON f.conversation_id = c.id
GROUP BY 1
ORDER BY 1;

Where open conversations are piling up right now.

SELECT
  q.name             AS queue,
  COUNT(*)           AS open_conversations
FROM conversations c
JOIN queues q ON q.id = c.queue_id
WHERE c.status <> 'done'
GROUP BY q.name
ORDER BY open_conversations DESC;

Omnichannel mix over the last 30 days.

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