Medium Dashboards 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.

Start a Project All Systems

4 to 7 days: timeline
Medium: complexity
4: tools
4: steps

Built with real HMX dashboard tool paths

Supabase PostgresSQL aggregationCRM activity/disposition fieldNext.js 16 server componentsSupabase PostgresSQL aggregationCRM activity/disposition fieldNext.js 16 server components

01 // System facts

System facts

Call Outcome Dashboard uses a reporting model and review layer for Dashboards. A dashboard that summarizes the outcomes of sales/discovery calls logged against leads — connected, voicemail, no-answer, booked-from-call, not-int... The architecture connects a structured disposition, supabase postgres, sql aggregation, and owner review with an explicit control path.

Outcome

Owners can see whether calls are connecting and converting, and which outcome patterns dominate — making call effort measurable and surfacing where follow-up timing or scripts need work.

Main risk

If dispositions are inconsistently logged (or skipped), the mix is biased toward whoever logs diligently, making cross-owner comparison unfair.

Prevention

Drive the dashboard from a controlled outcome field with a fixed vocabulary, show a 'logged vs total attempts' coverage number so under-logging is visible, and exclude unlabeled calls from rates rather than guessing.

Fallback

If structured dispositions don't exist yet, ship a minimal connected-vs-not view from whatever signal is reliable (e.g. booked-from-call), and recommend adding a disposition field as the prerequisite for the full mix.

System architecture

Call Outcome Dashboard Architecture

6 nodes

a structured disposition

SQL to aggregate call

Supabase Postgres

SQL aggregation

Review Queue

Owner Review

01a structured disposition
A dashboard that summarizes the outcomes of sales/discovery calls logged against leads — connected, voicemail, no-answer, booked-from-call, not-int...
02SQL to aggregate call
Write SQL to aggregate call outcomes by type, by owner, and by day, computing connect rate (connected / attempts) and booked-from-call rate.
03Supabase Postgres
Supabase Postgres contributes the trusted model for Call Outcome Dashboard so metrics are defined before they are visualized.
04SQL aggregation
Render an outcome dashboard (server component) with an outcome-mix bar, connect-rate trend, and a per-owner table; default to a rolling window with a date selector.
05Review Queue
If structured dispositions don't exist yet, ship a minimal connected-vs-not view from whatever signal is reliable (e.g.
06Owner Review
Owners can see whether calls are connecting and converting, and which outcome patterns dominate — making call effort measurable and surfacing where...

How it is built

Build steps

01Confirm a structured disposition exists: ensure call outcomes are captured as a controlled field/tag on the lead or an activity row (not just freeform notes); if needed, define the allowed outcome set with the owner.
02Write SQL to aggregate call outcomes by type, by owner, and by day, computing connect rate (connected / attempts) and booked-from-call rate.
03Render an outcome dashboard (server component) with an outcome-mix bar, connect-rate trend, and a per-owner table; default to a rolling window with a date selector.
04Add a 'low connect rate' or 'high no-answer' flag per owner/day so coaching opportunities surface rather than being buried in totals.

Tools

Workflow surface

Supabase Postgres
SQL aggregation
CRM activity/disposition field
Next.js 16 server components

Inputs layer: Confirm a structured disposition exists: ensure call outcomes are captured as a controlled field/tag on the lead or an activity row (not just freeform notes); if needed, define the allowed outcome set with the owner.
Transform layer: Write SQL to aggregate call outcomes by type, by owner, and by day, computing connect rate (connected / attempts) and booked-from-call rate.
Metrics layer: Supabase Postgres contributes the trusted model for Call Outcome Dashboard so metrics are defined before they are visualized.
Visualization layer: SQL aggregation handles refresh, review, or reporting delivery while drive the dashboard from a controlled outcome field with a fixed vocabulary, show a 'logged vs total attempts' coverage number so under-logging is...
Action layer: Owners can see whether calls are connecting and converting, and which outcome patterns dominate — making call effort measurable and surfacing where...

Data flow

01Confirm a structured disposition exists: ensure call outcomes are captured as a controlled field/tag on the lead or an activity row (not just freeform notes); if needed, define the allowed outcome set with the owner.
02Write SQL to aggregate call outcomes by type, by owner, and by day, computing connect rate (connected / attempts) and booked-from-call rate.
03Render an outcome dashboard (server component) with an outcome-mix bar, connect-rate trend, and a per-owner table; default to a rolling window with a date selector.
04Add a 'low connect rate' or 'high no-answer' flag per owner/day so coaching opportunities surface rather than being buried in totals.

Controls and fallbacks

If dispositions are inconsistently logged (or skipped), the mix is biased toward whoever logs diligently, making cross-owner comparison unfair.
Drive the dashboard from a controlled outcome field with a fixed vocabulary, show a 'logged vs total attempts' coverage number so under-logging is...
If structured dispositions don't exist yet, ship a minimal connected-vs-not view from whatever signal is reliable (e.g.

Research basis