Track repair list adoption by inspector

Objective

• Measure repair-list adoption by inspector so tablet/repair-list pilot rollouts can be evaluated per person, not only at company or market level.
• Near-term (v1): Add multi-select inspector filtering to the Post-Inspection Revenue admin dashboard so pilot cohorts can be reviewed together.
• Longer-term: Surface which inspectors are succeeding with repair-list usage and which may need coaching or process support.

Background

• The team is piloting tablets and repair-list workflows with a subset of inspectors; the main blocker is knowing whether the pilot is working.
• They want to connect inspector → inspection → repair-list creation so adoption can be analyzed by person.
• A near-term path discussed was reporting first, before a full dedicated dashboard — specifically a multi-select inspector filter on Post-Inspection Revenue so several participating inspectors can be compared during the pilot.
• Longer term: broader visibility into inspector-level success and coaching needs.
• Triage verdict: Feature gap — company/date-level adoption reporting exists; inspector-level grouping and filtering do not.
• The Post-Inspection Revenue dashboard (shipped via ATT-1670) reports ProPair funnel metrics (eligible inspections → repair lists → quotes) filtered by company + date only.

Scope

Frontend (attik-frontend) — Admin

• Post-Inspection Revenue page: src/app/admin/post-inspection-revenue/PostInspectionRevenueClient.tsx — loads propair-adoption and concierge-adoption with companyIds, startDate, endDate only.
• Shared filters: src/app/admin/_components/DashboardHeader.tsx — company + timeframe; no inspector filter today.
• ProPair section: src/app/admin/post-inspection-revenue/_components/PropairAdoptionSection.tsx — displays aggregated funnel/chart data.

Backend (attik-backend)

• Adoption API: src/routes/adminPostInspectionRevenue.ts — GET /post-inspection-revenue/propair-adoption aggregates by date period ($dateToString on inspection datetime); joins repairlists on _inspectionId; filters propairEligible inspections; accepts companyIds, startDate, endDate, groupBy — no inspectorIds.
• Dashboard view: scripts/createCcDashboardViews.ts / cc_inspection_base — ProPair eligibility flags on inspections; _inspectorId not projected into the view today.
• Data join path exists: repairListSchema _inspectionId → inspectionSchema _inspectorId (array of assigned inspectors); repair lists also have optional createdBy (user id, not inspector id).
• Repair list creation: src/routes/repairList.ts POST / — PostHog event repair list created logs inspection_id and company_id, not inspector.

Out of scope (unless explicitly expanded)

• Client portal repair-list UX changes (see ATT-1847, ATT-1367).
• Tools-level inspector-facing repair-list UI (src/app/tools/inspections/repair-lists/) — separate from admin adoption reporting unless product asks for in-app inspector views in v1.
• Full coaching dashboard or automated outreach — longer-term follow-up beyond v1 filter/reporting.
• General repair-list admin lifecycle improvements (sample filtering, downstream actions) — see ATT-1384; link as related, not duplicate.

References

• Parent dashboard (done): ATT-1670 — Build post-inspection revenue dashboard in Attik Admin
• Related: ATT-1384 — Improve repair list admin visibility and tracking
• Backend entry: attik-backend/src/routes/adminPostInspectionRevenue.ts
• Frontend entry: attik-frontend/src/app/admin/post-inspection-revenue/PostInspectionRevenueClient.tsx

Decisions needed

1. v1 deliverable — Is v1 inspector multi-select filter on existing ProPair charts sufficient, or must v1 also include a per-inspector breakdown table (counts/rates by inspector name)?
2. Inspector attribution rule — When an inspection has multiple assigned inspectors (_inspectorId array), credit adoption to primary inspector only, all assigned inspectors, or inspector who created the repair list (createdBy user → employee mapping)?
3. Adoption metric definition — What counts as “adopted” for the pilot: repair list created, ≥1 repair item added, quote requested/submitted, or a combination?
4. Pilot cohort — Which brands/companies and inspector list define the initial pilot (Southwest/Southeast subset)? Should the filter default to that cohort or require manual selection each time?
5. Dashboard scope — Admin Post-Inspection Revenue only, or also expose inspector-level adoption in tools (market/ops users without admin access)?
6. Concierge section — Should inspector filtering apply to Concierge adoption on the same page, or ProPair/repair-list only in v1?
7. Relationship to ATT-1384 — Should inspector adoption live under ATT-1869 while ATT-1384 covers broader admin repair-list visibility, or merge scope?
8. Data model change — Add _inspectorId to cc_inspection_base view vs join at query time in the adoption aggregation?