How to build Calendly scheduling dashboards in Metabase

Calendly is the scheduling tool most revenue teams run on — event types, scheduled events, invitees, routing forms, and no-show marks, sitting right at the top of the pipeline funnel. Metabase is where you turn that record into shared, trustworthy scheduling dashboards. This guide covers two complementary paths: a lightweight MCP + CLI route that pulls live data with the Calendly MCP server and loads a CSV into Metabase with the Metabase CLI, and a durable pipeline route that lands Calendly data in a database so you can build dashboards anyone can read.

How do you connect Calendly to Metabase?

Most teams combine both routes: quick answers through MCP and CLI uploads first, then recurring reporting on a warehouse-backed model.

What can you analyze from Calendly data in Metabase?

These all come from the same core objects — scheduled events, plus the invitees and their answers, event types, routing form submissions your sync exposes:

• Meetings booked by rep and by team
• No-show and cancellation rates
• Speed to lead: form submission to booked meeting
• Routing form conversion by path
• Rep utilization and available capacity

Which Calendly scheduling dashboards should you build in Metabase?

How do you use the Calendly MCP server with the Metabase CLI?

Pair the Calendly MCP server with the Metabase CLI for fast, hands-on analysis. MCP is useful for scoped lookups and summarized exports; the Metabase CLI's upload command loads CSV data into Metabase and creates a ready-to-query table and model.

Example workflow

• Ask the MCP server for scheduled events for the trailing 90 days with host, event type, status, cancellation, and no-show fields.
• Export the result as CSV, keeping stable IDs, owners, statuses, and dates — and hashing or dropping any personal contact fields.
• Run mb upload csv to load it into Metabase as a table and model, then build questions and dashboards on top.

Be honest about the limits

• MCP lookups are excellent for exploration, not scheduled reporting.
• A CSV upload is a snapshot; refresh it with mb upload replace or move to the pipeline for real history.
• Meeting records change after they are created — cancellations, reschedules, and no-show marks all land later — so re-read a trailing window instead of only new rows.
• mb upload csv needs an uploads database configured under Admin → Settings → Uploads.

How do you set up Calendly MCP and the Metabase CLI?

{
  "mcpServers": {
    "calendly": {
      "type": "http",
      "url": "https://mcp.calendly.com"
    }
  }
}

Calendly's hosted server, GA in March 2026, and the smoothest connect flow of any tool in these clusters: it supports Dynamic Client Registration, so your client registers itself and you just approve the OAuth prompt — no console-issued client ID to paste. That also means the reverse is true: clients that require a manually configured client ID and secret won't work, and personal access tokens are explicitly not accepted. Your client must support MCP spec 2025-03-26 or later, and there is no self-hosted build.

# Install the Metabase CLI
npm install -g @metabase/cli

# Log in (opens your browser; requires Metabase v62+)
mb auth login --url https://your-metabase.example.com

# Load a meetings export — creates a table AND a model
mb upload csv --file calendly-meetings.csv --collection root

# Refresh that same table later from a new export
mb upload replace <table-id> --file calendly-meetings.csv

Can you generate a Calendly dashboard with AI?

Yes. Use the prompt below with any assistant that can run the Calendly MCP server and the Metabase CLI. It works end to end: if Calendly tables already exist in Metabase it analyzes those; otherwise it pulls scoped, summarized data, loads it with mb upload csv, then builds the dashboard and caveats any metric that needs missing history.

Create a polished Metabase dashboard for Calendly scheduling analytics.
Work end to end: get the data into Metabase if it isn't there yet, then build.

Goal: Help sales and revenue operations leaders understand meetings booked per rep, no-show and cancellation rates, speed to lead, and routing form conversion from Calendly data.

Step 1 — Find or load the data:
- First, check what already exists in Metabase (search for calendly tables and
  models). If durable Calendly data is already present — a warehouse sync or
  an earlier upload — use it and skip to Step 2.
- If nothing is there, pull a scoped, summarized export with the Calendly MCP server:
  scheduled events, plus invitees and their answers, event types, routing form submissions.
  Prefer one row per meeting or invitee over raw activity
  feeds. Write each result to a CSV, then load it with the Metabase CLI — run
  "mb upload csv --file <export>.csv" so each upload creates a table and a
  ready-to-query model. Use "mb upload replace <table-id> --file <export>.csv"
  to refresh an existing table instead of creating duplicates.

Step 2 — Inspect before querying:
Do not assume exact table or column names. Inspect available fields, owners,
segments, statuses, and date ranges before creating trend cards.

Important:
- Build on whatever data is present; don't claim Metabase connects natively to
  Calendly — it reads a database or CLI-uploaded tables.
- Exclude canceled meetings from no-show denominators: a meeting that was
  called off was never an opportunity to show up.
- Use medians, not averages, for speed-to-lead and booking lead time — a few
  far-future bookings drag the mean badly.
- Records mutate after creation (cancellations, reschedules, no-show marks), so
  say plainly on the dashboard how recently the window was re-read.
