Rider Management owns the rider side of the marketplace lifecycle. It answers “who is this rider, can they request a ride right now, what do they prefer, and are they trustworthy enough for drivers to keep accepting their requests?” It is the smallest viable identity surface — phone-verified with a validated payment method — kept deliberately frictionless at signup, then progressively hardened by ratings and a human-reviewed ban policy. The ubiquitous language — Rider, VerificationCode, SavedAddress, AccessibilityPreference, AverageRiderRating, Appeal — is shared with the system requirements and domain model.

Product statement

Vision. Rider onboarding is the first impression — and the first place trust is either won or lost. RideNow keeps the path from install to first ride as short as possible without creating a soft target for fraud or abuse: a phone-verified rider with a validated payment method can request a ride within two minutes, and a chronically disruptive rider faces a transparent, appealable ban policy that a real operator signs off on.

Scope. Phone-based rider signup with one-time-code verification, brute-force lockout, payment-method association via the Payment context, saved addresses and accessibility preferences, rider ratings recorded from RideCompleted events, automatic warning and ban-proposal generation on sustained low ratings, operator-driven ban decisions, and a 30-day appeal window with an SLA-bound resolution.

Non-goals. Government-ID collection at signup (only triggered later by risk signals — see open question), full profile capture before the first ride, automatic ban without human review, public exposure of rider ratings.

Problem statement (SCQ)

  • Situation. New riders need the shortest possible path from install to first ride. Drivers need protection from chronically abusive or disruptive riders — a one-sided rating system favors riders structurally and pushes drivers off the platform. Trust and safety operators need every ban proposal to come with the full evidence trail and a published appeal process.
  • Complication. Heavy upfront identity verification depresses signup conversion and pushes price-sensitive riders to competitors; verifying nobody invites fraud, payment abuse, and unsafe rider behaviour. Ratings are noisy — a single bad day for a rider can produce one unfair 1-star, and an algorithmic auto-ban on that basis would be both unjust and a regulatory landmine. GDPR demands the rider can correct or erase personal data on demand, and ban decisions must remain auditable for years.
  • Question. How do we keep signup frictionless enough to win the install, harden the profile only when risk signals warrant it, and run a rider rating and ban policy that drivers trust, riders can appeal, and regulators can audit?

Personas & jobs

  • Daily commuter rider (primary). Jobs: “sign up in under two minutes with phone and a card”, “request a commute ride in one tap from a saved Home/Work address”, “set my accessibility preference once and have every ride honour it”. Frustrations addressed: long signup forms, retyping the same destination every morning. Source journey: Commuter morning ride — Step 1 is “Rider opens the RideNow app and taps Work”, which only works if signup, saved addresses, and a default payment method are already in place.
  • Occasional traveler rider (primary). Jobs: “sign up only when I need a ride, without a long form”, “trust that my account is real enough that drivers will pick me up”. Frustrations addressed: friction in low-frequency use, the awkwardness of a new account at a busy pickup.
  • Trust and safety operator (secondary). Jobs: “review ban proposals with full context — every rating below threshold with driver comment and ride reference”, “apply the ban policy consistently and within SLA”, “preserve a multi-year audit trail of every decision and appeal”. Frustrations addressed: scattered context across tools, manual chasing of ride history and prior incidents.

Features, stories & acceptance criteria

Feature: frictionless rider signup

Problem addressed: signup friction is the largest install-to-first-ride drop; identity verification at signup is a non-goal until risk signals warrant it.

  • Story — Sign up with phone number and payment method. “As a daily commuter rider, I want to sign up with my phone number and a payment method, so that I can request my first ride without filling a long form.”
    • AC: When a person signs up with a phone number, the system creates a rider profile and sends a one-time verification code to that phone number. (REQ-RDR-001)
    • AC: When the rider submits the correct code, the phone is marked verified and a RiderPhoneVerified event is published. (REQ-RDR-002)
    • AC: If the rider submits an incorrect code three times in a row, verification attempts on that phone number are locked for 15 minutes. (REQ-RDR-003)
    • AC: The system does not require a government-issued identity document at signup. (REQ-RDR-004)
    • AC: The system prevents a rider from requesting a ride unless the rider has a verified phone and at least one active payment method. (REQ-RDR-005)
    • AC: When a rider adds a payment method, the system requests validation from the Payment context and associates the method with the rider profile only if validation succeeds. (REQ-RDR-006)

Feature: saved addresses and preferences

Problem addressed: daily commuters retype the same destination every morning; accessibility needs must be honoured across every ride without re-entering them per-trip.

  • Story — Save Home and Work addresses. “As a daily commuter rider, I want to save Home and Work addresses, so that I can request a commute ride in one tap.”
    • AC: When a rider saves an address, the system stores it with a label on the rider profile. (REQ-RDR-010)
    • AC: When a rider edits or deletes a saved address, the change is applied to the profile immediately. (REQ-RDR-011)
    • AC: Saved addresses are exposed to the rider app such that selecting one as a destination requires a single tap from the home screen. (REQ-RDR-012)
  • Story — Accessibility preference travels with the rider. (platform-driven)
    • AC: When a rider sets an accessibility preference on their profile, the preference is propagated to subsequent ride requests. (REQ-RDR-013)

