Ride Management is the central coordinator of RideNow. It owns the ride lifecycle end-to-end: a rider commits to an upfront fare, the system finds the closest eligible driver, the ride runs from pickup to dropoff, payment is captured, and a fair, symmetric cancellation policy applies on both sides. It also owns safety — emergency button, trip sharing, unusual-stop detection, and post-ride reports. It is the busiest cross-context surface in the platform: it queries Geolocation for proximity and ETAs, asks Payment for fare estimate, pre-auth, capture, refund, and fee charges, gates new rides on a Rider Management readiness check, and notifies Driver Management when a driver crosses a penalty threshold. The ubiquitous language — RideRequest, Ride, RideOffer, FareEstimate, FinalFare, EmergencyEvent, SafetyReport — is shared with the system requirements and domain model.

Product statement

Vision. A ride-hailing marketplace that connects urban riders with independent drivers in under a minute, with upfront fares, transparent driver earnings, and an operational safety net that works during and after every ride — launched market by market, not city by city.

Scope. Ride request with committed fare; driver matching with offer rotation; pickup-to-completion lifecycle with live tracking and ETA refresh; fair cancellation policy with published fees and driver penalties; safety tooling — trip sharing, emergency button, unusual-stop detection, post-ride safety reports.

Non-goals. Negotiable fares (pricing is algorithmic); rider picks a specific driver (matching is proximity-based); replacing local emergency services (we notify and share location, we do not dispatch); cash payments (cashless by design).

Problem statement (SCQ)

  • Situation. Urban riders and visitors need on-demand point-to-point transportation. Independent drivers earn a living by moving them. Both sides depend on a platform that finds matches fast, prices honestly, and keeps everyone safe.
  • Complication. Incumbents have eroded rider trust with surprise surge pricing, opaque cancellation fees, and no-shows. Drivers face shrinking take-home rates, unexplained deactivations, and slow payouts. Safety incidents remain frequent enough to be a first-order switching trigger. Regulators are actively pushing back on surge and on driver classification.
  • Question. How do we run the request → match → ride → pay loop with sub-minute matches, an upfront fare that is the fare charged, a symmetric cancellation policy that respects both sides’ time, and safety features auditable by third parties?

Personas & jobs

  • Daily commuter rider (primary). 3-8 km trips, 5-15 rides per week, price- and time-sensitive. Jobs: get a ride confirmed in seconds when running late; know the exact fare before committing; cancel without penalty if plans change before assignment.
  • Occasional traveler rider (primary). Airport, station, venue trips with luggage or a group. Jobs: meet the driver at a busy pickup point without confusion; feel safe when riding alone at night with live trip sharing and an emergency button.
  • Part-time driver (primary). 10-25 hours per week, supplementing primary income. Jobs: earn predictably during chosen hours with clear per-ride earnings; avoid fake requests and unsafe pickups.
  • Full-time driver (primary). 30+ hours per week, primary income. Jobs: protect rating from unfair complaints; see destination and earnings on every offer; understand exactly why any suspension happened.
  • Trust and safety operator (secondary). Internal ops specialist triaging incidents and suspensions. Jobs: resolve a safety incident with complete context — ride trace, chat, ratings, prior incidents — in one view, within SLA.

Features, stories & acceptance criteria

Feature: request a ride

Problem addressed: the fare-reveal step is the largest leak in competitor funnels (18-24% abandonment). The committed-fare promise is the platform’s core trust differentiator.

  • Story — See the committed fare before I confirm. “As a daily commuter rider, I want to see the committed fare before I confirm, so that I know exactly what I will pay.”
    • AC: When a rider confirms a ride request with pickup and dropoff, a ride is created in requested status and matching is initiated. (REQ-RIDE-001)
    • AC: Ride requests from riders who do not satisfy the Rider Management ready-to-ride gate are rejected. (REQ-RIDE-002)
    • AC: When a rider enters a destination, a fare estimate from Payment is displayed within 3 seconds. (REQ-RIDE-003)
    • AC: The fare committed at confirmation is the fare charged, unless the actual route materially deviates and is accepted by the rider mid-ride. (REQ-RIDE-004)
    • AC: The committed fare is shown with a breakdown — base fare, distance, time, surge if any. (REQ-RIDE-005)
    • AC: While the ride is in requested status with no driver assigned, the rider can cancel with no fee. (REQ-RIDE-006)
  • Story — Schedule a ride for later. “As a daily commuter rider, I want to schedule a ride for later, so that I can guarantee a ride at a specific time.”
    • AC: Where supported, riders can schedule a ride up to 7 days in advance. (REQ-RIDE-007)
    • AC: Where supported, when the current time is 15 minutes before a scheduled pickup, matching is initiated. (REQ-RIDE-008)
    • AC: Where supported, when the current time is 30 minutes before a scheduled pickup, a reminder notification is sent to the rider. (REQ-RIDE-009)

