Planning a bike taxi dispatch operation

Define a service area that riders can actually serve

A bike taxi operation needs more than a radius on a map. Identify permitted operating areas, realistic pickup locations, opening hours, and the conditions under which requests should be declined or paused. A destination may lie inside a zone while its entrance is accessible only from a road your service cannot use. Review common locations with riders before publishing coverage.

Build a location list for stations, offices, campuses, and busy markets. Store a useful entrance description as well as coordinates. Start with a manageable area and review unmet requests before expanding. Operating permission, insurance, and passenger transport requirements depend on location and must be verified locally; installing dispatch software does not authorise a bike taxi service.

Make rider readiness an operational decision

Available should mean ready to accept and complete a passenger trip, not merely logged into an app. Define checks for rider eligibility, vehicle readiness, required equipment, device charge, and shift status. Separate available, offered, assigned, on trip, paused, and offline states so a rider cannot receive another passenger assignment while already occupied.

Helmet provision, suitability, and correct use belong in the operator’s safety process. WHO’s helmet manual supports a comprehensive approach to quality helmets and their use; it is not a substitute for local requirements or rider training. Establish who can pause service for unsafe conditions and how riders report a problem without being pressured to accept another trip.

Reduce uncertainty at the pickup

Give customers a clear pickup confirmation and a way to identify the assigned rider and vehicle. Give riders an entrance, landmark, and contact route that does not require handling a phone while moving. A message such as north gate beside the staffed entrance can be more useful than a precise pin on the wrong side of a wall.

Define what happens when the customer moves. A small correction may remain within the same booking; a materially different location may require a new estimate or reassignment. Record who approved the change and send consistent information to both parties. Explain waiting and cancellation rules before they apply, and retain the timeline if a charge is questioned.

Plan for rejection, lost connectivity, and service pauses

A rejected offer should return promptly to an actionable queue. A stale location must be visibly different from a recent position, and dispatch should know when the last update arrived. Ask how acceptance and trip completion are reconciled after a mobile device reconnects. Never interpret a missing update as proof that the rider has stopped or reached the passenger.

Create an escalation path for breakdowns, severe weather, and passengers who cannot locate the pickup. Dispatch should be able to stop new offers in the affected area while dealing with existing trips. For an emergency, follow local emergency procedures rather than treating an app support message as an emergency response service. Train the team on these distinctions before launch.

Work through a constrained pickup example

Consider an illustrative office-district shift with six ready riders and several requests from a station. One passenger selects the west exit, but that entrance is not a suitable pickup location. Dispatch confirms the agreed east-side meeting point before assigning a rider. Another rider goes offline after receiving an offer; the booking stays unresolved until acceptance is confirmed or a different rider takes it.

Now introduce heavy rain and pause new requests in that zone. Check that passengers already waiting receive an update and a clear cancellation option under your policy. The exercise tests communication, ownership, and recovery. It should not reward shorter journey times at the expense of safe riding or pressure riders to operate in unsuitable conditions.

Understand productivity without encouraging unsafe behaviour

Measure pickup success, request-to-acceptance time, waiting time, cancellations by reason, and manual support contacts per trip. Review distribution as well as averages: a small set of very difficult locations can hide behind an acceptable citywide mean. Compare zones and time periods with similar demand before changing staffing.

For example, 45 completed passenger trips over 30 rider-available hours gives 1.5 completed trips per available hour. State whether breaks and offline time are excluded. Treat this as a capacity-planning measure, not a rider speed target. Pair productivity measures with incident reporting and service complaints so a higher trip count is not mistaken for better overall performance.

Launch with a controlled rider and customer workflow

Rehearse onboarding, a normal booking, rejection, no-show, and connection loss with a small team. Use anonymised sample data where possible. Check notification language, mobile data use, battery behaviour, and the support route on the actual devices riders will carry. A workflow that works on office Wi-Fi may still be unsuitable on the street.

Review the first operating shifts with riders and dispatchers. Fix recurring pickup ambiguity before adding more coverage. Confirm the exact payment methods, service-zone controls, app requirements, and reporting available in the proposed product. Keep local compliance and safety checks separate from the software acceptance checklist; both need an accountable owner.

Your evaluation checklist

• Bring examples of unclear pickup locations.
• Test rider availability and a declined assignment.
• Discuss connectivity and customer cancellation handling.
• Agree on service-area setup and rider onboarding.

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.