Feature: rider rating and ban policy

Problem addressed: drivers need protection from chronically abusive riders; rider-side bans must be appealable and human-reviewed; regulators may audit ban policy enforcement.

  • Story — Driver rates the rider after a completed ride. (platform-driven, fed by RideCompleted from Ride Management)
    • AC: When a driver submits a rating and optional comment for a completed ride, the system records the rating and recomputes the rider’s average rating. (REQ-RDR-020)
    • AC: The system accepts ratings only in the integer range one through five inclusive. (REQ-RDR-021)
  • Story — Warn before banning. (platform-driven)
    • AC: While the rider has completed more than 10 rides, if the rider’s average rating drops below 4.0, the system sends the rider a warning notification with the rating threshold and ban policy. (REQ-RDR-022)
  • Story — Review banned-rider proposals with full context. “As a trust and safety operator, I want to review banned-rider proposals with full context, so that I can apply the policy consistently.”
    • AC: While the rider has completed more than 10 rides, if the rider’s average rating drops below 3.5, the system creates a ban proposal in the operator review queue listing every rating below threshold with driver comment and ride reference. (REQ-RDR-023)
    • AC: When an operator resolves a ban proposal, the system applies the decision, records it with operator identity, reason, and timestamp, and notifies the rider. (REQ-RDR-024)
    • AC: When a banned rider submits an appeal within 30 days, the system records the appeal and places it in the operator review queue. (REQ-RDR-025)
    • AC: The system delivers an operator decision on the appeal to the rider within 5 business days. (REQ-RDR-026)
    • AC: If the rider submits an appeal more than 30 days after the ban, the appeal is rejected as out of window and the rider is notified. (REQ-RDR-027)

Goals & success metrics

  • Reduce rider wait time and abandonment — the product-level goal “In every served market, the time from ride request to confirmed driver is under 30 seconds at p50… and the fare-reveal abandonment rate is under 10%”. Rider Management contributes by removing signup friction (REQ-RDR-001–REQ-RDR-006) and by delivering one-tap saved-destination selection (REQ-RDR-012).
  • Establish safety and trust baseline — the product-level goal “Every driver onboarded is identity-verified before the first ride. Emergency reports are acknowledged… and resolved with a complete audit trail”. Rider Management contributes the rider half: warning and ban-proposal automation (REQ-RDR-022, REQ-RDR-023), operator-driven ban decisions (REQ-RDR-024), and the 7-year audit trail of every ban and appeal (REQ-RDR-NFR-004).
  • Signup success rate ≥ 99.5% monthly. (REQ-RDR-NFR-003) — telephony-provider failures excluded. Outages in this funnel cost installs irrecoverably.
  • PII encrypted at rest with at least AES-256. (REQ-RDR-NFR-001) — phone numbers, saved addresses, and ratings are personal data.
  • GDPR right to erasure honoured within 30 days. (REQ-RDR-NFR-002) — coordinated with other contexts; only records under documented regulatory retention obligation are kept.
  • Append-only audit log of every ban and appeal decision retained for ≥ 7 years. (REQ-RDR-NFR-004) — driver-safety regulators may audit ban policy enforcement.
  • Ban appeal SLA ≤ 5 business days at p95. (REQ-RDR-026) — drift on this number erodes the perceived fairness of the policy faster than any other metric.

Constraints

  • Regulatory — GDPR and equivalents. Personal data of riders must be handled under GDPR (EU), CCPA (California), and equivalent regimes in every market — including right to access, correction, erasure, and data minimization. Source: PRD constraint “GDPR and equivalent privacy regimes”. Constrains Frictionless rider signup, saved-address storage, and the rating/ban audit trail.
  • Regulatory — PCI-DSS for payment-method association. Any payment data flowing through REQ-RDR-006 must remain PCI-DSS Level 1 compliant. The actual card storage lives in the Payment context; the association call from Rider Management never persists card numbers locally.
  • Operational — human review required for bans. Algorithmic auto-ban is a non-goal: every ban decision is operator-driven (REQ-RDR-024) and recorded in the append-only audit log (REQ-RDR-NFR-004). Warning (REQ-RDR-022) and ban-proposal creation (REQ-RDR-023) may be automated; the ban itself may not.
  • Open question — rider identity verification threshold. The PRD leaves open when a rider should be required to submit identity for verification: at signup, after a risk signal, or never. The current scope is “after a risk signal” and signup explicitly excludes government-ID collection (REQ-RDR-004); the policy decision is owned by Trust and Safety with deadline 2026-07-01 and may add new requirements to this context.

Traceability. Every feature above references REQ-RDR-… identifiers formalized in the System Requirements page. Those requirements become enums, value types, the Rider aggregate, the RiderLifecycle state machine, domain and infrastructure services, commands, events, and reactions in the Domain Model page. Cross-context bridges: the RideCompleted event from Ride Management feeds rider-rating ingestion (REQ-RDR-020); PaymentMethodValidated from the Payment context completes the validation handshake started by REQ-RDR-006.