Driver Management is the supply side of RideNow’s marketplace. It answers “who is qualified to drive for RideNow, is their vehicle safe, and are they in good standing to accept a ride right now?” The product spans from a candidate’s first application through ongoing identity verification, vehicle registration and document expiry, availability toggles, ratings accumulated across completed rides, and the suspension/appeal lifecycle that removes unsafe drivers while giving them due process. The ubiquitous language — Driver, IdentityDocument, Vehicle, AvailabilityState, AverageRating, Suspension, Appeal — is shared with the system requirements and the domain model.

Product statement

Vision. Drivers are the marketplace. Driver Management gets a qualified driver from signup to first ride in under 72 hours, gives them visible status at every step, and applies suspension and deactivation policy through a transparent, appealable, human-reviewed process — the opposite of the opaque deactivations that drove driver churn on incumbent platforms.

Scope. Driver application and identity-document capture; third-party identity and background verification; vehicle registration with registration / insurance / inspection documents and automatic eligibility tracking; availability toggle (online / offline) gated on verification, suspension status, and an eligible selected vehicle; rating capture after each completed ride with running average and 30-day trend; warning and suspension-proposal generation with operator review; appeal submission and resolution with full audit trail.

Non-goals. Run vehicle inspection or background checks in-house — RideNow integrates with certified third-party providers and consumes their result. Classify drivers as employees — drivers are independent contractors by design; jurisdictions that require employment are out of scope. Deactivate a driver automatically without a human review for ratings-only reasons. Allow a driver to serve rides with an expired document. Publish individual rider ratings publicly.

Problem statement (SCQ)

  • Situation. A two-sided ride-hailing marketplace only works if every active driver is identity-verified, drives a documented vehicle, and is in good standing the moment a rider taps Request. Drivers, in turn, depend on the platform to onboard them quickly, show them where they stand, and explain any policy decision that affects their income.
  • Complication. Independent driver surveys show 38% of new drivers leave competing platforms within 60 days, citing payout delays, unexplained deactivations, and opaque earnings breakdown as top reasons. Background checks must run through certified third parties whose SLA we do not control. Documents (registration, insurance, inspection) expire on their own clocks. Rating systems can deactivate a driver from a single unfair complaint with no recourse. Driver-classification disputes turn the audit trail of every suspension into a regulatory artifact.
  • Question. How do we onboard qualified drivers fast, keep only eligible drivers online, enforce a quality floor through ratings, and apply suspensions through a transparent, appealable, audited process — without ever letting an unverified driver reach a rider or a verified driver lose their livelihood without due process?

Personas & jobs

  • Part-time driver. A vehicle owner who drives evenings and weekends to supplement primary income. Goals: choose hours freely and still earn enough to justify the session; know per-ride earnings immediately; cash out quickly; avoid fake requests, disruptive riders, and unsafe pickups. Frustrations: long idle time off-peak; opaque commission and bonus structure; payouts delayed 5–7 days on competing platforms.
  • Full-time driver. A driver whose primary income comes from ride-hailing, 30+ hours per week. Goals: maximize consistent weekly earnings; maintain a high rating to access higher-value trips and bonuses; understand exactly why any suspension or deactivation happened. Frustrations: ratings can drop from one unfair complaint with no recourse; unexplained deactivations with no human appeals process.
  • Trust and safety operator. Reviews suspension proposals and appeals; resolves incidents with full ride context. Goals: apply suspension and deactivation policy consistently; preserve an auditable trail for legal and regulatory review.
  • Identity verification provider (system actor). A certified third-party integrated through IdentityVerificationProvider. Returns a verification decision per submitted application within an SLA window.

Features, stories & acceptance criteria

Feature: driver onboarding and identity verification

