Skip to Content

← All archived runs

Run: vendor-detail-parity

run.md

Run: vendor-detail-parity

  • branch: claude/vendor-detail-parity-pipeline-lz21pn
  • pr: #702

01_define/output/spec.md

Spec: Vendor detail-page parity

  • slug: vendor-detail-parity
  • personas: Vendor
  • touches: apps/web/app/(app)/vendor/{revenue,customers,pipeline,csat,retention,delivery}, apps/web/lib/route-policies.ts, packages/services/server (read-only)
  • complexity: standard

Problem

The vendor dashboard home is at parity with the demo app, but the vendor detail pages diverge — a gap in the Q2 2026 O1 objective (vendor engagement: vendor dashboard + reporting) under the "Refine the Bridge" initiative. Specifically: /vendor/revenue is missing entirely in web (demo shows ASR, a period selector, and revenue-by-delivery-stage); /vendor/customers shows a generic user-management table instead of demo's revenue-oriented "Top customers" view; and several demo cards were dropped from web — csat's "Forward retention risk", retention's "NRR movement" (expansion/contraction/churn), and delivery sub-metrics. The backing data is already loaded server-side (getRevenueFlow, getTopCustomers, getRevenueRetention, getRevenueRisk), so this is a UI/parity job, not a new-data job.

Proposed change

Bring the vendor detail pages to demo parity, all on the shared DetailPageShell + heading standard:

  • Build /vendor/revenue (new page) rendering ASR, a "Change this period" selector, and "Revenue by delivery stage", sourced from the existing getRevenueFlow; add its route-policies.ts entry.
  • Replace /vendor/customers content with demo's "Top customers" table (leads / delivered / CSAT / rev-weighted CSAT / spend / at-risk), sourced from getTopCustomers.
  • Restore the dropped cards: csat "Forward retention risk" churn-prediction card and retention "NRR movement" (expansion / contraction / churn) card.
  • Reconcile /vendor/delivery sub-metrics to demo (SLA target, Avg BRD-to-delivery, and the velocity-trend table).
  • Leave /vendor/pipeline content as-is — web's "Pipeline drop-offs" is retained as an intentional web view (owner decision, see Out of scope); only confirm it uses the shared shell + heading standard.