Feature: driver matching

Problem addressed: the sub-minute match is the headline experience commitment. Matching transparency — destination and earnings visible on every offer — also addresses driver frustration with incumbent platforms that hide them.

  • Story — Driver confirmed within seconds. “As a daily commuter rider, I want a driver confirmed within seconds, so that I can stop watching the app and get ready.”
    • AC: When a ride enters requested status, eligible nearby drivers are queried from Geolocation. (REQ-RIDE-020)
    • AC: The system offers the ride to the closest eligible driver. (REQ-RIDE-021)
    • AC: If a driver does not respond within 15 seconds, the offer is retracted and rolled to the next closest eligible driver. (REQ-RIDE-023)
    • AC: If no driver accepts within the configured search radius and timeout, the ride is cancelled with reason no-driver-available and the rider is notified. (REQ-RIDE-024)
    • AC: When a driver accepts, the ride transitions to driver-assigned, the rider is notified with driver and vehicle details, and RideAccepted is published. (REQ-RIDE-025)
  • Story — See ride offers with full destination and estimated earnings. “As a full-time driver, I want to see ride offers with full destination and estimated earnings, so that I can accept informed.”
    • AC: Every offer shows pickup, destination, estimated distance, estimated duration, and estimated driver earnings. (REQ-RIDE-022)
    • AC: The driver’s 30-day offer acceptance rate is exposed on the driver home screen. (REQ-RIDE-026)

Feature: pickup to completion

Problem addressed: the rider always knows where the driver is; the driver always knows what they will earn. Live location is the trust hook between assignment and pickup; fare finalization within seconds is the trust hook at the end.

  • Story — See the live location of my driver en route. “As a daily commuter rider, I want to see the live location of my driver en route, so that I can plan when to walk to the pickup point.”
    • AC: While the ride is in driver-assigned or driver-arrived, rider-facing driver location updates at least every 3 seconds. (REQ-RIDE-040)
    • AC: While the ride is in driver-assigned, the pickup ETA is refreshed on each driver location update. (REQ-RIDE-041)
    • AC: When the driver’s location is within 100 meters of the pickup point, the ride transitions to driver-arrived and the rider is notified. (REQ-RIDE-042)
    • AC: While the ride is in progress, location updates from Geolocation arrive at least every 3 seconds and the route is tracked in real time. (REQ-RIDE-045)
    • AC: While the ride is in progress, the destination ETA is refreshed on the rider app at least every 30 seconds. (REQ-RIDE-046)
  • Story — One-tap Start Ride and End Ride. “As a part-time driver, I want a one-tap Start Ride and End Ride control, so that the ride lifecycle is clean without menu navigation.”
    • AC: When the driver starts the ride, the ride transitions to in-progress, actual pickup location and time are recorded, and RideStarted is published. (REQ-RIDE-044)
    • AC: When the driver ends the ride, the ride transitions to completed, actual dropoff is recorded, and RideCompleted is published. (REQ-RIDE-047)
    • AC: When a ride is completed, final fare computation is requested from Payment using actual distance and duration. (REQ-RIDE-048)
    • AC: When the final fare is computed, payment capture is initiated through Payment. (REQ-RIDE-049)
    • AC: When a ride is completed, the driver earnings breakdown is displayed in the driver app within 5 seconds at p95. (REQ-RIDE-050)

Feature: cancellations with fair fees and penalties

