How to build Kustomer support dashboards in Metabase

Kustomer is a CRM-style support platform that unifies customer conversations from email, chat, social, and voice onto a single timeline. Metabase is where you turn that activity into shared, trustworthy dashboards. This guide covers two complementary paths: a lightweight MCP route for fast, AI-assisted questions, and a durable pipeline route that syncs Kustomer into a database so you can build dashboards anyone can read.

How do you connect Kustomer to Metabase?

Most teams combine these: use the MCP route for customer-360 lookups, and the pipeline route for the dashboards people depend on.

What can you analyze from Kustomer data in Metabase?

• Conversation volume — created vs. done by day and channel
• Time to first response — across all channels
• Queue health — where work waits and backlog by queue
• Backlog and aging — open work and how long it's been waiting
• CSAT — satisfaction by channel and over time
• Repeat contacts — customers writing in repeatedly
• Agent and team load — workload distribution and handle time

Which Kustomer dashboards should you build in Metabase?

How do you use the Kustomer and Metabase MCP servers together?

Pair the Kustomer MCP server with the Metabase MCP server for live, conversational analysis. The Kustomer MCP reads current conversations, customers, and timelines; the Metabase MCP queries the models and dashboards you've already built.

Example workflows

• Pull a customer's full timeline across channels and summarize the history.
• List open conversations by queue from Kustomer and compare against a Metabase model.
• Audit which agents and custom objects (Klasses) are in use.

Be honest about the limits

• MCP is great for live lookups — not for scheduled or audited reporting.
• It does not create history; trend analysis still needs synced data.
• Kustomer's MCP server is read-only and limited to Enterprise/Ultimate plans.
• The Metabase MCP server is built in; an admin enables it under Admin → AI → MCP.

How do you set up the Kustomer and Metabase MCP servers?

{
  "mcpServers": {
    "kustomer": {
      "command": "npx",
      "args": ["-y", "@kustomer/mcp-server"],
      "env": {
        "KUSTOMER_API_KEY": "your-bearer-token"
      }
    },
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Generate a Bearer API key in Kustomer under Settings → Security → API Keys, scoped to the access you want the assistant to have.

Can you generate a Kustomer dashboard with AI?

Yes — and this is the fastest way to a strong first draft. Use the prompt below with the Metabase MCP server and any assistant that can inspect your warehouse schema and create Metabase questions. It assumes Kustomer data is already synced into a database Metabase can read, treats MCP as exploratory, and tells the agent to skip metrics the schema can't support instead of faking them.

Create a polished Metabase dashboard for Kustomer support analytics using the
available Kustomer tables in this database.

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

First, inspect the schema and identify the available Kustomer tables. 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.

Important:
- Treat MCP data access as exploratory only.
- Build the dashboard from durable database/warehouse 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.
- Do not claim Metabase connects natively to Kustomer unless that is explicitly
  true in this environment.

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.

Before finalizing, create or recommend reusable Metabase 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 schema. Keep it practical, dense,
and executive-readable. Avoid vanity metrics.

How do you sync Kustomer data into a database or warehouse?

For dashboards that need history and reliability, land Kustomer data in a database first, then connect Metabase to that database.

Connector options

• dlt(code) — write a Python pipeline against the Kustomer REST API; the most reliable route since there's no first-party managed connector.
• Kustomer REST API(raw) — the source of truth; paginate conversations, messages, customers, and use search exports for bulk history.
• Managed ETL (verify) — check whether your ETL vendor offers a Kustomer connector; availability varies, so confirm before relying on it.

Notes

• Land raw tables first, then build clean models on top.
• Kustomer is event/timeline-driven — sync messages (not just conversations) to compute response times.
• Custom objects (Klasses) may hold satisfaction or business data; map them explicitly.

How should you model Kustomer data in Metabase?

Core tables

Modeling advice

• Define first response from the first outbound, non-note message in a conversation.
• Normalize status (open/snoozed/done) and channel so charts stay stable.
• Roll the timeline up to a conversation grain for most dashboards; keep messages for response-time math.
• Treat tags as a bridge table so a conversation can carry many tags.
• Define "done" once and reuse it everywhere.

Which Kustomer metrics should you track in Metabase?

What SQL powers Kustomer dashboards in Metabase?

These assume the modeled tables above (PostgreSQL dialect). Adjust identifiers to match your warehouse.

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;

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;

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;

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;

What are common mistakes when analyzing Kustomer in Metabase?

Related

Related analytics

Related integrations

FAQ