Dashboards & Analytics · Bookings

Booking Status and No-Show Visibility Board

A board that joins booking status against actual attendance so the team can see booked, completed, and no-show counts in one place instead of inside the calendar tool.

Start a ProjectAll Case Studies
4 to 7 days
build time
4
outcomes
5
stack tools
6
build steps

Built with real HMX dashboard tool paths

Supabase PostgresCal.com booking fields (existing webhook writes)SQL viewNext.js 16 server componentsVercel hostingSupabase PostgresCal.com booking fields (existing webhook writes)SQL viewNext.js 16 server componentsVercel hosting

01 // Outcomes

Outcome signals

One board
for booked, completed, and no-show counts
No-show rate
as a tracked number by week and source
Drill list
of recent no-shows for follow-up
Flagged
missing-status bookings instead of miscounting

Case architecture

Booking Status and No-Show Architecture

6 nodes
which booking-status fields
the no-show rate formula and
Supabase Postgres
Cal
Review Queue
Dashboard Action
  1. 01which booking-status fields

    A board that joins booking status against actual attendance so the team can see booked, completed, and no-show counts in one place instead of insid...

  2. 02the no-show rate formula and

    Define the no-show rate formula and the window with the operator so the denominator is unambiguous.

  3. 03Supabase Postgres

    Supabase Postgres contributes the trusted model for Booking Status and No-Show so metrics are defined before they are visualized.

  4. 04Cal

    Build a view summarizing booked / rescheduled / completed / no-show per week and per lead source.

  5. 05Review Queue

    When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

  6. 06Dashboard Action

    One board for booked, completed, and no-show counts; No-show rate as a tracked number by week and source; Drill list of recent no-shows for follow-...

Problem

The operating gap

Booking lives in the calendar tool and outcomes live in someone's head; nobody can quickly see the no-show rate or how many booked calls actually happened last week without clicking through individual events.

Build

What gets built

A read-only view over the booking fields already written back from the Cal.com webhook — booked, rescheduled, completed, no-show — summarized by week and by source so the no-show rate is a number, not a feeling. It reads existing booking-status fields and does not touch the scheduling flow.

Build steps

How it ships

Booking Status and No-Show Visibility Board uses a reporting model and review layer for Dashboards. A board that joins booking status against actual attendance so the team can see booked, completed, and no-show counts in one place instead of insid... The architecture connects which booking-status fields, supabase postgres, cal, and dashboard action with an explicit control path.

  1. 01Confirm which booking-status fields the Cal.com webhook already writes and how no-show / completed are recorded.
  2. 02Define the no-show rate formula and the window with the operator so the denominator is unambiguous.
  3. 03Build a view summarizing booked / rescheduled / completed / no-show per week and per lead source.
  4. 04Render a board with the weekly counts, the no-show rate trend, and a drill list of recent no-shows.
  5. 05Flag bookings with a missing or stale status as a data-quality note rather than counting them as attended.
  6. 06Document the definitions so the no-show rate is consistent every week.

Stack

Tools and layers

  • Supabase Postgres
  • Cal.com booking fields (existing webhook writes)
  • SQL view
  • Next.js 16 server components
  • Vercel hosting
  • Inputs layer: Confirm which booking-status fields the Cal.com webhook already writes and how no-show / completed are recorded.
  • Transform layer: Define the no-show rate formula and the window with the operator so the denominator is unambiguous.
  • Metrics layer: Supabase Postgres contributes the trusted model for Booking Status and No-Show so metrics are defined before they are visualized.
  • Visualization layer: Cal.com booking fields (existing webhook writes) handles refresh, review, or reporting delivery while a read-only view over the booking fields already written back from the Cal.com webhook — booked, rescheduled, completed, no-show — summarized by we...
  • Action layer: One board for booked, completed, and no-show counts; No-show rate as a tracked number by week and source; Drill list of recent no-shows for follow-...

Data flow

  1. 01Confirm which booking-status fields the Cal.com webhook already writes and how no-show / completed are recorded.
  2. 02Define the no-show rate formula and the window with the operator so the denominator is unambiguous.
  3. 03Build a view summarizing booked / rescheduled / completed / no-show per week and per lead source.
  4. 04Render a board with the weekly counts, the no-show rate trend, and a drill list of recent no-shows.
  5. 05Flag bookings with a missing or stale status as a data-quality note rather than counting them as attended.
  6. 06Document the definitions so the no-show rate is consistent every week.

Controls

  • Booking lives in the calendar tool and outcomes live in someone's head; nobody can quickly see the no-show rate or how many booked calls actually h...
  • A read-only view over the booking fields already written back from the Cal.com webhook — booked, rescheduled, completed, no-show — summarized by we...
  • When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

Research basis