Cal.com show rate scorecard with a no-show marking queue

Build me an interactive show rate scorecard app for Cal.com. My sales leader does not ask how many meetings we booked, she asks how many we actually held, and Cal.com's own insights do not answer that. The app has two views: a scorecard for any date range, and a marking queue where a human records whether each past meeting was held or a no-show.

All data comes from Cal.com's Get All Bookings operation. Fetch every booking whose start time falls inside the selected date range, paging with take and skip until the response reports no next page, since take defaults to 100 and a quarter of history will not fit in one call. Bookings endpoints need the cal-api-version header set to 2026-02-25, and responses arrive wrapped as { status, data }, so unwrap before use. The rate limit is 120 requests per minute, so pace the paged fetches and hold the fetched range in memory while the user works, so re-sorting a table does not refetch everything.

The first view is the scorecard. At the top, a date range picker with presets for last 7 days, last 30 days, this month, last month, and a custom range. Under it, four headline tiles: meetings held, attendee no-shows, cancellations, and held rate. Each tile shows the underlying count so the number is auditable, and the held rate tile states the denominator it used.

Get the math exactly right, because this is where these reports usually go wrong. Held rate is held meetings divided by held meetings plus attendee no-shows. A held meeting is a past, accepted booking where no attendee was marked absent. An attendee no-show is a past, accepted booking where at least one attendee was marked absent. Cancelled, rescheduled and still pending bookings are excluded from that denominator entirely, and so is anything whose end time has not passed yet. Cancellations get their own tile and their own column but are never folded into the no-show number. Host no-shows are tracked and shown separately and never count against the attendee held rate.

Below the tiles, two breakdown tables built from the same fetched bookings, grouped on the event type and host fields already present on each booking record, so no extra lookup is needed. The first ranks every event type by held rate. The second ranks every host by held rate, worst first, because that is the table my sales leader actually reads. Columns for both: name, meetings held, attendee no-shows, cancellations, decisions counted (the denominator), and held rate. Both tables sortable by any column. Rows with fewer than five counted decisions are flagged as low volume and sorted below the rest, so a single missed call does not put a rep at the top of the worst list.

Show a marking coverage indicator on the scorecard: how many past bookings inside the range still have no held or no-show decision recorded. If any are unmarked, label the held rate provisional and link straight into the marking queue with the same date range already applied.

The second view is the marking queue. It lists past accepted bookings whose end time has passed and for which nobody has recorded a decision yet, oldest first, showing date and time, event type, host, and the attendee names and emails. Each row has two buttons, Held and No Show. Held calls Cal.com's Mark Booking Absence for that booking with the attendees marked as not absent. No Show calls the same operation with the absent attendee or attendees marked absent. When a booking has several attendees, let the user choose which ones were absent rather than assuming all of them. Include a separate, less prominent control to mark the host absent, for the case where our side missed the call.

Persist every decision inside the app as well as writing it to Cal.com, recording the booking id, the decision, who made it, and when. This matters: a booking nobody has touched and a booking explicitly judged as held can look identical coming back from the API, so without a local record the queue would never empty. Treat the locally stored decisions as the source of truth for whether a booking has been judged, and the Cal.com absence flags as the source of truth for the held or no-show outcome. Rows leave the queue as soon as they are decided, with an undo affordance for a mis-click.

On the scorecard, give me a button that appends the current scorecard as a dated row to a Google Sheet using Append Values, so I build a month over month history. The user picks the spreadsheet and tab once and the app remembers it. The row: date appended, range start, range end, meetings held, attendee no-shows, cancellations, held rate, host no-shows, decisions counted, and the percentage of past bookings that had been marked when the row was written. If the tab is empty, write a header row first.

Also on the scorecard, a button that posts the summary to Slack with Send a Message, for the Monday revenue meeting. Let the user choose the channel from a picker populated by List Channels and remember the choice. Format with Slack mrkdwn, so single asterisks for bold, and keep it to the date range, the four headline numbers, the three worst hosts, the best and worst event type, and one line on how many past meetings are still unmarked.

Keep the visible copy plain: say meetings that actually happened, not bookings with an absence flag. Where a benchmark helps someone judge their own number, note that inbound demo requests generally hold above 80 percent, and that outbound booked meetings typically run 25 to 35 percent no-shows, so under 25 percent is good work. Do not add scheduled reports or recurring digests. This app is the interactive counterpart to a weekly recap: arbitrary date ranges, sortable breakdowns, and a marking queue that only a human can work.