Designated Driver Go-Online Rules: Balance Reserve, Heat Map and Order Modes

Designated driving dies quietly when any driver can go online broke, blind and on the wrong mode. Wallet reserve gates, a heat map that shows real supply, and a clear choice between smart dispatch and grab are not polish. They are how Friday night stays staffed without the office inventing rules in a group chat.

Ptaxi’s designated driver app module documents go-online limits, payment QR requirements, heat maps with online/accepting/waiting counts, dispatch modes, preferential mileage-stage pricing and waiting fees. Merchant-assisted booking and multi-driver orders are covered in designated driver merchant-assisted booking — this piece focuses on the driver go-online and supply side.

Go-online is a gate, not a toggle

Two controls matter before a driver hears a single offer:

1. Wallet reserve. Backend switches can block go-online (and order taking) when the driver balance sits below a configured reserve. That reserve is working capital for cash settlement, penalties and platform cuts — not a punishment for its own sake. Publish the number in driver onboarding so nobody discovers it at 9 p.m.
2. Payment QR before online. Drivers can upload collection QR codes for offline payment. Admins may require that upload before go-online is allowed. When the bill is confirmed, payment paths include passenger pay, driver advance pay, or showing the driver’s QR for offline collection. Without a QR where you require one, offline nights turn into arguments.

Health declaration on first daily go-online can be enabled from the admin side. Use it when your market asks for it; do not pretend it is a medical product.

Drivers who fail verification never reach this screen. Certification (including whether prior designated-driver experience and extra documents are required) is admin-controlled. Unapproved accounts should not serve.

Heat map: counts you can manage

The driver home heat map is an operations instrument. Documented contents:

• Areas with more orders
• Counts of online drivers, drivers accepting orders and drivers waiting for orders
• Visibility into drivers in waiting-for-passenger, heading-to-pickup and heading-to-destination states

Dispatchers and team leads use those counts to decide whether to message idle drivers, open a geo, or stop ad spend in a dead zone. Drivers use the same picture to choose where to wait. If your demo heat map only paints pretty colors without counts, ask for the numbers — that is the feature.

Listening detection (network, location permission, go-online state) tells the driver whether they are actually able to hear offers. A “online” badge with a dead listener is how you lose trust.

Smart dispatch versus grab

Mode settings let drivers work under smart dispatch or instant grab, depending on how you run the city.

• Smart dispatch pushes offers by configured rules. Drivers spend less time staring at a pool and more time driving.
• Grab widens agency: drivers pull work within acceptance range. Busy cores love it; sparse suburbs may leave riders waiting unless you tighten range or fall back to dispatch.

Order broadcast must survive a locked screen: voice for new offers, popup when the screen wakes, and clear origin / destination / distance in the announcement. Reservation reminders (SMS and voice before start) belong in the same reliability bucket.

Multi-driver passenger orders (several chauffeurs on one request) are a first-class field on this line; keep the fan-out rules next to your mode choice so three cars for one banquet do not collide with grab chaos. Details live in the merchant and multi-driver article.

Broadcast, reservations and the locked-screen test

Offer audio that dies when the phone sleeps will empty your heat map of real acceptances. Confirm in the driver app that new orders announce origin, destination and distance to pickup, that locked-screen voice still works, and that opening the phone lands inside the offer — not on a stale home screen.

Scheduled designated-driver jobs need the same honesty as real-time ones: early-start windows, SMS and voice reminders before the appointment, and rules that stop a rider from stacking conflicting near-term bookings. If reservations only live in a messenger thread while real-time jobs live in the app, you will double-dispatch on banquet nights.

Listen-detection results belong in driver support macros: “Your location permission is off” is a cheaper ticket than “the app is broken.”

Pricing that matches how designated trips feel

Pricing plans use the same core stack as other mobility lines: base fare (starting fee or base fee), distance, time, long-distance bands and waiting after arrival at pickup. Cycles cover weekdays, weekends, holidays or custom calendars. Different periods can carry different unit prices — say “time-period pricing,” not a surge brand name.

Preferential (特惠) pricing can be switched on: distance rates by mileage stage, with a maximum charge for that stage. That is how you run promotions without rewriting every plan. Waiting fees remain explicit — curb time is billable when the plan says so.

Passenger-side confirmation shows estimated fare, discounted fare and component detail before call. Minimum estimated mileage gates can stop tiny unprofitable pings. Fixed-price switches exist for operators who want an all-in number on selected jobs.

For the broader pricing and SOS framing on this product, see designated driver pricing and safety tools. Product overview: designated driver app development.

Payments without inventing card rails

Documented passenger payment methods on this line are in-app wallet balance plus the local methods the operator enables (commonly the regional wallet / QR rails you integrate). Driver confirmation can mark passenger pay, driver advance or offline QR collection. Do not invent bank cards, tips or Stripe in the marketing site if they are not in your build.

Wallet top-up packages with bonus credit can be configured for passengers. Driver wallets still need top-up, withdrawal review and the reserve gate above.

Settling the bill without a second app

When the trip ends, the driver confirms the bill. Passenger pay, driver advance and offline QR collection cover the usual curb cases. Cash-style offline collection still needs the platform cut to land correctly against the driver wallet when you use reserve gates — otherwise the reserve is theater.

Passenger wallets can offer top-up packages with bonus credit. Keep bonus rules boring and visible. Surprise credit that cannot pay waiting fees creates support load you do not need.

Invoice and withdrawal review stay on the admin side. Drivers who hit income freeze windows need that explained at onboarding next to the reserve amount.

What to staff before you open the city

• Set the reserve amount and QR requirement; train drivers once
• Decide smart dispatch vs grab defaults per zone
• Verify heat map counts match what ops see in the driver list
• Load preferential stages and waiting rules; test a receipt with components
• Keep merchant booking as a channel, not the only path — link regulars to self-serve and venues to merchant-assisted booking

Geofence drama is limited on designated driving compared with taxi lines — the docs note dispatch fences are aimed at taxi-business drivers. Do not promise taxi-style fence theater here without checking the module.

If go-online, heat map and modes are fuzzy in a sales call, stop the call and open the driver app. The reserve block and the online/accepting/waiting counts are visible in a working build. Start from the designated driver app page or contact us with your city map and expected Friday volume.