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. This guide covers two complementary paths: a lightweight MCP route for fast, AI-assisted questions, and a durable pipeline route that syncs Pylon into a database so you can build dashboards anyone can read.

How do you connect Pylon to Metabase?

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

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?

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

Pair the Pylon MCP server with the Metabase MCP server for live, conversational analysis. The Pylon MCP reads current issues and accounts; the Metabase MCP queries the models and dashboards you've already built.

Example workflows

• List accounts with open escalations and summarize by owner.
• Pull a customer's open issues from Pylon and cross-check load trends against a Metabase model.
• Trace an issue from Pylon to a linked pull request and back.

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.
• Access follows the authenticated user's permissions in Pylon.
• The Metabase MCP server is built in; an admin enables it under Admin → AI → MCP.

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

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

A Pylon admin enables the MCP server under Settings → AI Controls → MCP Server, and each user needs the MCP Access role. On first connection the server opens a browser window to authorize.

Can you generate a Pylon 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 Pylon 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 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:
- 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.
- 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 do you sync Pylon data into a database or warehouse?

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

Connector options

• dlt(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(raw) — the source of truth; paginate issues, accounts, and contacts and upsert on a schedule.
• Managed ETL (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.

How should you model Pylon data in Metabase?

Core tables

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?

What SQL powers Pylon dashboards in Metabase?

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

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;

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;

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;

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?

Related

Related analytics

Related integrations

FAQ