How to build Zendesk support dashboards in Metabase

Zendesk is where your team handles customer tickets across email, chat, and the web. Metabase is where you turn that activity into shared, trustworthy dashboards. Because Metabase reads from SQL databases, the reliable way to connect them is a small pipeline: sync Zendesk into a database or warehouse on a schedule, then point Metabase at it. This guide walks through that path end to end — including a free option with no paid connector.

How do you connect Zendesk to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Zendesk connector. So connecting Zendesk to Metabase means one thing: run a small pipeline that copies Zendesk data into a database on a schedule, then connect Metabase to that database. Once the data lands, the models, metrics, and SQL later in this guide all work.

The good news: this doesn't require a paid tool. Use a managed connector if you want zero maintenance, or a free, code-based sync you host yourself — both are covered in Build the pipeline below, and in more depth in our guide to building a data pipeline.

What can you analyze from Zendesk data in Metabase?

• Ticket volume — created vs. solved by day, channel, and group
• First-response time — how long customers wait for a first reply
• Resolution time — created to solved, with median and p90
• SLA attainment — share of tickets meeting policy targets
• Backlog and aging — open work and how long it's been waiting
• CSAT — satisfaction ratings and response rate over time
• Reopen rate — solved tickets reopened (needs ticket audits)
• Agent and group load — workload distribution and handle time

Which Zendesk dashboards should you build in Metabase?

How do you build the Zendesk → Metabase pipeline?

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

Connector options

• dlt (free, code) — write a Python pipeline against the Zendesk REST API for full control of streams and schema. The lightest path to a maintainable, no-vendor sync.
• Zendesk REST API (free, raw) — the source of truth; use Incremental Exports to capture ticket and audit history.
• Airbyte — has a Zendesk Support source covering tickets, comments, users, organizations, satisfaction ratings, and more. Free if you self-host the open-source version; paid on Airbyte Cloud.
• Fivetran (paid, managed) — offers a Zendesk Support connector with a maintained schema and incremental syncs.

Notes

• Land raw tables first, then build clean models on top.
• Sync the ticket_metrics object — it carries pre-computed reply and resolution durations.
• Capture ticket audits/events if you want accurate reopen rate and time-in-status; snapshots lose transitions.

Can you generate a Zendesk dashboard with AI?

Yes — and once Zendesk data is synced into a database, this is the fastest way to a strong first draft. First give an AI assistant a way to read your Metabase schema and create questions and dashboards, then paste the prompt below. It builds the dashboard from your database tables and tells the agent to skip metrics the schema can't support instead of faking them.

Two ways to let an assistant query and build in Metabase

Both connect to a Metabase instance that's already pointed at your synced database — the pipeline above moves the data; these just let the assistant read and write Metabase. Pick whichever fits your setup:

Set up the Metabase MCP server

Enable it under Admin → AI → MCP, then point your client at the endpoint:

# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp

{
  "mcpServers": {
    "metabase": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://your-metabase.example.com/api/metabase-mcp"]
    }
  }
}

Clients with native remote support can use a "url" field instead of the mcp-remote bridge. Confirm the current endpoint in the Metabase MCP docs.

Set up the Metabase CLI

Install it globally, then authenticate once (the binary is mb):

# Install the CLI (the binary is `mb`)
npm install -g @metabase/cli

# Authenticate once — opens your browser on Metabase v62+, or use an API key
mb auth login --url https://your-metabase.example.com
mb auth status

On Metabase v62+ mb auth login opens your browser; older servers fall back to an API key. A terminal-based assistant can then inspect your schema (mb db schemas, mb table get --include fields) and create content (mb card create, mb dashboard create) against the synced tables.

Prompt: build the Zendesk Support Overview dashboard

With MCP or the CLI connected, paste this into your assistant to generate the dashboard:

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

Goal: Help support leaders understand volume, responsiveness, SLA attainment,
CSAT, and agent workload from Zendesk data.