Problem addressed: the symmetric cancellation policy. Riders cancel freely while no driver is committed. Once a driver is committed, both sides face proportional consequences.

  • Story — Cancel before a driver is assigned at no cost. “As a daily commuter rider, I want to cancel before a driver is assigned at no cost, so that I do not feel locked in the instant I tap request.”
    • AC: While the ride is in requested, when the rider cancels, the ride is cancelled with no fee, any payment hold is released, and RideCancelledByRider is published. (REQ-RIDE-060)
    • AC: While the ride is in driver-assigned or driver-arrived, when the rider cancels, the ride is cancelled, a cancellation fee is charged, the driver is freed, and RideCancelledByRider is published. (REQ-RIDE-061)
    • AC: The applicable cancellation fee policy is displayed at any time the rider can cancel. (REQ-RIDE-062)
  • Story — Policy-enforced no-shows and late cancels. “As a full-time driver, I want excessive no-shows and late cancels by the other side to be policy-enforced, so that my time is respected.”
    • AC: While the ride is in driver-arrived, if the rider does not board within 5 minutes, the ride is cancelled with reason rider-no-show, a cancellation fee is charged, and the driver is freed. (REQ-RIDE-043)
    • AC: While the ride is in driver-assigned, when the driver cancels, the ride is cancelled with no rider charge, the driver’s cancellation count is incremented, the ride is re-entered into matching, and RideCancelledByDriver is published. (REQ-RIDE-063)
    • AC: When a driver has cancelled more than 3 rides in 24 hours, the driver is suspended for 30 minutes and Driver Management is notified. (REQ-RIDE-064)
    • AC: While the ride is in driver-assigned, if the driver does not arrive within ETA + 5 minutes, the ride is cancelled with reason driver-no-show, re-entered into matching, and the driver’s no-show count is incremented. (REQ-RIDE-065)
    • AC: When a driver has accumulated more than 2 no-shows in 24 hours, the driver is suspended for 1 hour and Driver Management is notified. (REQ-RIDE-066)
    • AC: When a ride is cancelled with reason driver-no-show, the rider is notified that a new driver is being found, with an updated pickup ETA. (REQ-RIDE-067)

Feature: safety during and after the ride

Problem addressed: safety incidents are a first-order switching trigger. The bundle — emergency button, trip sharing, unusual-stop detection, post-ride reports — is a low-cost, high-signal differentiator that converts trust-sensitive riders.

  • Story — Share live trip status with a contact. “As an occasional traveler rider, I want to share live trip status with a contact, so that someone I trust knows where I am.”
    • AC: When a rider activates trip sharing, a real-time tracking link is sent to designated emergency contacts showing location and ETA while the ride is active. (REQ-RIDE-080)
  • Story — Emergency button. “As an occasional traveler rider, I want an emergency button during the ride, so that I can raise an alarm and share my location instantly if needed.”
    • AC: When a rider or driver presses the emergency button during a ride, an emergency event is recorded with timestamp, ride context, and current location, and the safety team is notified. (REQ-RIDE-081)
    • AC: When an emergency event is recorded, the safety-team notification is delivered within 60 seconds at p95. (REQ-RIDE-082)
    • AC: Where emergency-services integration is enabled in the rider’s market, when an emergency event is recorded, a location link is sent to the configured local emergency-services endpoint. (REQ-RIDE-083)
  • Story — Unusual stop detection. (platform-driven)
    • AC: While the ride is in progress, if the vehicle stops for more than 5 minutes at a location not on the planned route, a safety check notification is sent to the rider. (REQ-RIDE-084)
  • Story — Post-ride safety reports attached to the ride record. “As a trust and safety operator, I want post-ride safety reports attached to the ride record, so that I can triage and escalate with complete context.”
    • AC: When a rider or driver files a safety report within 30 days of ride completion, the report is recorded, attached to the ride, the ride is flagged, and it is escalated to the safety queue. (REQ-RIDE-085)
    • AC: If a safety report is filed more than 30 days after ride completion, the report is routed to the manual-triage queue rather than the automated escalation path. (REQ-RIDE-086)

