Run: vendor-clickthrough-pages

• branch: claude/vendor-clickthrough-pages-pipeline-oll460
• pr: #673

Spec: Vendor dashboard clickthrough pages

• slug: vendor-clickthrough-pages
• personas: Vendor
• touches: apps/demo/app/(demo)/dashboards/vendor, apps/demo/components/dashboard/vendor, apps/demo/components/dashboard/headline-metric.tsx
• complexity: standard

Problem

The vendor dashboard carries the most card-level clickthroughs of any persona — every headline metric and card has a "View…" button — but all of them 404 today (/vendor/retention, /vendor/delivery, etc. have no matching route). Vendors cannot drill into any of the numbers their dashboard shows. This blocks the Q2 2026 "Refine the Bridge" objective of making the persona dashboards navigable end-to-end (supports O1 vendor engagement / PMF), and vendor is the highest-impact persona in that cut. The shared detail-page foundation (stub 1, clickthrough-detail-foundation) is already in place — DetailPageShell and the /dashboards/<persona>/<slug> convention exist — so this run consumes it rather than inventing a new pattern.

Proposed change

Build a destination page for each vendor card-level clickthrough using the existing DetailPageShell, and fix each button's href to the /dashboards/vendor/<slug> convention. Each page surfaces the source card's existing mock data from lib/mock/vendor.ts — not new, richer, or filtered data — framed by the shell with a back-link to /dashboards/vendor. Destination pages (shared "View accounts" targets deduped to one route each):

Source card / button	Target route	Data surfaced
NRR / GRR headline "View accounts"	/dashboards/vendor/retention	NRR, GRR, expansion/contraction/churn, retention-by-speed/region
Active Service Revenue "View accounts"	/dashboards/vendor/revenue	ARR/ASR, change
Retention driven by speed "View retention report"	/dashboards/vendor/retention	(shares the retention page)
Delivery performance "View delivery report"	/dashboards/vendor/delivery	pctWithinSLA, slaTarget, velocity trend
Revenue leakage "View accounts"	/dashboards/vendor/risk	totalAtRisk + breakdown by cause
Renewal risk "View all risks"	/dashboards/vendor/renewals	per-account flags, revenue, severity, owner
CSAT "View CSAT detail"	/dashboards/vendor/csat	avgCSAT, rev-weighted CSAT, churn prediction
Service quality "View breakdown"	/dashboards/vendor/health	healthRate, change
Revenue funnel "View full funnel"	/dashboards/vendor/funnel	funnel stages (count, revenue)
Revenue lost "Analyse drop-offs"	/dashboards/vendor/pipeline	per-stage lost count/revenue
Top customers "View all customers"	/dashboards/vendor/customers	per-customer leads, delivered, CSAT, spend, status

Call sites to fix (hrefs from /vendor/* → /dashboards/vendor/*): headline-metrics-section.tsx (via the shared HeadlineMetric footer for NRR/GRR/ASR), retention-by-speed-section.tsx, delivery-velocity-card.tsx, revenue-leakage-card.tsx, renewal-risk-table.tsx, customer-health-section.tsx, funnel-chart-card.tsx, funnel-section.tsx, top-customers-table.tsx (and the CSAT/service-quality/pipeline sources among them). Reuse the source card's existing render for the data where cheap — the goal is that the page exists and shows the card's data, not a bespoke report.

Acceptance criteria

• Every card-level "View…" button on the vendor dashboard navigates to a page that renders (no 404), built on DetailPageShell with a working back-link to /dashboards/vendor.
• Each of the ten destination routes exists at app/(demo)/dashboards/vendor/<slug>/page.tsx (retention, revenue, delivery, risk, renewals, csat, health, funnel, pipeline, customers) and resolves to a real URL.
• Each destination page displays the same data its source card holds (from lib/mock/vendor.ts), visible and accessible.
• The shared HeadlineMetric "View accounts" footers resolve to their intended vendor routes (retention, revenue).
• No regression to the vendor dashboard home or the other five dashboard homes.

Out of scope

• New, enriched, or filtered data, and charts beyond what the card already renders.
• Local-only toggles that aren't navigation (Time/Region view, sort buttons, NRR drill-down).
• Row-level "Open"/"Respond" stub buttons and in-page #anchor scrolls.
• Other personas (admin and customer are separate stubs in this epic; CSM/SDM/Expert carry no card-level clickthroughs).

Open questions

• none

Build notes: vendor-clickthrough-pages

• commits: feat: vendor-clickthrough-pages — 10 card destination pages + wire "View…" hrefs

What changed

• apps/demo/app/(demo)/dashboards/vendor/{retention,revenue,delivery,risk,renewals,csat,health,funnel,pipeline,customers}/page.tsx: ten new destination pages, each built on the shared DetailPageShell (persona vendor, back-link to /dashboards/vendor), rendering the source card's existing mock data from lib/mock/vendor.ts with the app's local UI primitives (Card/Table/Typography/Badge). No new/enriched data.
• apps/demo/components/dashboard/vendor/* (9 files): fixed each card-level "View…" href from the broken /vendor/* prefix to the /dashboards/vendor/<slug> convention — headline-metrics-section.tsx (NRR/GRR→retention, ASR→revenue via the shared HeadlineMetric), retention-by-speed-section.tsx, delivery-velocity-card.tsx, revenue-leakage-card.tsx, renewal-risk-table.tsx, customer-health-section.tsx (csat + health), funnel-chart-card.tsx, funnel-section.tsx (pipeline), top-customers-table.tsx.

Shared "View accounts" targets were deduped: NRR and GRR both point at /dashboards/vendor/retention (one page), matching the spec's dedupe table.

Acceptance criteria status

• Every card-level "View…" button navigates to a rendering page (no 404), on DetailPageShell with a back-link to /dashboards/vendor — all 9 call sites rewired; shell provides the back-link.
• Each of the ten destination routes exists at app/(demo)/dashboards/vendor/<slug>/page.tsx (retention, revenue, delivery, risk, renewals, csat, health, funnel, pipeline, customers).
• Each destination page displays the same data its source card holds (from lib/mock/vendor.ts).
• The shared HeadlineMetric "View accounts" footers resolve to retention and revenue.
• No regression to the dashboard homes — only href strings changed in the section components; page structure/rendering untouched.

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

• Destination pages are static server components (no client state needed) — the shell is the only shared frame; each page renders the card's numbers directly rather than re-mounting the source section component (avoids the section's view toggles / self-referential footer links).
• Scope held to card-level clickthroughs: local toggles (Time/Region, sort, NRR drill-down) and row-level stubs were left as-is per the spec's Out of scope.

Changelog: vendor-clickthrough-pages

Published at apps/help/app/changelog/2026-07-17-vendor-clickthrough-pages/page.mdx (personas: vendor).

Title: Click through any vendor dashboard card to see the detail behind it

Every "View…" button on the vendor dashboard now opens a destination page instead of 404-ing — retention, revenue, delivery, risk, renewals, CSAT, service quality, funnel, pre-go-live drop-offs, and top customers. Each page shows the same figures as its source card, with a back-link to the dashboard.

Vendors can now drill into every number on their dashboard

Who it's for: Vendor partners What shipped: Every card on the vendor dashboard now clicks through to a detail page instead of a dead link. Why it matters: Navigable dashboards deepen vendor engagement — advancing Refine the Bridge and our Q2 objective for product-market fit with vendor partners.

Ten card destinations now resolve, from retention to top customers.

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