- Don't load raw invitee email addresses into the warehouse; hash or drop them.

Dashboard title: Calendly Scheduling Overview

Sections:
1. Executive summary: Meetings booked this month; Held meetings;
   No-show rate; Cancellation rate; Median speed to lead.
2. Volume: Meetings booked per week and per rep; event type mix.
3. Quality: No-show rate with cancellations excluded; cancellations by event
   type; reschedules per booked meeting.
4. Speed to lead: Median minutes from submission to booking; unbooked
   submissions; conversion by routing path.
5. Capacity: Meetings per rep vs. target; booked hours; round-robin spread.

Filters: Date range, Host or rep, Event type, Status, Lead source.

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 data.

How do you sync Calendly data into a database or warehouse?

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

Connector options

• Managed ETL — use a connector when one covers the objects you need, and read its support level and sync mode before you rely on it.
• Custom pipeline — use the Calendly API v2 for control over snapshot grain, fields, and refresh cadence.
• MCP + CSV — use this for quick exploration and one-off slices.

Airbyte's <code>source-calendly</code> (Marketplace support level) syncs event types, scheduled events, groups, and organization memberships, with incremental support on event types and scheduled events. One important caveat: the <code>scheduled_events</code> stream uses <code>start_time</code> as its incremental cursor, so cancellations and reschedules recorded after a sync won't be picked up — run a periodic full refresh, as Airbyte's own docs recommend, or no-show and cancellation metrics will drift. Fivetran offers an Application Lite connector. The API itself uses cursor pagination with a maximum page size of 100.

Notes

• Decide the snapshot grain first (one row per meeting, one row per invitee) — it drives storage and every trend card.
• Land raw tables first, then build clean Metabase models on top.
• Normalize meeting-id, host-user, event-type, created-at, start-time, status, and cancellation-time fields.

How should you model Calendly data in Metabase?

Core tables

Modeling advice

• Build a clean scheduled_meetings model with the same columns across scheduling tools, so a team running two of them doesn't fork the definitions.
• Keep status, cancellation time, reschedule flags, and no-show marks as explicit columns — every rate metric depends on which of them lands in the denominator.
• Re-read a trailing window on each sync rather than only new rows: meeting records keep changing after they are created.
• Hash or drop invitee email addresses before they reach the warehouse, and join meetings to CRM accounts on a stable key rather than on an email domain.

Which Calendly scheduling metrics should you track in Metabase?

Scheduling data is the top of the funnel, so most of its value shows up in pipeline metrics further down. See Sales analytics for conversion, velocity, and win-rate definitions that use these meetings as their first step.

What SQL powers Calendly scheduling dashboards in Metabase?

These assume a cleaned analytical model in a warehouse (PostgreSQL dialect). Adjust table and column names to match your pipeline.

SELECT
  date_trunc('week', created_at) AS booked_week,
  host_user,
  COUNT(*) AS meetings_booked,
  COUNT(*) FILTER (WHERE status = 'canceled') AS canceled_later,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE status = 'canceled')
    / NULLIF(COUNT(*), 0), 1
  ) AS cancel_rate_pct
FROM scheduled_meetings
WHERE created_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1, 2
ORDER BY booked_week DESC, meetings_booked DESC;

-- Canceled meetings are excluded from the denominator: a meeting that
-- was called off was never an opportunity for anyone to show up.
SELECT
  date_trunc('month', m.start_time) AS month,
  COUNT(*) AS invitees_expected,
  COUNT(*) FILTER (WHERE i.no_show_at IS NOT NULL) AS no_shows,
  ROUND(
    100.0 * COUNT(*) FILTER (WHERE i.no_show_at IS NOT NULL)
    / NULLIF(COUNT(*), 0), 1
  ) AS no_show_rate_pct
FROM meeting_invitees i
JOIN scheduled_meetings m ON m.meeting_id = i.meeting_id
WHERE m.status <> 'canceled'
  AND m.start_time < now()
  AND m.start_time >= CURRENT_DATE - INTERVAL '12 months'
GROUP BY 1
ORDER BY 1;

-- Median, not average: one lead booked three weeks later
-- would move the mean and tell you nothing useful.
SELECT
  date_trunc('week', s.submitted_at) AS week,
  COUNT(*) AS submissions,
  COUNT(m.meeting_id) AS submissions_that_booked,
  ROUND(
    PERCENTILE_CONT(0.5) WITHIN GROUP (
      ORDER BY EXTRACT(EPOCH FROM (m.created_at - s.submitted_at)) / 60
    )::numeric, 1
  ) AS median_minutes_to_booking
FROM routing_form_submissions s
LEFT JOIN scheduled_meetings m ON m.meeting_id = s.resulting_meeting_id
WHERE s.submitted_at >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY 1
ORDER BY 1;

What are common mistakes when analyzing Calendly in Metabase?

Related

Related analytics

Related dashboards

Related integrations

FAQ