Dashboards & Analytics · Onboarding

Paid-Invoice to Onboarding Visibility View

A view that shows every paid client and where they are between payment and onboarding completion, so nobody who paid slips through the cracks waiting to be started.

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

Built with real HMX dashboard tool paths

Supabase PostgresSQL view (payment-to-milestone join)Next.js 16 server componentsMetabase (read-only BI)Vercel hostingSupabase PostgresSQL view (payment-to-milestone join)Next.js 16 server componentsMetabase (read-only BI)Vercel hosting

01 // Outcomes

Outcome signals

Every
paid client visible against onboarding stage
Wait time
since payment computed for the unstarted
Oldest-first
list so nobody waits unnoticed
Flagged
paid clients with no onboarding record

Case architecture

Paid-Invoice to Onboarding Architecture

6 nodes
where paid status and
the onboarding stages and
Supabase Postgres
SQL view
Review Queue
Dashboard Action
  1. 01where paid status and

    A view that shows every paid client and where they are between payment and onboarding completion, so nobody who paid slips through the cracks waiti...

  2. 02the onboarding stages and

    Define the onboarding stages and the 'waiting too long after payment' threshold.

  3. 03Supabase Postgres

    Supabase Postgres contributes the trusted model for Paid-Invoice to Onboarding so metrics are defined before they are visualized.

  4. 04SQL view

    Build a view returning time-since-payment and current onboarding stage for each paid client.

  5. 05Review Queue

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

  6. 06Dashboard Action

    Every paid client visible against onboarding stage; Wait time since payment computed for the unstarted; Oldest-first list so nobody waits unnoticed...

Problem

The operating gap

A client pays and then waits — the handoff from 'invoice paid' to 'onboarding started' has no shared view, so someone occasionally pays and sits unstarted for days because everyone assumed someone else picked it up.

Build

What gets built

A read-only view that joins paid status against onboarding milestones, computes time-since-payment for anyone not yet onboarded, and lists the waiting clients oldest-first. It reports the gap between payment and onboarding; it does not run the onboarding itself.

Build steps

How it ships

Paid-Invoice to Onboarding Visibility View uses a reporting model and review layer for Dashboards. A view that shows every paid client and where they are between payment and onboarding completion, so nobody who paid slips through the cracks waiti... The architecture connects where paid status and, supabase postgres, sql view, and dashboard action with an explicit control path.

  1. 01Confirm where paid status and onboarding milestone timestamps live and how they relate per client.
  2. 02Define the onboarding stages and the 'waiting too long after payment' threshold.
  3. 03Build a view returning time-since-payment and current onboarding stage for each paid client.
  4. 04Render a 'paid but not yet onboarded' list sorted by wait time, plus a stage summary.
  5. 05Flag any paid client with no onboarding record at all as the highest-priority gap.
  6. 06Document the stages and threshold so the handoff has a shared definition.

Stack

Tools and layers

  • Supabase Postgres
  • SQL view (payment-to-milestone join)
  • Next.js 16 server components
  • Metabase (read-only BI)
  • Vercel hosting
  • Inputs layer: Confirm where paid status and onboarding milestone timestamps live and how they relate per client.
  • Transform layer: Define the onboarding stages and the 'waiting too long after payment' threshold.
  • Metrics layer: Supabase Postgres contributes the trusted model for Paid-Invoice to Onboarding so metrics are defined before they are visualized.
  • Visualization layer: SQL view (payment-to-milestone join) handles refresh, review, or reporting delivery while a read-only view that joins paid status against onboarding milestones, computes time-since-payment for anyone not yet onboarded, and lists the wait...
  • Action layer: Every paid client visible against onboarding stage; Wait time since payment computed for the unstarted; Oldest-first list so nobody waits unnoticed...

Data flow

  1. 01Confirm where paid status and onboarding milestone timestamps live and how they relate per client.
  2. 02Define the onboarding stages and the 'waiting too long after payment' threshold.
  3. 03Build a view returning time-since-payment and current onboarding stage for each paid client.
  4. 04Render a 'paid but not yet onboarded' list sorted by wait time, plus a stage summary.
  5. 05Flag any paid client with no onboarding record at all as the highest-priority gap.
  6. 06Document the stages and threshold so the handoff has a shared definition.

Controls

  • A client pays and then waits — the handoff from 'invoice paid' to 'onboarding started' has no shared view, so someone occasionally pays and sits un...
  • A read-only view that joins paid status against onboarding milestones, computes time-since-payment for anyone not yet onboarded, and lists the wait...
  • When automation confidence is low, route the record to a manual owner with the source, stage, and last action attached.

Research basis