How to build Freshdesk support dashboards in Metabase
Freshdesk is where your team handles customer tickets across email, portal, chat, and phone. 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 Freshdesk 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 Freshdesk to Metabase?
Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Freshdesk connector. So connecting Freshdesk to Metabase means one thing: run a small pipeline that copies Freshdesk 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 Freshdesk data in Metabase?
- Ticket volume — created vs. resolved by day, source, and group
- First response time — how long customers wait for a reply
- Resolution time — created to resolved, with median and p90
- SLA attainment — first-response and resolution targets met
- Backlog and aging — open work and how long it's been waiting
- CSAT — satisfaction surveys and response rate over time
- Agent and group load — workload distribution and resolution speed
Which Freshdesk dashboards should you build in Metabase?
Support overview
The daily pulse of volume and responsiveness.
- Tickets created vs. resolved per day (dual line)
- Median first response time (number + trend)
- Median resolution time (number + trend)
- Open backlog by status (bar)
SLA & response time
Are we keeping our promises?
- SLA attainment % for first response and resolution (number)
- Overdue tickets by group (table)
- Response time p50/p90 by week (line)
- Aging open tickets by days-open bucket (table)
CSAT & quality
Track satisfaction, not just speed.
- CSAT % by week (line)
- Survey response rate (number)
- Reopened tickets by week (line)
- Volume by ticket type and priority (bar)
Agent & group performance
Balance workload and spot coaching opportunities.
- Resolved tickets by agent (bar)
- Median resolution time by group (bar)
- Open assigned tickets by agent (table)
- Volume by source (email, portal, chat) (bar)
How do you build the Freshdesk → Metabase pipeline?
For dashboards that need history and reliability, land Freshdesk data in a database first, then connect Metabase to that database.
Connector options
- dlt (free, code) — write a Python pipeline against the Freshdesk REST API for full control. The lightest path to a maintainable, no-vendor sync.
- Freshdesk REST API (free, raw) — the source of truth; use
include=statsto pull response and resolution timestamps. - Airbyte — has a Freshdesk source covering tickets, conversations, contacts, agents, groups, and satisfaction ratings. Free if you self-host the open-source version; paid on Airbyte Cloud.
- Fivetran (paid, managed) — offers a Freshdesk connector with a maintained schema and incremental syncs.
Notes
- Land raw tables first, then build clean models on top.
- Request ticket
statsso you getfirst_responded_at,resolved_at, andclosed_atwithout recomputing. - Capture ticket activities if you want accurate reopen rate and time-in-status.
Can you generate a Freshdesk dashboard with AI?
Yes — and once Freshdesk 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:
Metabase MCP
- Best for
- Chat clients (Claude, Cursor, Codex)
- Enable
- Admin → AI → MCP
- Endpoint
https://<your-metabase>/api/metabase-mcp- Auth
- OAuth handled by Metabase
Metabase CLI
- Best for
- Terminal agents, scripts, and CI
- Install
npm install -g @metabase/cli- Auth
- Browser OAuth (v62+) or an API key
- Docs
- @metabase/cli
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 statusOn 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 Freshdesk Support Overview dashboard
With MCP or the CLI connected, paste this into your assistant to generate the dashboard:
Create a polished Metabase dashboard for Freshdesk support analytics using the
available Freshdesk tables in this database.
Goal: Help support leaders understand volume, responsiveness, SLA attainment,
CSAT, and agent workload from Freshdesk data.
First, inspect the schema and identify the available Freshdesk tables. Do not
assume exact table names. Map the available raw tables into these analytical
concepts where possible: Tickets, Conversations (replies and notes), Contacts,
Agents, Groups, Companies, Satisfaction surveys, and SLA fields.
Important:
- Build the dashboard from durable database/warehouse tables.
- Use medians (p50) and p90 for response and resolution times, never averages.
- Define "first response" as the first public agent reply, excluding private
notes and automated messages.
- If ticket activity history is missing, do not calculate reopen rate or
time-in-status. Use a caveat instead.
- Do not claim Metabase connects natively to Freshdesk unless that is explicitly
true in this environment.
Dashboard title: Freshdesk Support Overview
Sections:
1. Executive summary (KPI cards): Tickets created last 7 days; Resolved last 7
days; Open backlog; Median first response time; Median resolution time;
CSAT % (only if survey data exists).
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
Volume by source.
3. SLA & response time: First response and resolution SLA attainment; Overdue by
group; Response time p50/p90 by week.
4. CSAT & quality: CSAT by week; Survey response rate; Reopened by week (only if
activities exist); Volume by ticket type and priority.
5. Agent & group: Resolved by agent; Median resolution time by group; Open
assigned by agent; Volume by source.
Filters: Group, Agent, Source, Ticket type, Priority, Status, Date range.
Before finalizing, create or recommend reusable Metabase models:
modeled_freshdesk_tickets, modeled_freshdesk_conversations,
modeled_freshdesk_contacts, modeled_freshdesk_agents, and
modeled_freshdesk_groups.
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 Freshdesk data in Metabase?
Core tables
| Table | Grain | Key columns |
|---|---|---|
tickets | one row per ticket | id, status, priority, source, type, group_id, responder_id, requester_id, created_at, stats_resolved_at |
conversations | one row per reply/note | ticket_id, incoming, private, user_id, created_at |
contacts | one row per requester | id, email, company_id |
agents | one row per agent | id, name, group_ids |
groups | one row per group | id, name |
Modeling advice
- Map Freshdesk's numeric
statuscodes (2 open, 3 pending, 4 resolved, 5 closed) to readable labels in a model. - Use the ticket
statstimestamps for durations rather than recomputing from conversations. - Define first response from the first public, incoming-false conversation and exclude private notes.
- Treat tags as a bridge table so a ticket can carry many tags.
- Define "resolved" once (status 4 or 5) and reuse it everywhere.
Which Freshdesk metrics should you track in Metabase?
| Metric | Definition | Notes |
|---|---|---|
| First response time | Created → first public agent reply. | Report median and p90; exclude private notes. |
| Resolution time | Created → stats_resolved_at. | Decide whether to include pending time. |
| Ticket volume | Created vs. resolved in a period. | Segment by source and group. |
| SLA attainment | Share meeting first-response/resolution targets. | Use SLA fields or modeled targets per group. |
| Backlog | Open/pending tickets right now. | Pair with aging buckets. |
| CSAT | Positive survey responses ÷ rated tickets. | Watch the response rate too. |
What SQL powers Freshdesk dashboards in Metabase?
These assume the modeled tables above (PostgreSQL dialect, with Freshdesk status codes). Adjust identifiers to match your warehouse.
The basic volume trend over the last 30 days (status 4/5 = resolved/closed).
SELECT
date_trunc('day', t.created_at) AS day,
COUNT(*) AS created,
COUNT(*) FILTER (WHERE t.status IN (4, 5)) AS resolved
FROM tickets t
WHERE t.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;Median and p90 from created to the stats resolved timestamp.
SELECT
date_trunc('week', t.created_at) AS week,
percentile_cont(0.5) WITHIN GROUP (
ORDER BY EXTRACT(EPOCH FROM (t.stats_resolved_at - t.created_at)) / 3600.0
) AS median_resolution_hours,
percentile_cont(0.9) WITHIN GROUP (
ORDER BY EXTRACT(EPOCH FROM (t.stats_resolved_at - t.created_at)) / 3600.0
) AS p90_resolution_hours
FROM tickets t
WHERE t.stats_resolved_at IS NOT NULL
GROUP BY 1
ORDER BY 1;Share of resolved tickets that did not escalate first response. Adjust to your SLA fields.
SELECT
g.name AS group_name,
COUNT(*) AS resolved_tickets,
ROUND(
100.0 * COUNT(*) FILTER (WHERE NOT t.fr_escalated) / NULLIF(COUNT(*), 0),
1
) AS first_response_sla_pct
FROM tickets t
JOIN groups g ON g.id = t.group_id
WHERE t.status IN (4, 5)
GROUP BY g.name
ORDER BY resolved_tickets DESC;Open tickets bucketed by how long they've been waiting.
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 (4, 5)
GROUP BY 1
ORDER BY MIN(CURRENT_DATE - t.created_at::date);What are common mistakes when analyzing Freshdesk in Metabase?
stats for response and resolution timestamps.