First, inspect the schema and identify the available Zendesk tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Tickets, Ticket comments/audits, Ticket metrics, Users (agents and
end users), Organizations, Groups, Tags, Satisfaction ratings, and SLA policies.

Important:
- Build the dashboard from durable database/warehouse tables.
- Use medians (p50) and p90 for reply and resolution times, never averages.
- Define "first reply" as the first public agent comment, excluding automated
  messages and internal notes.
- If ticket audit/status history is missing, do not calculate reopen rate or
  time-in-status. Use a caveat instead.
- Do not claim Metabase connects natively to Zendesk unless that is explicitly
  true in this environment.

Dashboard title: Zendesk Support Overview

Sections:
1. Executive summary (KPI cards): Tickets created last 7 days; Tickets solved
   last 7 days; Open backlog; Median first reply time; Median full resolution
   time; CSAT % (only if satisfaction ratings exist).
2. Volume & backlog: Created vs solved by day; Open tickets by status; Backlog
   aging by days-open bucket; Volume by channel.
3. SLA & response time: SLA attainment by policy (only if SLA fields exist);
   Breached tickets by reason; Reply time p50/p90 by week.
4. CSAT & quality: CSAT by week; Rating response rate; Bad ratings by tag;
   Reopen rate (only if audits exist).
5. Agent & team: Solved by agent; Median handle time by group; Open assigned by
   agent; Volume by group.

Filters: Group, Assignee, Channel, Tag, Priority, Status, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_zendesk_tickets, modeled_zendesk_comments, modeled_zendesk_users,
modeled_zendesk_organizations, modeled_zendesk_satisfaction, and
modeled_zendesk_sla (only if SLA data exists).

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 should you model Zendesk data in Metabase?

Core tables

Modeling advice

• Normalize status into a small set (new/open/pending/solved/closed) so charts stay stable.
• Prefer ticket_metrics for durations rather than recomputing from comments — Zendesk already accounts for business hours and pending time.
• Filter ticket_comments to public = true and exclude automated authors to define "first reply."
• Treat tags as a bridge table so a ticket can carry many tags.
• Define "solved" once and reuse it everywhere to avoid metric drift.

Which Zendesk metrics should you track in Metabase?

What SQL powers Zendesk dashboards in Metabase?

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

SELECT
  date_trunc('day', t.created_at) AS day,
  COUNT(*)                                          AS created,
  COUNT(*) FILTER (WHERE t.status IN ('solved', 'closed')) AS solved
FROM tickets t
WHERE t.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', t.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY m.reply_time_in_minutes
  ) AS median_first_reply_min,
  percentile_cont(0.9) WITHIN GROUP (
    ORDER BY m.reply_time_in_minutes
  ) AS p90_first_reply_min
FROM tickets t
JOIN ticket_metrics m ON m.ticket_id = t.id
WHERE m.reply_time_in_minutes IS NOT NULL
GROUP BY 1
ORDER BY 1;

SELECT
  date_trunc('week', s.created_at) AS week,
  COUNT(*) FILTER (WHERE s.score = 'good') AS good,
  COUNT(*) FILTER (WHERE s.score IN ('good', 'bad')) AS rated,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE s.score = 'good')
      / NULLIF(COUNT(*) FILTER (WHERE s.score IN ('good', 'bad')), 0),
    1
  ) AS csat_pct
FROM satisfaction_ratings s
GROUP BY 1
ORDER BY 1;

SELECT
  CASE
    WHEN CURRENT_DATE - t.created_at::date <= 1  THEN '0-1 days'
    WHEN CURRENT_DATE - t.created_at::date <= 3  THEN '2-3 days'
    WHEN CURRENT_DATE - t.created_at::date <= 7  THEN '4-7 days'
    ELSE '8+ days'
  END                AS age_bucket,
  COUNT(*)           AS open_tickets
FROM tickets t
WHERE t.status NOT IN ('solved', 'closed')
GROUP BY 1
ORDER BY MIN(CURRENT_DATE - t.created_at::date);

What are common mistakes when analyzing Zendesk in Metabase?

Related

Related analytics

Related integrations

FAQ