Taxi Driver App Features That Keep Drivers on Your Platform

Drivers stay when the app wastes less of their time than the alternatives. Fancy dashboards do not keep a night shift online. A clear go-online state, an offer they can hear with the screen off, a trip that ends in a trustworthy bill, and a wallet they can explain to a spouse — that does.

Ptaxi builds taxi dispatch software with a driver app that covers certification, heat maps, smart dispatch versus grab, order broadcast, trip stages through bill confirm, and wallet withdraw. We have a stake in this topic. Treat the checklist below as what any serious driver app should show in a shift-long demo — including ours — and hand the build to three drivers you trust before you buy a pitch deck.

Going online: status before the first offer

The first screen is not the offer. It is whether the driver is allowed to work.

Certification first. Drivers submit details and documents; admin verification review approves or rejects. Unapproved accounts should not serve. Same pattern appears across taxi, ride-hailing and designated-driver lines — do not soft-launch with “we’ll check papers later.”

Go online / go offline must be obvious. Drivers who think they are online while the system still shows them offline burn gas for nothing. Health declaration on first daily go-online can be toggled from admin where your market asks for it; treat it as a compliance switch, not a medical product.

Driver QR and proxy booking belong here for fleets that still take street work: a driver QR for passenger scan-to-order, and (where configured) driver-assisted booking limited to grab mode and long-distance carpool. Document the limits so a driver does not invent a second sales channel in a chat group.

The offer: hear it, read it, decide fast

Offers fail in the field more often than in demos.

Documented driver modes include smart dispatch and instant grab. Under smart dispatch, drivers can opt into or out of airport and station jobs. Under grab, they can choose whether to take long-distance carpool. Order scope and time-period settings cut pointless rejections: a driver who only works evenings should not drown in lunch offers.

Order broadcast needs to work when the phone is locked: voice content (pickup, drop-off, distance or scheduled time) and pop-ups for new jobs with the screen off. After unlock, the app should open into the job, not a blank home. Test that path on the cheapest Android brands your city actually uses — battery “optimisation” that kills background location is where fleets quietly lose Friday night.

Taxi-specific detail: within five minutes an unaccepted job can sit on the home view; older jobs move to an order pool; timed-out unaccepted jobs auto-cancel. Phone-dispatch voice jobs may require listening to the voice note before accept. That is not decoration — it is how you avoid drivers grabbing work they never understood.

For how push versus grab assignment works on the platform side, see how taxi dispatch software assigns orders.

Pickup, trip and bill confirm

Navigation to the pickup must hand off without losing the order state. Passenger contact by phone (privacy-number protection where configured) matters more than a pretty chat mock in a sales slide. Documented trip stages look like: head to pickup → wait for boarding → head to destination → confirm bill.

At bill confirm the driver can add highway, bridge or parking fees where policy allows. Payment paths include passenger pay, driver advance pay, offline/cash settlement, and driver collection. On metered taxi trips the in-vehicle meter often owns the fare the rider sees; phone-dispatch jobs may use a simpler on-trip flow and settle offline. When cash is marked paid, the platform cut still leaves the driver wallet so end-of-day numbers stay honest.

Cancellations, destination changes (driver updates after the passenger asks) and transfer of long-distance carpool jobs (with daily limits) belong in training, not in a footnote. For fare components the receipt should show, see how to calculate taxi fares in an app.

Earnings, wallet and trust

After the trip, drivers open three screens: order list (completed, cancelled, in progress), performance stats and passenger ratings, and wallet — top-up, withdraw, withdraw history and bill detail. Withdrawal requests go through admin review. Vehicle info changes after approval need customer-service review so a swapped plate does not silently rewrite compliance.

Referral rewards and learning/classroom modules exist on the ride-hailing side; use them when you have a real curriculum, not as a badge farm. Clear fee breakdowns beat motivational copy. Commission and wallet mechanics are covered in ride-hailing commission models and driver wallets.

Onboarding and document gates are a separate article: driver onboarding and verification.

Heat map: use it, do not worship it

The driver home heat map highlights busy order areas. It is a supply picture, not a prophecy. If every driver stampedes to the same red cell, you get a herd and empty suburbs. Train supervisors to treat the map as a conversation starter — “why is the east side empty at 10 p.m.?” — not as an automatic dispatch oracle. Behaviour-analysis marketing claims that are not in the product docs should stay out of your RFP answers.

Features that look good in a demo and fail in the field

• Perfect GPS on a flagship phone, silent death on a two-year-old budget Android.
• Offer screens that assume the driver is staring at the app instead of navigating.
• Earnings totals without a component breakdown when cash and in-app balance mix.
• “Support” that is only an email address with no in-app path during a live trip.
• Face-check or device-lock theatre that is not actually in the product you bought.

Safety tools for riders and drivers (trip sharing, one-tap emergency dial, alarm management in admin) are a different checklist — see ride-hailing safety features. Do not bolt SOS marketing onto a driver-app feature page unless the documented path exists.

Order pool, timeouts and taxi-specific noise

Taxi dispatch adds timing rules that ride-hailing demos often skip. Unaccepted jobs can remain visible on the driver home for a short window, then move into an order pool; jobs that sit too long auto-cancel. Phone-dispatch / voice jobs may require the driver to hear the full voice note before accept. Build training around that audio path — a driver who taps through without listening will show up at the wrong curb and blame the app.

Intercity versus urban commission and urban geofences appear on the taxi line; monthly passes that waive per-trip commission while still taking information fees, taxes or withdraw fees are a taxi-document pattern. If you sell both metered taxi and app-dispatch work in one fleet, say so in driver onboarding so wallet deductions are not a surprise. Cash marked paid must still pull the platform cut from the driver wallet or your evening totals lie.

What the operator needs to see

Offers, accepts, rejects and cancel reasons per driver; live vehicle location and track playback; certification queue queues; withdrawal review; exception orders (misreport, penalty, reject, refund, reprice). Without those admin views, the driver app is a toy. Small fleets deciding how much software they need first can start with own taxi app for small fleets.

Hand the demo driver app to three drivers for a week. Ask which screen they skip. That answer is worth more than any feature matrix on a vendor slide. If you want that demo walkthrough, contact us.