Acceptance criteria

  • /vendor/revenue exists, renders ASR + a "Change this period" selector + "Revenue by delivery stage", and has a route-policies.ts entry gated to the Vendor persona.
  • /vendor/customers shows demo's "Top customers" table with columns leads, delivered, CSAT, rev-weighted CSAT, spend, and at-risk (sourced from getTopCustomers) — the generic user-management table is gone.
  • csat "Forward retention risk" churn-prediction card is restored on /vendor/csat.
  • retention "NRR movement" card showing expansion / contraction / churn is restored on /vendor/retention.
  • /vendor/delivery shows SLA target, Avg BRD-to-delivery, and the velocity-trend table, matching demo.
  • All six vendor detail pages (revenue, customers, pipeline, csat, retention, delivery) use the shared DetailPageShell and the heading standard.
  • /vendor/pipeline keeps its "Pipeline drop-offs" content (not replaced with demo's revenue-lost view).

Out of scope

  • The vendor dashboard home (already at parity).
  • The web-only customer detail page (vendor/customers/[id]) — left as-is unless it directly conflicts with the new Top-customers list.
  • Back-porting web's "Pipeline drop-offs" view into the demo app (a separate future item).
  • Any change to the demo app itself.
  • New service methods or data-model changes — all required data is already available server-side.

Open questions

  • none. The one content decision (/vendor/pipeline) is settled: keep web's "Pipeline drop-offs" and do not duplicate the "Revenue lost before go-live" card already shown on /vendor/funnel.

02_build/output/notes.md

Build notes: vendor-detail-parity

  • commits: feat: vendor-detail-parity — revenue page, top-customers, csat/retention/delivery parity

What changed

  • apps/web/app/(app)/vendor/revenue/page.tsx (new): the missing vendor Revenue detail page — ASR + "change this period" cards from getRevenueRetention, and a "Revenue by delivery stage" table from getRevenueFlow (arrMovementStrip). Uses the shared DetailPageShell, the standard tenant/range resolution, and the graceful .catch → null fallback the other detail pages use.
  • apps/web/lib/route-policies.ts: added the /vendor/revenue persona-surface entry (roles: vendor) so the deny-by-default proxy allows the new page.
  • apps/web/app/(app)/vendor/customers/page.tsx: replaced the generic user-management table (UsersTable role="customer") with demo's "Top customers" table sourced from getTopCustomers — leads, delivered, CSAT, rev-weighted CSAT, total spend, rev-awaiting-CSAT, and an at-risk/stable status badge.
  • apps/web/app/(app)/vendor/csat/page.tsx: restored the "Forward retention risk" churn-prediction card, sourced from churnPrediction on the getCustomerHealth read the page already performs (no new query).
  • apps/web/app/(app)/vendor/retention/page.tsx: restored the "NRR movement" card (expansion / contraction / churn) from the getRevenueRetention fields already loaded.
  • apps/web/app/(app)/vendor/delivery/page.tsx: reconciled the delivery sub-metrics to demo — a 3-card strip (% delivered within SLA · SLA target · Avg BRD-to-delivery) plus a "Velocity trend" table from velocityTrend; kept web's revenue-weighted TTV and the time-to-value distribution table as additional depth.

Acceptance criteria status

  • /vendor/revenue exists, renders ASR + change + revenue-by-stage, has a route-policy entry — new page + policy entry, data from getRevenueRetention/getRevenueFlow.
  • /vendor/customers shows demo's Top-customers table — getTopCustomers, all columns present; generic user table removed.
  • csat "Forward retention risk" card restored — from churnPrediction on getCustomerHealth.
  • retention "NRR movement" card restored — expansion/contraction/churn from getRevenueRetention.
  • /vendor/delivery shows SLA target, Avg BRD-to-delivery, velocity-trend table — reconciled to demo.
  • All six vendor detail pages use the shared DetailPageShell + heading standard — revenue/customers/pipeline/csat/retention/delivery all on DetailPageShell.
  • /vendor/pipeline keeps its "Pipeline drop-offs" content — left untouched per the Define decision.

Verify result

  • mechanical checks (format · lint · typecheck · build) run in CI + the Vercel preview, not here. Release reads them back from the PR's check runs. No check is expected to fail.

Notes for review

  • No new service methods or data-model changes — every page reads data already exposed by vendorService, as the spec anticipated.
  • Delivery is a superset of demo, not a literal mirror: it keeps web's revenue-weighted TTV and TTV-distribution table alongside the restored demo elements. Flag if strict visual parity (dropping the extras) is preferred.
  • /vendor/pipeline was deliberately not changed (owner decision to keep "Pipeline drop-offs").

03_release/output/changelog.md


title: Your vendor revenue, customers and delivery detail pages are all here date: 2026-07-27T12:20:00Z personas: [vendor] slug: vendor-detail-parity pr: https://github.com/sustentus/sustentus/pull/702

Your vendor revenue, customers and delivery detail pages are all here

Your vendor dashboard's detail pages now give you the full picture. There's a new revenue page showing your active service revenue, how it changed this period, and how it's spread across each delivery stage. Your customers page now leads with your top accounts by spend and revenue-weighted CSAT — leads, delivered work, satisfaction, and who's at risk — instead of a plain user list. Your satisfaction page shows the revenue likely to churn next period, retention breaks out expansion, contraction and churn, and delivery adds your SLA target, average time from BRD to delivery, and a month-by-month velocity trend. You can now open any of these from your dashboard and see the same detail you rely on across the board.

03_release/output/investor-update.md

Vendors now get full revenue, customer and delivery detail pages

Who it's for: Vendors What shipped: A new revenue detail page plus demo-parity customers, satisfaction, retention and delivery pages on the vendor dashboard. Why it matters: Deeper self-serve reporting keeps onboarded vendors engaged — the heart of Refine the Bridge's Q2 objective, establishing product-market fit with vendor partners.

All seven acceptance criteria met; no new data or infrastructure required.

Dig deeper: <merged-PR URL> · <changelog entry URL>