Cross-cutting non-functional commitments

  • Match latency. When a ride is requested, driver-assigned is reached within 30 seconds at p50 and 90 seconds at p95 per market. (REQ-RIDE-NFR-001)
  • Fare estimate latency. When a rider enters a destination, the fare estimate is displayed within 3 seconds at p95. (REQ-RIDE-NFR-002)
  • Completion rate. Ride completion rate is sustained above 95% measured monthly per market. (REQ-RIDE-NFR-003)
  • Emergency path availability. Emergency button and trip sharing are available at 99.99% measured monthly, even when non-emergency features are degraded. (REQ-RIDE-NFR-004)
  • Audit trail. Every cancellation event is recorded with rider identity, driver identity, ride state, reason, fee outcome, and timestamp in an append-only log retained at least 7 years. (REQ-RIDE-NFR-005)
  • Deployment independence. Ride Management deploys independently of Driver Management, Rider Management, Geolocation, and Payment, subject to published inter-context contracts. (REQ-RIDE-NFR-006)

Reference journey

Commuter morning ride (daily commuter rider)

  1. Rider opens the app and taps Work — the saved destination prefills.
  2. Rider reviews the committed fare with breakdown and surge indicator, then taps Confirm.
  3. Matching spinner shows estimated time to assignment; a driver is assigned within seconds.
  4. Rider walks to the pickup point with live driver location and refreshed pickup ETA.
  5. Driver arrives; rider verifies vehicle plate and model and boards.
  6. Ride is in progress; ETA to destination, live route, and emergency / share controls are visible.
  7. Ride completes; receipt is delivered within a minute and the rating prompt appears.

This is the loop that the system requirements formalize step by step.

Goals & success metrics

  • Reduce rider wait time and abandonment. p50 time from RideRequested to driver-assigned < 30 seconds; p95 < 90 seconds; fare-reveal abandonment < 10% per market. Tied to the upfront-fare hypothesis. (REQ-RIDE-NFR-001, REQ-RIDE-NFR-002)
  • Run rides reliably end-to-end. Completion rate > 95%; driver no-show < 3%; rider no-show < 5%. Tied to the cancellations & penalties policy and the matching rotation. (REQ-RIDE-NFR-003, REQ-RIDE-043, REQ-RIDE-065)
  • Establish safety and trust baseline. Every active driver identity-verified before first ride; emergency reports acknowledged within 60 seconds at p95. Tied to the safety bundle and the audit hypothesis. (REQ-RIDE-082, REQ-RIDE-NFR-004)

Constraints

  • Regulatory — Surge cap risk. Regulators in several markets actively push back on surge pricing during emergencies or peak transit disruption. The cancellation, fare and surge policies must be tunable per market without code changes; the upfront-fare promise prevents retroactive surge once the fare is committed. (REQ-RIDE-004, REQ-RIDE-062)
  • Regulatory — GDPR and equivalent privacy regimes. Personal data of riders, drivers, and operators — including ride traces, chat, ratings, safety reports — is handled under GDPR (EU), CCPA (California), and equivalents, including right to access, correction, erasure, and minimization. Applies particularly to safety recording and the cancellation audit trail.
  • Regulatory — Local ride-hailing operating licences. In every launch market, RideNow holds the applicable ride-hailing operating licence and complies with local vehicle, driver, insurance, and cancellation rules. The cancellation audit trail (REQ-RIDE-NFR-005) is retained at least 7 years to satisfy regulator audits of policy enforcement.
  • Operational — Cross-context obligations. Ride Management is the heaviest cross-context surface in the platform. Outages or contract drift in Geolocation, Payment, Rider Management, or Driver Management directly degrade the ride loop; the deployment-independence requirement (REQ-RIDE-NFR-006) and inter-context contracts protect the loop from upstream incidents.

Traceability. Every feature above references REQ-RIDE-… identifiers formalized in the System Requirements page. Those requirements become value types, entities, aggregates, state machines, services, commands, events, and reactions in the Domain Model page. Cross-context dependencies — matching to Geolocation, fare estimate / pre-auth / capture / refund / fees to Payment, ready-to-ride gate to Rider Management, suspension to Driver Management, surge transparency and ETA tracking to Geolocation — materialize as infrastructure-service gateways (GeolocationGateway, PaymentGateway, RiderManagementGateway, DriverManagementGateway, RideNotificationService) and as Published Language events (RideRequested, RideCompleted, DriverNoShowRecorded).