💡 Customer failed-trip feedback loop to instrument the north-star metric

[github-actions[bot]]

Summary

Add a one-tap "Wasn't there" / "Sold out when I arrived" customer feedback affordance on followed-vendor cards in the activity feed, and pipe the events into a vendor-level reliability signal that managers can review and that future confidence scoring can consume.

Market Signal

• The PRD's measurable outcomes section names failed-trip reduction as the platform's north-star differentiator and Guardrail: Inaccurate listing complaint rate stays near zero in first 90 days. There is currently no instrument to measure either metric from the customer side — the product is flying blind on its own primary KPI.
• Phase 2 of the PRD already commits to "Confidence score model and explainability views" and "Manager reliability analytics and quality controls". This proposal is the input data plane that those features depend on.
• Incumbents (Marketspread, ManageMyMarket, MarketWurks, Local Line) optimize for manager admin and vendor commerce — none expose customer-side outcome telemetry as a coordination input.

User Signal

• The PRD Journey 1 (Rachel) opens with "she's been burned twice in the last month" — the entire product hypothesis is that customers carry latent failed-trip frustration. Today they have nowhere to put it inside the app.
• epics.md Epic 7 implements activity feeds (FR32a–c) but no FR captures customer outcome reports. There is exactly one occurrence of "failed.trip" in the planning corpus and zero in the implemented epics.

Technical Opportunity

• Reuse the immutable audit log infrastructure shipped in Epic 8 (audit_log table, FR35–39): a customer outcome event is just another actor=customer, action_type=outcome_report row pointing at the vendor + market_day.
• Reuse the existing notification + activity-feed pipeline from Epic 7 to deliver a contextual "How did your visit go?" prompt the morning after a followed-vendor checkin the customer's location pinged near.
• Aggregate via a Postgres view → vendor reliability rollup, gated to manager dashboards (Epic 5) only — never publicly visible to customers in v1, to avoid weaponizing the signal before it's calibrated.
• Schema is two columns + an enum. Days of work, not weeks.

Assessment

Dimension	Score	Rationale
Feasibility	high	Reuses audit log, activity feed, and manager dashboard primitives that already shipped in Epics 5/7/8.
Impact	high	Without this, the platform cannot measure or improve its own north-star metric. Every Phase 2 feature (confidence score, reliability analytics, substitutions) depends on this data.
Urgency	high	Pilot markets are launching; if the first 90 days run without outcome telemetry, the team will have no quantitative case for the platform's value proposition at the end of pilot.

Adversarial Review

Strongest objection: "Customer outcome reports become a vendor harassment vector — disgruntled customers will mass-tag vendors as 'wasn't there' and damage livelihoods, especially on art-market segments where vendor relationships are fragile."

Rebuttal: Three mitigations stack: (1) outcome events are manager-visible only in v1, never customer-facing, so there is no public reputation surface to weaponize; (2) only customers who actually followed the vendor and whose check-in window matches a real market day can submit; (3) the vendor sees an aggregate "your reliability looks healthy / needs attention" signal, never individual reports — same pattern Uber uses for driver ratings. Public surfacing is a Phase 2 decision after calibration data exists.

Suggested Next Step

Run bmad-quick-spec to scope the minimum viable telemetry: event schema, prompt-trigger heuristic, and manager-dashboard rollup view. Defer reliability scoring algorithm to a follow-on spike once 4–6 weeks of pilot data are in hand.

---

Proposed by the BMAD Analyst (Mary) on 2026-04-07.
Workflow run