Pylon × Metabase

How to build Pylon support dashboards in Metabase

Pylon is an AI-native B2B support platform that unifies conversations from Slack, Microsoft Teams, email, and in-app chat with rich account context. 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 Pylon 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.

Heads up: Metabase connects to SQL databases and warehouses — it does not ship a native Pylon connector. For dashboards that need history and reliability, you'll sync Pylon into a database first (covered below).

How do you connect Pylon to Metabase?

Metabase connects to SQL databases and warehouses — not to SaaS APIs directly, and there's no native Pylon connector. So connecting Pylon to Metabase means one thing: run a small pipeline that copies Pylon 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 Pylon data in Metabase?

  • Issue volume — created vs. resolved by day and channel
  • Time to first response — overall and by account tier
  • Account health — open issues, escalations, and load by account
  • Backlog and aging — open work and how long it's been waiting
  • Contact drivers — volume by tag and feature requests
  • Channel mix — Slack vs. Teams vs. email
  • Team load — workload distribution across members

Which Pylon dashboards should you build in Metabase?

For: Support & CS leads

Support overview

The daily pulse across channels.

  • Issues created vs. resolved per day (dual line)
  • Median time to first response (number + trend)
  • Open backlog by status (bar)
  • Volume by channel (Slack, Teams, email) (bar)
For: Customer success

Account health

B2B support is account-shaped, not just ticket-shaped.

  • Open issues by account (table)
  • Accounts with rising issue volume (line)
  • Escalations by account (bar)
  • Top accounts by support load (table)
For: Support ops

Response time & SLA

Are we responding fast for key accounts?

  • First response time p50/p90 by week (line)
  • Response time by account tier (bar)
  • Aging open issues by days-open bucket (table)
  • Reopened issues by week (line)
For: Product & eng liaison

Drivers & feature requests

Turn support signal into product priorities.

  • Volume by tag/topic (bar)
  • Feature requests by account (table)
  • Issues linked to engineering work (number)
  • Top contact drivers this quarter (bar)

How do you build the Pylon → Metabase pipeline?

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

No paid tool required. A fully free stack: a small dlt or hand-written script (extract) → a free Postgres database like Neon or Supabase (load) → a scheduler such as GitHub Actions cron (host) → Metabase (visualize). For hosting and scheduling details, see our data pipeline guide.

Connector options

  • dlt (free, code) — write a Python pipeline against the Pylon REST API; the most reliable route since there's no first-party managed connector.
  • Pylon REST API (free, raw) — the source of truth; paginate issues, accounts, and contacts and upsert on a schedule.
  • Managed ETL (paid, verify) — check whether your ETL vendor offers a Pylon connector; availability varies, so confirm before relying on it.

Notes

  • Land raw tables first, then build clean models on top.
  • Sync accounts and their custom fields — account context is what makes B2B support analytics useful.
  • Capture issue state changes if you want accurate reopen rate and time-in-status.

Can you generate a Pylon dashboard with AI?

Yes — and once Pylon 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:

