Analytics systems grouped by the operating question.
Data cleanup, source modeling, review dashboards, report cadence, and exception flags.
- 25
- case studies
- 19
- systems
- 2
- proof artifacts
- 3
- scope tiers
Built with real HMX dashboard tool paths
01 // Systems
Dashboards & Analytics Systems
The systems we build for this service, with steps and fallbacks.
High system
Action Queue Dashboard
A do-this-next dashboard that inverts traditional reporting: instead of metrics, it surfaces the prioritized list of records that need human action right now — overdue follow-ups, leads with no owner, booked-but-not-confirmed, hot leads untouched past SLA, no-shows to recover, hygiene errors to fix — each as a clickable worklist item. It composes signals from across the suite into one ranked queue. The capstone view that makes the analytics actionable rather than observational.
- Timeline
- 5 to 9 days
- Fallback
- Defined
- Supabase Postgres
- SQL (UNION / prioritization)
- Next.js 16 server components
- Cross-suite views
- Admin deep links
View system
Medium system
Admin & System Monitoring Report
An internal operations dashboard for the people running the system — recent admin actions (audit log), route health checks, critical monitoring events, error/spam spikes, and rate-limit hits — so the operator's own platform is observable, not just the business funnel. It consolidates admin_audit_log, monitoring_route_checks, and monitoring_events into one operational read. This is the run-the-system view that complements the run-the-business dashboards.
- Timeline
- 4 to 8 days
- Fallback
- Defined
- Supabase Postgres
- admin_audit_log / monitoring_route_checks / monitoring_events
- Next.js 16 admin (HMAC session)
- Existing lib/monitoring.ts
View system
High system
Automation Health Monitor
A monitoring dashboard for the automations that keep the funnel alive — admin-notified, auto-reply-sent, webhook processed, scheduled job ran — showing success/failure counts, last-success timestamps, and gaps where an expected automation didn't fire. It reads the monitoring_events table and the lead notification fields to answer 'is the plumbing actually running?'. It reports on automations; it does not build or run them.
- Timeline
- 5 to 9 days
- Fallback
- Defined
- Supabase Postgres
- monitoring_events table
- SQL views
- Next.js 16 server components
- Resend (alert email path)
View system
Medium 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.
- Timeline
- 4 to 8 days
- Fallback
- Defined
- Supabase Postgres
- Cal.com webhooks
- SQL views
- Next.js 16 server components
- Webhook signature verification
View system
Medium system
Call Outcome Dashboard
A dashboard that summarizes the outcomes of sales/discovery calls logged against leads — connected, voicemail, no-answer, booked-from-call, not-interested, callback-requested — with counts, connect rate, and outcome mix per owner and per day. It turns call-disposition notes captured in the CRM into a trend instead of scattered text. Reporting only: it reads dispositions, it does not place or transcribe calls.
- Timeline
- 4 to 7 days
- Fallback
- Defined
- Supabase Postgres
- SQL aggregation
- CRM activity/disposition field
- Next.js 16 server components
View system
Medium system
Campaign Performance View
A campaign-level view that ties leads and bookings back to the campaign/UTM that drove them and reports volume, cost-aware efficiency (if spend is provided), and downstream quality — booked rate and completed rate per campaign — so spend follows what converts, not just what clicks. It joins captured UTM campaign data to lead outcomes and optionally an imported spend table. Strictly an analytics view over campaign metadata; it does not run ads.
- Timeline
- 5 to 9 days
- Fallback
- Defined
- Supabase Postgres
- UTM capture
- SQL joins
- CSV/table spend import
- Next.js 16 server components
View system
High system
Conversion Reporting Model
A defined, repeatable conversion model that fixes the full funnel math once — visitor/lead -> qualified -> booked -> completed -> won — with each stage's denominator, numerator, and conversion % pinned down so every report uses the same definitions. It is delivered as a documented SQL model (views) plus a report panel, not an ad-hoc chart someone rebuilds each month with different math. The model is the contract; the chart just renders it.
- Timeline
- 5 to 10 days
- Fallback
- Defined
- Supabase Postgres
- Layered SQL views
- Next.js 16 server components
- KPI definition doc
View system
High system
Cost & Usage View
A cost-awareness dashboard that pulls usage and spend signals from the actual infrastructure — Supabase (DB size, egress, compute, MAU), Vercel (bandwidth, function/edge usage, build minutes), and any metered API/email usage — into one view with trend and budget thresholds, so surprise bills are caught before the invoice. It reads provider usage APIs/billing exports on a schedule and trends them. Pure observability over cost; it does not change infrastructure or plans.
- Timeline
- 5 to 10 days
- Fallback
- Defined
- Vercel API (usage/billing)
- Supabase usage + Postgres snapshot table
- Supabase/Vercel Cron
- Edge function
- Next.js 16 server components
View system
Medium system
CRM Data Hygiene Board
A data-quality board that scores the CRM on the things that quietly break reporting — duplicate leads, missing required fields, blank owner, invalid email/phone, stale statuses, and contradictory booking states — listing the actual offending records so they can be fixed. It exists because every other analytics view is only as good as the underlying data. It measures and lists hygiene problems; it does not auto-edit records.
- Timeline
- 5 to 9 days
- Fallback
- Defined
- Supabase Postgres
- SQL (dedup / validation)
- Existing lead-duplicate logic
- Next.js 16 server components
View system
Low system
Data Freshness & Staleness Check
A freshness panel that watches the heartbeat of each data source feeding the dashboards — last lead, last subscriber, last booking event, last blog change, last successful job — and flags any feed that hasn't updated within its expected window. It answers 'are the numbers I'm looking at current?' before anyone trusts a chart. This is the trust layer under every other dashboard in the suite.
- Timeline
- 3 to 5 days
- Fallback
- Defined
- Supabase Postgres
- SQL (max timestamp / age)
- Next.js 16 server components
- TypeScript
View system
Low system
KPI Definition Sheet & Glossary
A single source-of-truth document plus a lightweight in-app glossary that pins down every metric used across the dashboards — exact formula, numerator, denominator, time basis, included/excluded buckets, refresh cadence, and owner — so 'conversion rate', 'active lead', and 'no-show' mean exactly one thing. It is the governance artifact every other system in this suite references. It defines metrics; it does not compute them, but it is what makes the computations trustworthy and consistent.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Markdown/doc in repo
- SQL reference snippets
- Next.js 16 (glossary route/tooltips)
- Version control (git)
View system
Low system
Lead Quality Tag Chart
A view that visualizes the distribution and trend of lead-quality tags — hot/warm/cold, qualified/unqualified, ICP-fit/not, junk/spam — and ties quality tags to downstream outcomes so 'quality' is validated against whether those leads actually book and complete. It reads the CRM quality/tag field and joins it to booking outcomes. Analytics over an existing tagging scheme; it does not auto-tag or score leads with AI.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Supabase Postgres
- SQL (distribution + cross-tab)
- CRM quality/tag field
- Next.js 16 server components
View system
Medium system
Lead Source Attribution Dashboard
An operational view that breaks inbound leads down by where they actually came from (form source tag, UTM, referrer, paid vs organic vs referral) and shows volume, share, and trend per source over a chosen window. It joins the CRM lead table to first-touch UTM/referrer capture so owners can see which channels feed the pipeline and which have gone quiet, instead of guessing. Built as a read-only Postgres-backed panel that any operator can open during weekly review.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Supabase Postgres
- SQL views / materialized views
- Supabase Cron (pg_cron)
- Next.js 16 server components
- TypeScript
View system
Medium system
Monthly Owner Summary Report
An automated month-end summary that rolls the key operating numbers — leads by source, conversion and booking rates, no-shows, workload, hygiene score, automation health — into one concise report an owner reads in two minutes, with month-over-month deltas. It reuses the suite's existing views and emits a stored snapshot (and optional emailed digest) so each month is comparable and archived. The connective report that ties the individual dashboards into a single recurring read.
- Timeline
- 5 to 9 days
- Fallback
- Defined
- Supabase Postgres
- Supabase Cron (pg_cron)
- monitoring_reports snapshot pattern
- Resend
- Next.js 16 server components
View system
Medium system
No-Show Review View
A focused review view dedicated to no-shows and last-minute cancellations — who didn't show, the source/owner/time-slot patterns behind no-shows, reminder-sent vs no-show correlation, and a recovery worklist of no-shows to re-engage — so no-shows become a managed, reducible problem rather than a write-off. It deep-dives the no-show slice of the booking data. A specialized analysis + worklist, distinct from the broader booking status report.
- Timeline
- 4 to 7 days
- Fallback
- Defined
- Supabase Postgres
- Cal.com webhooks
- SQL (cross-tab / breakdown)
- Next.js 16 server components
View system
Low system
Owner Workload Distribution View
A workload view that shows how open leads, tasks, and follow-ups are distributed across owners — counts per owner, overdue items per owner, and load balance vs the team average — so routing isn't quietly dumping everything on one person. It reads CRM ownership and due-date fields to surface who is overloaded and who has capacity. This is a capacity-and-fairness lens, not a routing engine.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Supabase Postgres
- SQL aggregation
- Next.js 16 server components
- TypeScript
View system
Medium system
Pipeline Aging Board
A stage-by-stage aging board that shows how long each open lead has been sitting in its current pipeline stage, with buckets (0-2 days, 3-7, 8-14, 14+) and per-stage medians, so stale deals stop hiding in a flat list. It computes time-in-stage from CRM status/stage-change timestamps and surfaces the oldest untouched leads first. The point is an action queue for follow-up, not a vanity funnel chart.
- Timeline
- 4 to 7 days
- Fallback
- Defined
- Supabase Postgres
- Postgres triggers
- SQL window functions
- Next.js 16 server components
- TypeScript
View system
Low system
Subscriber & Waitlist Analytics Board
An analytics board for the newsletter/waitlist audience — net subscriber growth, new vs unsubscribed per period, source of signups, and confirmation/active rate — so list health is tracked as a curve, not a single ever-growing vanity count. It reads the subscribers table (subscribed_at, status, source) and frames growth honestly including churn. Reporting over the existing subscribe flow; it does not send campaigns.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Supabase Postgres
- subscribers table
- SQL aggregation
- Next.js 16 server components
View system
Low system
Support Queue Report
A queue-health report over inbound support/enquiry items — open vs resolved, age of the oldest open item, first-response and resolution time, and backlog trend — so the team sees whether the queue is keeping up or quietly growing. It reads ticket/enquiry rows (status, created_at, first_response_at, resolved_at) and frames the queue as a backlog to drain. Measurement layer over the queue, not a helpdesk or ticketing engine.
- Timeline
- 3 to 6 days
- Fallback
- Defined
- Supabase Postgres
- SQL (queue metrics)
- Next.js 16 server components
- TypeScript
View system
02 // Operating path
With the fallback visible
- 01Sources read
- 02Definitions checked
- 03Metric refreshed
- 04Action queued