Dashboards & Analytics · Pipeline Aging

Pipeline Stage Aging Report That Surfaces Stuck Deals

An aging report that shows how long each lead has sat in its current stage so owners can see what is going stale before it dies quietly.

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

Built with real HMX dashboard tool paths

Supabase PostgresSQL view (age bucketing)Next.js 16 server componentsMetabase (read-only BI)Vercel hostingSupabase PostgresSQL view (age bucketing)Next.js 16 server componentsMetabase (read-only BI)Vercel hosting

01 // Outcomes

Outcome signals

Days-in-stage
computed for every open lead
Stuck deals
ranked oldest-first by owner
Shared
fresh/aging/stale thresholds agreed up front
Earlier
catch on stalls before leads go cold

Case architecture

Pipeline Stage Aging Report That Architecture

6 nodes
which timestamp marks stage
aging thresholds per stage
Supabase Postgres
SQL view
Review Queue
Owner Review
  1. 01which timestamp marks stage

    An aging report that shows how long each lead has sat in its current stage so owners can see what is going stale before it dies quietly.

  2. 02aging thresholds per stage

    Define aging thresholds per stage with the operator (a discovery call ages faster than a proposal).

  3. 03Supabase Postgres

    Supabase Postgres contributes the trusted model for Pipeline Stage Aging Report That so metrics are defined before they are visualized.

  4. 04SQL view

    Build a view that returns days-in-stage, an age bucket, owner, and last-activity for every open lead.

  5. 05Review Queue

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

  6. 06Owner Review

    Days-in-stage computed for every open lead; Stuck deals ranked oldest-first by owner; Shared fresh/aging/stale thresholds agreed up front; Earlier...

Problem

The operating gap

Deals stall in a stage for weeks and nobody notices until the lead is cold; the CRM shows a current stage but not how long it has been there, so 'stuck' is invisible until it is too late.

Build

What gets built

A reporting view that computes days-in-current-stage from the stage timestamp, buckets leads into fresh / aging / stale thresholds per stage, and lists the oldest offenders by owner. It is a read-only analytics surface that reads the existing stage and timestamp fields — it does not change the pipeline itself.

Build steps

How it ships

Pipeline Stage Aging Report That Surfaces Stuck Deals uses a reporting model and review layer for Dashboards. An aging report that shows how long each lead has sat in its current stage so owners can see what is going stale before it dies quietly. The architecture connects which timestamp marks stage, supabase postgres, sql view, and owner review with an explicit control path.

  1. 01Confirm which timestamp marks stage entry and whether stage-change history is available or needs a derived 'last moved' field.
  2. 02Define aging thresholds per stage with the operator (a discovery call ages faster than a proposal).
  3. 03Build a view that returns days-in-stage, an age bucket, owner, and last-activity for every open lead.
  4. 04Render an 'oldest stuck deals' table sorted by age, grouped by stage and owner.
  5. 05Add a small stage-by-stage summary (count fresh vs aging vs stale) for the top of the report.
  6. 06Document the thresholds so the buckets are a shared definition, not a personal opinion.

Stack

Tools and layers

  • Supabase Postgres
  • SQL view (age bucketing)
  • Next.js 16 server components
  • Metabase (read-only BI)
  • Vercel hosting
  • Inputs layer: Confirm which timestamp marks stage entry and whether stage-change history is available or needs a derived 'last moved' field.
  • Transform layer: Define aging thresholds per stage with the operator (a discovery call ages faster than a proposal).
  • Metrics layer: Supabase Postgres contributes the trusted model for Pipeline Stage Aging Report That so metrics are defined before they are visualized.
  • Visualization layer: SQL view (age bucketing) handles refresh, review, or reporting delivery while a reporting view that computes days-in-current-stage from the stage timestamp, buckets leads into fresh / aging / stale thresholds per stage, and l...
  • Action layer: Days-in-stage computed for every open lead; Stuck deals ranked oldest-first by owner; Shared fresh/aging/stale thresholds agreed up front; Earlier...

Data flow

  1. 01Confirm which timestamp marks stage entry and whether stage-change history is available or needs a derived 'last moved' field.
  2. 02Define aging thresholds per stage with the operator (a discovery call ages faster than a proposal).
  3. 03Build a view that returns days-in-stage, an age bucket, owner, and last-activity for every open lead.
  4. 04Render an 'oldest stuck deals' table sorted by age, grouped by stage and owner.
  5. 05Add a small stage-by-stage summary (count fresh vs aging vs stale) for the top of the report.
  6. 06Document the thresholds so the buckets are a shared definition, not a personal opinion.

Controls

  • Deals stall in a stage for weeks and nobody notices until the lead is cold; the CRM shows a current stage but not how long it has been there, so 's...
  • A reporting view that computes days-in-current-stage from the stage timestamp, buckets leads into fresh / aging / stale thresholds per stage, and l...
  • When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

Research basis