ClaudeClaude Code CLI
# Metabase built-in MCP (replace with your instance URL)
claude mcp add --transport http metabase https://your-metabase.example.com/api/metabase-mcp
Cursor~/.cursor/mcp.json or .cursor/mcp.json
{
  "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 & authenticateshell
# 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 Pylon Support Overview dashboard

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

Prompt for creating a Pylon Support Overview dashboard
Create a polished Metabase dashboard for Pylon B2B support analytics using the
available Pylon tables in this database.

Goal: Help support and customer success leaders understand volume, responsiveness,
account health, and contact drivers from Pylon data.

First, inspect the schema and identify the available Pylon tables. Do not assume
exact table names. Map the available raw tables into these analytical concepts
where possible: Issues, Accounts, Contacts, Users (team members), Channels, Tags,
and custom fields.

Important:
- Build the dashboard from durable database/warehouse tables.
- Use medians (p50) and p90 for response times, never averages.
- B2B support is account-shaped — roll metrics up to the account where useful.
- If issue state history is missing, do not calculate reopen rate or
  time-in-status. Use a caveat instead.
- Do not claim Metabase connects natively to Pylon unless that is explicitly
  true in this environment.

Dashboard title: Pylon Support Overview

Sections:
1. Executive summary (KPI cards): Issues created last 7 days; Resolved last 7
   days; Open backlog; Median time to first response; Accounts with open
   escalations; Volume by channel.
2. Volume & backlog: Created vs resolved by day; Open by status; Backlog aging;
   Volume by channel.
3. Account health: Open issues by account; Accounts with rising volume; Top
   accounts by load; Escalations by account.
4. Response time: First response p50/p90 by week; Response time by account tier;
   Reopened by week (only if history exists).
5. Drivers: Volume by tag; Feature requests by account; Top contact drivers.

Filters: Account, Channel, Tag, Assignee, Status, Date range.

Before finalizing, create or recommend reusable Metabase models:
modeled_pylon_issues, modeled_pylon_accounts, modeled_pylon_contacts, and
modeled_pylon_users.

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 Pylon data in Metabase?

Core tables

TableGrainKey columns
issuesone row per issueid, state, channel, account_id, assignee_id, requester_id, created_at, first_response_at, closed_at
accountsone row per account (company)id, name, domain, owner_id, tier (custom field)
contactsone row per contactid, email, account_id
usersone row per team memberid, name

Modeling advice

  • Roll issues up to the account for most B2B support dashboards.
  • Normalize state (new/open/on-hold/closed) and channel so charts stay stable.
  • Bring account custom fields (tier, ARR, owner) into your model so you can segment load by account value.
  • Treat tags as a bridge table so an issue can carry many tags.
  • Define "closed" once and reuse it everywhere.

Which Pylon metrics should you track in Metabase?

MetricDefinitionNotes
Time to first responseCreated → first response.Report median and p90; segment by account tier.
Issue volumeCreated vs. resolved in a period.Segment by channel and account.
Open issues by accountBacklog rolled up to the account.Core B2B health signal.
EscalationsIssues flagged or escalated, by account.Watch concentration in key accounts.
Backlog agingHow long open issues have waited.Bucket by days open.
Feature-request volumeIssues tagged as requests, by account.Feeds product prioritization.

What SQL powers Pylon dashboards in Metabase?

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

Issues created vs. resolved per dayPostgreSQL

The basic volume trend over the last 30 days.

SELECT
  date_trunc('day', i.created_at) AS day,
  COUNT(*)                                        AS created,
  COUNT(*) FILTER (WHERE i.state = 'closed')      AS resolved
FROM issues i
WHERE i.created_at >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY 1
ORDER BY 1;
Open issues by accountPostgreSQL

Where the support load concentrates across B2B accounts.

SELECT
  a.name             AS account,
  COUNT(*)           AS open_issues
FROM issues i
JOIN accounts a ON a.id = i.account_id
WHERE i.state <> 'closed'
GROUP BY a.name
ORDER BY open_issues DESC
LIMIT 25;
Time to first response by weekPostgreSQL

Median from the issue's first-response timestamp.

SELECT
  date_trunc('week', i.created_at) AS week,
  percentile_cont(0.5) WITHIN GROUP (
    ORDER BY EXTRACT(EPOCH FROM (i.first_response_at - i.created_at)) / 60.0
  ) AS median_first_reply_min
FROM issues i
WHERE i.first_response_at IS NOT NULL
GROUP BY 1
ORDER BY 1;
Volume by channelPostgreSQL

Slack vs. Teams vs. email over the last 30 days.

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

What are common mistakes when analyzing Pylon in Metabase?

Running dashboards off a one-time CSV export.→ Schedule the sync so data stays fresh — a manual export goes stale the moment someone acts on it.
Reporting only at the issue grain.→ B2B support is account-shaped — roll metrics up to the account to see real health.
Ignoring account custom fields.→ Bring tier and ARR into your model so load is weighted by account value.
Using averages for response time.→ Report medians and p90 — these durations are heavily right-skewed.
Expecting reopen rate without state history.→ Sync issue state changes if you want accurate reopen and time-in-status metrics.

Related analytics

Related integrations

FAQ

Does Metabase connect natively to Pylon?
No. Metabase reads SQL databases and warehouses. Sync Pylon into a database first (dlt or the REST API), then connect Metabase to that database.
Do I need a paid connector to sync Pylon?
No. Pylon has no first-party managed connector, so a free stack is the natural fit: a small dlt or hand-written script against the Pylon REST API, a free Postgres tier (Neon or Supabase), and GitHub Actions cron to run it on a schedule.
Why roll metrics up to the account?
Pylon is built for B2B support, where the meaningful unit is the customer account, not the individual ticket. Account-level open issues, escalations, and load surface churn and renewal risk that ticket counts hide.