How to build LiveAgent support dashboards in Metabase
LiveAgent is a multi-channel help desk that brings email, live chat, calls, and social messages into one ticketing system. 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 LiveAgent 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 LiveAgent to Metabase?
Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native LiveAgent connector. So connecting LiveAgent to Metabase means one thing: run a small pipeline that copies LiveAgent 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 LiveAgent data in Metabase?
- Ticket volume — created vs. resolved by day and channel
- First response time — how long customers wait for a reply
- Channel mix — email vs. chat vs. call vs. social
- Department health — backlog and load by department
- Backlog and aging — open work and how long it's been waiting
- Agent performance — workload distribution and handle time
- Repeat contacts — customers writing in repeatedly
Which LiveAgent dashboards should you build in Metabase?
Support overview
The daily pulse across channels.
- Tickets created vs. resolved per day (dual line)
- Median first response time (number + trend)
- Open backlog by status (bar)
- Volume by channel (email, chat, call, social) (bar)
Response time & SLA
Are we replying within target?
- First response time p50/p90 by week (line)
- Open tickets by department (bar)
- Aging open tickets by days-open bucket (table)
- Reopened tickets by week (line)
Agent performance
Balance workload across the team.
- Resolved tickets by agent (bar)
- Median handle time by agent (bar)
- Open assigned tickets by agent (table)
- Calls handled by agent (bar)
Channels & drivers
Understand what's driving contacts.
- Volume by channel over time (line)
- Volume by tag/topic (bar)
- Volume by hour of day (bar)
- Repeat-contact customers (table)
How do you build the LiveAgent → Metabase pipeline?
Every pipeline is the same four stages: extract from LiveAgent's API, load into a database, model the raw tables into clean ones, and visualize in Metabase. You can assemble this with a managed connector or a free script you host yourself.
Connector options
- dlt (free, code) — write a Python pipeline against the LiveAgent REST API (v3); the most reliable route since there's no first-party managed connector.
- LiveAgent REST API (v3) (free, raw) — the source of truth; paginate tickets, messages, agents, and departments and upsert on a schedule.
- Managed ETL (paid, managed) — check whether your ETL vendor offers a LiveAgent connector; availability varies, so confirm before relying on it.
Notes
- Land raw tables first, then build clean models on top.
- Sync messages so you can compute response times and channel mix accurately.
- Capture ticket events if you want accurate reopen rate and time-in-status.
Can you generate a LiveAgent dashboard with AI?
Yes — and once LiveAgent 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 LiveAgent Support Overview dashboard
With MCP or the CLI connected, paste this into your assistant to generate the dashboard:
Create a polished Metabase dashboard for LiveAgent support analytics using the
available LiveAgent tables in this database.
Goal: Help support leaders understand multi-channel volume, responsiveness,
department health, and agent workload from LiveAgent data.
First, inspect the schema and identify the available LiveAgent tables. Do not
assume exact table names. Map the available raw tables into these analytical
concepts where possible: Tickets, Messages, Agents, Contacts, Departments, Tags,
and Channels (email, chat, call, social).
Important:
- 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.
- If ticket event history is missing, do not calculate reopen rate or
time-in-status. Use a caveat instead.
- Do not claim Metabase connects natively to LiveAgent unless that is explicitly
true in this environment.
Dashboard title: LiveAgent Support Overview
Sections:
1. Executive summary (KPI cards): Tickets created last 7 days; Resolved last 7
days; Open backlog; Median first response time; Volume by channel.
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
Volume by channel.
3. Response time & SLA: First response p50/p90 by week; Open by department;
Reopened by week (only if history exists).
4. Agent performance: Resolved by agent; Median handle time by agent; Open
assigned by agent; Calls by agent.
5. Channels & drivers: Volume by channel over time; Volume by tag; Volume by hour;
Repeat contacts.
Filters: Department, Agent, Channel, Tag, Status, Date range.
Before finalizing, create or recommend reusable Metabase models:
modeled_liveagent_tickets, modeled_liveagent_messages, modeled_liveagent_agents,
modeled_liveagent_contacts, and modeled_liveagent_departments.
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 LiveAgent data in Metabase?
Core tables
| Table | Grain | Key columns |
|---|---|---|
tickets | one row per ticket | id, status, channel, department_id, agent_id, contact_id, date_created, date_resolved |
messages | one row per message | ticket_id, type (agent/customer), is_note, date_created |
agents | one row per agent | id, name, online |
contacts | one row per contact | id, email, name |
departments | one row per department | id, name |
Modeling advice
- Map LiveAgent's coded statuses and channel types to readable labels in a model — raw API data is coded.
- Define first response from the first outbound agent message, excluding notes.
- Treat tags as a bridge table so a ticket can carry many tags.
- Keep call tickets separate where handle time means talk time, not reply time.
- Define "resolved" once and reuse it everywhere.
Which LiveAgent metrics should you track in Metabase?
| Metric | Definition | Notes |
|---|---|---|
| First response time | Created → first agent message. | Report median and p90; exclude notes. |
| Ticket volume | Created vs. resolved in a period. | Segment by channel and department. |
| Channel mix | Share of tickets by channel. | Email, chat, call, and social behave differently. |
| Backlog | Open tickets right now. | Pair with aging and department breakdowns. |
| Agent load | Open and resolved tickets per agent. | Frame as balance, not a leaderboard. |
| Repeat-contact rate | Customers with multiple tickets. | A signal of unresolved root causes. |
What SQL powers LiveAgent dashboards in Metabase?
These assume the modeled tables above (PostgreSQL dialect; LiveAgent uses coded statuses such as R for resolved). Adjust identifiers to match your warehouse.
The basic volume trend over the last 30 days.
SELECT
date_trunc('day', t.date_created) AS day,
COUNT(*) AS created,
COUNT(*) FILTER (WHERE t.status = 'R') AS resolved
FROM tickets t
WHERE t.date_created >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;Median from the first outbound agent message per ticket.
WITH first_outbound AS (
SELECT
m.ticket_id,
MIN(m.date_created) AS first_reply_at
FROM messages m
WHERE m.type = 'A' -- agent message
AND m.is_note = false
GROUP BY m.ticket_id
)
SELECT
date_trunc('week', t.date_created) AS week,
percentile_cont(0.5) WITHIN GROUP (
ORDER BY EXTRACT(EPOCH FROM (f.first_reply_at - t.date_created)) / 60.0
) AS median_first_reply_min
FROM tickets t
JOIN first_outbound f ON f.ticket_id = t.id
GROUP BY 1
ORDER BY 1;Multi-channel mix over the last 30 days.
SELECT
t.channel,
COUNT(*) AS tickets
FROM tickets t
WHERE t.date_created >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY t.channel
ORDER BY tickets DESC;Where open tickets are piling up right now.
SELECT
d.name AS department,
COUNT(*) AS open_tickets
FROM tickets t
JOIN departments d ON d.id = t.department_id
WHERE t.status <> 'R'
GROUP BY d.name
ORDER BY open_tickets DESC;