Planning shared-ride scheduling

Define the shared service before planning routes

Shared-ride scheduling combines compatible passenger requests into one vehicle journey. It differs from assigning a separate taxi to every booking. Decide whether you offer fixed departure shuttles, recurring commuter trips, scheduled door-to-door service, or a dynamically assembled shared journey. Each model creates different expectations about flexibility, waiting, and detours.

Write the passenger promise first: booking deadline, pickup window, arrival commitment if any, maximum acceptable detour, baggage allowance, and cancellation process. A route that minimises distance but misses a passenger’s required arrival time is not a feasible service plan. Keep these commitments visible to dispatch rather than storing them only in customer messages.

Capture constraints, not just origins and destinations

For each passenger, collect the pickup and destination, party size, earliest and latest acceptable times, and relevant service requirements. Record whether a time is a firm arrival deadline or a preferred pickup. These cannot be treated as the same input. Gather necessary accessibility information respectfully and restrict its use to service delivery.

For each vehicle, identify usable passenger capacity and any configuration constraints. Check capacity on every leg after pickups and drop-offs, not only at departure. A six-seat vehicle carrying four passengers can accept two more on the next leg, but not a party of three. If equipment changes usable capacity, represent that explicitly rather than relying on a driver’s last-minute judgement.

Build a feasible sequence before optimising

A practical planning method is to start with the least flexible bookings, place their stops, and insert compatible requests only when the revised route still satisfies all existing commitments. Account for travel between stops, boarding time, waiting, and the effect of a new pickup on passengers already aboard. Verify feasibility again whenever the stop order changes.

Dispatch-led grouping and automatic optimisation are different capabilities. Ask which constraints a proposed tool evaluates, which can be configured, and how a rejected request is explained. Do not infer an optimisation engine from a map or route display. Keep a manual escalation path for requests that cannot be served within the published promise.

Test a shared journey with a real tradeoff

Consider an illustrative six-seat shuttle carrying four passengers toward a business district. A two-person booking could fit by seat count, but its pickup adds 12 minutes to the route. An existing passenger has only five minutes of remaining arrival allowance. The insertion is therefore unsuitable even though capacity is available.

Possible responses include offering another departure, assigning another vehicle, or declining the request under your service rules. Do not simply move the existing passenger’s deadline. Record the rejected constraint so planners can see whether unmet demand comes from capacity, timing, or geography. All numbers in this example are illustrative and should be replaced with your own service commitments.

Handle no-shows and cancellations without confusing the route

Give drivers the current stop sequence and a clear process for confirming boarding or reporting a no-show while safely stationary. Define who authorises waiting beyond the planned allowance and when dispatch should continue to protect other passengers. A cancellation may release a seat, but accepting a replacement request still requires checking the full route.

When dispatch changes a journey, retain its identifier, version the instructions, and obtain acknowledgement. Update affected passengers with useful revised information without sharing other riders’ names or destinations. A stale driver itinerary and a newly optimised dispatcher screen must not coexist unnoticed. Include reconnect and duplicate-update cases in software testing.

Explain pickup windows and service boundaries

Communicate the whole pickup window, the meeting point, and how the passenger should prepare. If your service promises a window rather than an exact minute, avoid a confirmation that implies a fixed appointment. Explain when a live estimate is advisory and what happens if the service falls outside its original commitment.

FTA material on shared-ride paratransit describes the use of pickup windows. That is a US public-transport context, not a universal rule for commercial pooling. Accessibility and service obligations depend on the service and jurisdiction. Use local requirements when setting policies; do not copy another operator’s window or no-show rule without checking its suitability.

Measure passenger outcomes as well as vehicle usage

Track pickups within the original window, arrivals within promised deadlines, excess ride time, rejected requests by constraint, and cancellations after assignment. For occupancy, passenger-kilometres divided by vehicle-kilometres gives average passengers carried over distance. For example, 120 passenger-kilometres over 60 vehicle-kilometres equals two passengers on average, not a seat-occupancy percentage without a capacity denominator.

Review these measures together. Higher occupancy can coincide with unacceptable detours, and fewer empty kilometres can conceal missed deadlines. Start with a limited route or departure period, compare actual stop times with the plan, and refine boarding allowances. Confirm matching scope, notifications, fare allocation, and data exports before scaling.

Your evaluation checklist

• State whether trips are shared-route or individually dispatched.
• Bring capacity limits and pickup-window examples.
• Test cancellation within an existing shared journey.
• Confirm matching rules and configuration in writing.

Common questions

Explore the next step

Use this checklist to structure a conversation about your operation. Confirm required capabilities, integrations, and commercial terms before making a decision.