Problem addressed: every active driver must be identity-verified before a single ride is offered, and drivers must see status and reason at every step — not vanish into a black box.

  • Story — Submit identity and licence documents from the phone. “As a part-time driver, I want to submit my identity and license documents from my phone, so that I can start the onboarding process without visiting an office.”
    • AC: When a person submits a driver application, a driver profile is created in pending-verification status. (REQ-DRV-001)
    • AC: Driver can upload a government-issued ID, driver’s licence, and selfie from the app, and the system stores the documents and initiates third-party identity verification. (REQ-DRV-002)
    • AC: Driver sees the verification status — submitted, under review, verified, or rejected — at every step. (REQ-DRV-003)
    • AC: While the driver is not in verified status, the driver receives no ride offers. (REQ-DRV-004)
    • AC: When the verification provider returns a successful result, the driver transitions to verified and a DriverVerified event is published. (REQ-DRV-005)
    • AC: On rejection, the driver sees the specific reason and the appeal path, and the rejection reason is recorded. (REQ-DRV-006)
  • Story — Know how long verification will take. “As a part-time driver, I want to know how long verification will take, so that I can plan when I can start driving.”
    • AC: Driver sees an estimated time-to-verify on the status screen while verification is in progress. (REQ-DRV-007)
    • AC: When verification status changes, the driver is notified through the app and push channel within 24 hours of the change. (REQ-DRV-008)

Feature: vehicle registration and inspection

Problem addressed: every ride is served by a documented, inspected vehicle — a regulatory and insurance non-negotiable, and the safety baseline riders evaluate.

  • Story — Register a vehicle with registration, insurance, and inspection documents. “As a part-time driver, I want to register my vehicle with registration, insurance, and inspection documents, so that I can be offered rides in that vehicle.”
    • AC: When a driver registers a vehicle, the system stores the vehicle details with its registration, insurance, and inspection documents, and associates the vehicle with the driver. (REQ-DRV-020)
    • AC: Vehicle is marked eligible only when registration, insurance, and inspection documents are all present, valid, and unexpired. (REQ-DRV-021)
    • AC: When any document expires, the vehicle is automatically marked ineligible and the driver is notified to upload renewed documents. (REQ-DRV-022)
    • AC: While the driver’s selected vehicle is ineligible, the driver cannot go online in that vehicle. (REQ-DRV-023)

Feature: driver availability

Problem addressed: drivers control their hours; the system must guarantee that only verified, unsuspended drivers with eligible vehicles ever see a ride offer, and that ghost-online drivers are removed quickly.

  • Story — Toggle online and offline with one tap. “As a part-time driver, I want to toggle online and offline with one tap, so that I can start and stop my session freely.”
    • AC: While the driver is verified, not suspended, and has an eligible selected vehicle, when the driver requests to go online, the transition is confirmed within one second and a DriverWentOnline event is published. (REQ-DRV-030), (REQ-DRV-NFR-004)
    • AC: When an online driver requests to go offline, the driver transitions to offline status and a DriverWentOffline event is published. (REQ-DRV-031)
    • AC: While the driver is online, the driver is exposed as match-eligible to Ride Management together with the driver’s current location. (REQ-DRV-032)
    • AC: While the driver is suspended, any attempt to go online is rejected. (REQ-DRV-033)
    • AC: If an online driver’s last position update is older than 60 seconds, the driver is taken offline, notified, and a DriverWentOffline event is published. (REQ-DRV-034)

Feature: driver rating and suspension

