← projects

[Pipeline, Not Business]

Lead Processing Latency

How long a lead takes from checkout to SMS, e-mail and call center — exact p50/p95 per day, channel and event, and where leads get stuck.

● In productionProduct & FrontendCompany↑ Analytics Dashboards HubReactPostgresSQLMySQLTypeScript
01 /context

Every purchase, abandoned cart and refund becomes a lead event routed to SMS, e-mail and call-center platforms. Nobody could say whether that took seconds or hours.

02 /my role

Built the dashboard and its sync from the integration database, and defined the metrics with the operations team.

03 /problem

The old view averaged latencies, counted every event × channel pair (even ones never routed) and read sales tables — it measured the business, not the pipeline.

04 /how it works
  1. 01 · Reads only the integration DB

    The dashboard measures the pipeline and never touches sales tables.

  2. 02 · Finalized per channel

    Each channel has its own success status, and only routed event × channel pairs count. Otherwise refund events parked in WAITING for a channel that never processes them would look stuck forever.

  3. 03 · Exact percentiles

    Precomputed from a 24-bucket geometric histogram, never averaged across days — a percentile of percentiles isn't a percentile.

  4. 04 · Stuck, two readings

    “How much is stuck in total?” on the backlog panel; “how much got stuck in this period?” everywhere else.

  5. 05 · Time per stage

    A collapsible Gantt: platform → database and database → dispatch, each with its own percentile series.

05 /architecture
01
Integration DB
02
Sync (table × month)
03
Histogram percentiles
04
Stuck snapshot
05
Dashboard
06 /interactive demo

what you're seeing

Dots are lead events traveling from the integration database to each channel. Below: a latency histogram, percentiles per channel, the match rate, a tray of stuck pairs, a per-lead Gantt and the matrix of which event goes to which channel.

try this

  1. 1.Pause SMS: dots pile up as stuck and the match rate drops — then resume and they're delivered late.
  2. 2.Switch Events ⇄ Leads to see how much the unit changes the match rate.
  3. 3.Tap a dot to open that lead's Gantt; check the matrix — unrouted pairs never count as stuck.

real vs simplified

The definitions are the dashboard's (finalized per channel, routed pairs only, events vs leads, time per stage). Time is compressed and the traffic is synthetic.
[lab] loading demo…
07 /results
Showed that our own routing takes a few seconds; the slow stage was the gateway's post-sale webhooks, arriving minutes after their own timestamp.
A fixed US-only filter showed that a large share of historical errors came from leads outside the US.
08 /what broke and what I changed
  • ! brokeA card's p50 was several times the real value, and an early Gantt inverted which stage was slowest — all from aggregating percentiles.

    → changedHistogram-based percentiles everywhere.

  • ! brokeThe dashboard showed a green arrow during a four-day SMS outage, because every metric started after the hole.

    → changedAn ingestion alert that compares gateway orders with pipeline events.

09 /related