Medium Dashboards system

Booking & No-Show Status Report

A reporting view over the booking lifecycle — invited, booked, rescheduled, completed, cancelled, no-show — that turns Cal.com webhook events plus CRM lead booking fields into rates and counts: book rate from lead, no-show rate, reschedule rate, and time-to-book. It gives owners a weekly read on whether reminders and scheduling are working. Strictly a measurement layer over existing booking data, not the booking automation itself.

Start a Project All Systems

4 to 8 days: timeline
Medium: complexity
5: tools
4: steps

Built with real HMX dashboard tool paths

Supabase PostgresCal.com webhooksSQL viewsNext.js 16 server componentsWebhook signature verificationSupabase PostgresCal.com webhooksSQL viewsNext.js 16 server componentsWebhook signature verification

01 // System facts

System facts

Booking & No-Show Status Report uses a reporting model and review layer for Dashboards. A reporting view over the booking lifecycle — invited, booked, rescheduled, completed, cancelled, no-show — that turns Cal.com webhook events plus... The architecture connects the booking state model from, supabase postgres, cal, and owner review with an explicit control path.

Outcome

A clear weekly picture of booking and no-show performance — owners can see whether reminders are reducing no-shows and how many booked slots actually happen, framed as fewer missed sessions when timed reminders work.

Main risk

No-show data is only as good as the source events; if Cal.com webhooks miss or the CRM field lags, completed/no-show counts are quietly wrong.

Prevention

Verify webhook signatures and delivery, run the CRM-vs-Cal.com reconciliation flag on every refresh, and treat 'no event in N hours after slot' as a review item rather than silently marking complete.

Fallback

If webhook reliability is shaky, fall back to reporting only the states the CRM can confirm (invited/booked) and mark no-show/completed as 'needs manual confirm' until the event feed is stable.

System architecture

Booking & No-Show Status Report Architecture

6 nodes

the booking state model from

SQL to compute booking

Supabase Postgres

Cal

Review Queue

Owner Review

01the booking state model from
A reporting view over the booking lifecycle — invited, booked, rescheduled, completed, cancelled, no-show — that turns Cal.com webhook events plus...
02SQL to compute booking
Write SQL to compute booking funnel rates (booked / eligible leads), no-show rate, reschedule rate, and median time-to-book, with a date window and source breakdown.
03Supabase Postgres
Supabase Postgres contributes the trusted model for Booking & No-Show Status Report so metrics are defined before they are visualized.
04Cal
Render a status report panel (server component) with the funnel counts, the key rates as big numbers with prior-period delta, and a list of recent no-shows/cancellations for follow-up.
05Review Queue
If webhook reliability is shaky, fall back to reporting only the states the CRM can confirm (invited/booked) and mark no-show/completed as 'needs m...
06Owner Review
A clear weekly picture of booking and no-show performance — owners can see whether reminders are reducing no-shows and how many booked slots actual...

How it is built

Build steps

01Map the booking state model from the real signals: Cal.com webhook fields (booking created/cancelled/rescheduled) and the CRM booking_status/status columns updated by the webhook handler, into one normalized status per lead.
02Write SQL to compute booking funnel rates (booked / eligible leads), no-show rate, reschedule rate, and median time-to-book, with a date window and source breakdown.
03Render a status report panel (server component) with the funnel counts, the key rates as big numbers with prior-period delta, and a list of recent no-shows/cancellations for follow-up.
04Add a reconciliation check that flags leads whose CRM booking_status disagrees with the latest Cal.com event (a sync gap) so the numbers stay trustworthy.

Tools

Workflow surface

Supabase Postgres
Cal.com webhooks
SQL views
Next.js 16 server components
Webhook signature verification

Inputs layer: Map the booking state model from the real signals: Cal.com webhook fields (booking created/cancelled/rescheduled) and the CRM booking_status/status columns updated by the webhook handler, into one normalized status per lead.
Transform layer: Write SQL to compute booking funnel rates (booked / eligible leads), no-show rate, reschedule rate, and median time-to-book, with a date window and source breakdown.
Metrics layer: Supabase Postgres contributes the trusted model for Booking & No-Show Status Report so metrics are defined before they are visualized.
Visualization layer: Cal.com webhooks handles refresh, review, or reporting delivery while verify webhook signatures and delivery, run the CRM-vs-Cal.com reconciliation flag on every refresh, and treat 'no event in N hours after slot' as...
Action layer: A clear weekly picture of booking and no-show performance — owners can see whether reminders are reducing no-shows and how many booked slots actual...

Data flow

01Map the booking state model from the real signals: Cal.com webhook fields (booking created/cancelled/rescheduled) and the CRM booking_status/status columns updated by the webhook handler, into one normalized status per lead.
02Write SQL to compute booking funnel rates (booked / eligible leads), no-show rate, reschedule rate, and median time-to-book, with a date window and source breakdown.
03Render a status report panel (server component) with the funnel counts, the key rates as big numbers with prior-period delta, and a list of recent no-shows/cancellations for follow-up.
04Add a reconciliation check that flags leads whose CRM booking_status disagrees with the latest Cal.com event (a sync gap) so the numbers stay trustworthy.

Controls and fallbacks

No-show data is only as good as the source events; if Cal.com webhooks miss or the CRM field lags, completed/no-show counts are quietly wrong.
Verify webhook signatures and delivery, run the CRM-vs-Cal.com reconciliation flag on every refresh, and treat 'no event in N hours after slot' as...
If webhook reliability is shaky, fall back to reporting only the states the CRM can confirm (invited/booked) and mark no-show/completed as 'needs m...

Research basis