Problem addressed: ratings drive quality on the rider side, but unfair complaints must not silently end a driver’s livelihood. Ratings-only suspensions require human review, and every operator decision is logged immutably.

  • Story — See current rating and trajectory. “As a full-time driver, I want to see my current rating and trajectory, so that I know where I stand and can take action before a suspension.”
    • AC: When a rider submits a rating for a completed ride, the rating is recorded and the driver’s average is recomputed. (REQ-DRV-040)
    • AC: Ratings are accepted only as integers in the range 1 through 5 inclusive. (REQ-DRV-041)
    • AC: Driver can see the current average rating and its 30-day trend in the driver app. (REQ-DRV-042)
    • AC: While the driver has completed more than 20 rides, if the average drops below 4.2, the driver is sent a warning notification with the threshold and the suspension policy. (REQ-DRV-043)
    • AC: While the driver has completed more than 20 rides, if the average drops below the suspension threshold, a suspension proposal is created in the operator review queue with the driver’s ride trace, rating history, prior incidents, and current payout state. (REQ-DRV-044)
    • AC: Driver can open an appeal on any rating below 3 with a free-text reason; the appeal is queued for operator review. (REQ-DRV-047)
  • Story — Operator review with full context. “As a trust and safety operator, I want to review every suspension proposal with full context, so that I can approve, reject, or escalate consistently.”
    • AC: When an operator approves, rejects, or escalates a suspension proposal, the decision is recorded with operator identity, reason, and timestamp in a permanent audit trail. (REQ-DRV-045)
    • AC: No deactivation or suspension triggered solely by rating thresholds is executed without operator approval. (REQ-DRV-046)
  • Story — Appeal a suspension. (due-process path for the full-time driver persona)
    • AC: When a suspended driver submits an appeal, the appeal is recorded and the driver transitions to appeal-in-review. (REQ-DRV-048)
    • AC: When an operator resolves a suspension appeal, the driver transitions to either verified or permanently-suspended, the resolution rationale is recorded, and the driver is notified. (REQ-DRV-049)

Goals & success metrics

  • 100% of active drivers identity-verified before the first ride. (REQ-DRV-004, REQ-DRV-005) — derived from the Establish safety and trust baseline product goal; no unverified driver ever reaches a rider.
  • 60-day driver retention > 70%. Derived from the Sustain driver supply and earnings transparency product goal (industry comparable: 62%). Retention is a function of fast onboarding, transparent status, fair ratings handling, and visible appeal outcomes.
  • Identity verification SLA: decision within 48 hours at p95. (REQ-DRV-NFR-001) — onboarding throughput depends on third-party SLA adherence; falling outside escalates to manual review.
  • Go-online response time ≤ 1 second at p95. (REQ-DRV-NFR-004) — the online toggle is a single tap and must feel instant, per the PRD acceptance criterion.
  • Audit trail retention ≥ 7 years, append-only. (REQ-DRV-NFR-005) — every suspension, deactivation, and appeal decision is preserved for regulatory audits and driver-classification disputes.

Constraints

  • Regulatory — background checks. Driver background checks must be performed by a provider certified in the applicable jurisdiction; we do not perform them in-house. Source: PRD constraint “Background checks must use certified providers”.
  • Regulatory — local operating licences. In every launch market, RideNow must hold the applicable ride-hailing operating licence and comply with local vehicle, driver, and insurance rules. Source: PRD constraint “Local ride-hailing operating licences”.
  • Privacy. Identity documents, licences, and selfies are sensitive PII. They are stored encrypted at rest using at least AES-256 (REQ-DRV-NFR-002), retained for the regulatory minimum applicable in the driver’s market, and deleted within 30 days of a valid erasure request after deactivation (REQ-DRV-NFR-003) — under GDPR, CCPA, and equivalents.
  • Operational — third-party SLA exposure. Verification depth is bounded by the certified provider’s SLA. Failure to return a decision within 48 hours at p95 escalates to manual review (REQ-DRV-NFR-001) — verification throughput is therefore a shared dependency on the provider’s capacity and on the Third-party identity verification meets our SLA assumption.
  • Risk — driver classification. A court or regulator ruling that platform drivers must be employees would break the marketplace model in that market (PRD risk, mitigation: avoid). The audit trail required by REQ-DRV-NFR-005 is the operating evidence that protects classification posture.

Traceability. Every feature above references REQ-DRV-… identifiers formalized in the System Requirements page. Those requirements become value types, entities, state machines, services, commands, and events in the Domain Model page. Three external events cross into Driver Management — RideCompleted and DriverNoShowRecorded from Ride Management, and DriverPositionStale from Geolocation & Routing — and are translated through reactions into the SubmitRating and GoOffline commands.