Designated Driver Merchant Booking: Multi-Driver Orders and Waiting Fees

Designated driving fails in software when you only rename a taxi template. The car belongs to the customer. Hotels and restaurants want to book for guests. Groups need more than one driver at once. Waiting at the curb is billable time, not an awkward silence. Those are product requirements, not polish.

Ptaxi’s designated driver app module covers merchant-assisted booking, multi-driver counts, waiting fees and post-accept time changes on top of the shared passenger, driver and admin stack. Pricing and SOS patterns are covered separately in designated driver pricing and safety tools; this article focuses on how merchant and multi-car demand actually runs.

Why venues care about “merchant booking”

A restaurant manager does not want to hand a stranger’s phone number across a sticky bar and hope a freelance driver answers. They want to place the order, see status, and earn a defined cut when the trip completes.

In the documented designated-driver flow, merchant staff can place orders for users. After the order is completed, commission settles to the merchant per rules you configure. The admin can create merchants, view commission rules, and inspect reward statistics and detail lines.

That is an affiliate channel with operational teeth: someone at the venue is accountable for the booking quality, and finance can reconcile merchant payouts without a side spreadsheet. If your sales motion runs through hotels, clubs or banquet halls, ask to see the merchant list and a completed commission settlement in the demo — not only a passenger self-serve trip.

Multi-driver orders are a first-class field

Groups leave together. One “call a driver” button that assumes a single car forces three separate orders, three estimates and three chances for someone to cancel.

The passenger flow lets the user set the number of drivers required so several vehicles can be called at once. Combine that with booking for someone else (name and phone for the actual rider) and you cover the common “host books for guests” pattern without inventing a second product.

Operationally, decide how offers fan out: same pickup pin, staggered acceptances, and what happens if only two of three drivers accept. Your dispatch and cancel rules should say so before Friday night invents the policy.

Waiting fees and time-of-day plans

Chauffeur trips burn time before the wheels move. Pricing plans include waiting fees for the period after the driver arrives at the pickup point. The same plan structure carries base fare (starting fee or base fee), distance, time and long-distance fees, with different unit prices by time period and cycles for weekdays, weekends, holidays or a custom cycle. Preferential mileage-tier pricing can be enabled from admin.

That is how you express night and weekend tariffs without pretending you have a separate “surge” product. Passengers see estimated and preferential prices with a breakdown before confirm. Drivers confirm the bill at the end and may add highway, bridge or parking fees where your process allows.

Payment paths include passenger pay, driver advance pay, and offline collection against a driver QR code when enabled. Driver go-online can require a reserved wallet balance and, where you switch it on, uploaded collection QR codes before the driver can take work.

Changing time without canceling the trip

Plans slip. The documented flow allows modifying the trip time after a driver has accepted and before the driver confirms the passenger is onboard. That single rule saves goodwill: a ten-minute delay should not force a full cancel with whatever penalty you configured.

Pair it with clear cancel rules (including responsible cancel fees where you enable them) and a minimum estimated mileage gate so tiny trips never enter the pool. Heat maps and listening checks (network, location permission, online state) still matter — ghost-online drivers waste merchant goodwill as fast as passenger goodwill.

Merchant ops that keep finance calm

Create merchants in admin before the sales team promises a hotel partnership. Attach commission rules you can explain on one page. After trips complete, reward statistics and detail lines should match what the venue expects — including which completed states count.

Decide whether the guest pays in the passenger flow (wallet/balance or offline patterns you enable) while the merchant only earns commission, or whether the venue settles differently. Do not invent card-acquiring stories the feature lists do not document. Keep overseas packaging on wallet, balance and documented offline or driver-assisted collection.

Scan-to-order from a driver QR code still helps at the curb when a guest is already standing beside a driver the venue trusts. Merchant booking covers the case when the guest is still at the table.

Minimum mileage, heat maps and ghost online

A minimum estimated mileage gate stops junk trips from burning merchant goodwill. Heat maps that show online, accepting and idle drivers help venues and ops see whether Friday coverage is real. Listening checks — network, location permission, online state — reduce drivers who look available and never hear an offer.

Order broadcast with lock-screen voice matters on chauffeur nights when drivers are walking to a car, not staring at the app. If offers only appear when the app is foregrounded, acceptance rates will lie to you.

What to put on the demo script

Run this sequence once with the vendor watching:

1. Create a merchant and set a commission rule.
2. Place a merchant-assisted order for a guest phone number.
3. Request two drivers on one order.
4. Accept with one driver, change the pickup time before boarding.
5. Let waiting time accrue at pickup; confirm the bill shows the waiting component.
6. Complete the trip and show the merchant commission line in admin.

If any step is “we can customize that,” write down whether it is configuration or project work. For how designated driving differs from taxi apps at the product level, see designated driver app development.

Admin switches worth naming in the contract

Ask which business switches ship in your package: fixed-price style options, cash or offline payment, minimum mileage, acceptance limits, and whether drivers must upload collection QR codes before going online. Preferential mileage-tier pricing is an admin switch, not automatic. Geofence types that are documented as taxi-oriented may not apply cleanly to designated driving — verify rather than assume.

Customer-manager / referral style promotion exists on passenger personal-center patterns across lines; do not confuse that with merchant venue commission. They are different money flows.

For a wider product contrast against taxi apps, keep designated driver app development handy when writing an RFP.

What this is not

Merchant booking is not a substitute for driver verification. Drivers still submit materials and go online only after review. Emergency calling, trip sharing, emergency contacts and private-number protection remain passenger-side safety tools; admin alarm and complaint queues still need humans.

We do not claim China-only channels (mini programs, official accounts) as the overseas packaging. Frame payments as wallet/balance and the offline or driver-assisted patterns your contract enables — not card networks the feature lists do not document.

Train venue staff with a one-page job aid: when to book, how to enter the guest phone, how many drivers to request, and who to call if no driver accepts. Software cannot fix a host who enters the wrong pickup pin every Saturday.

If venues are part of your growth plan, say so early. The designated driver module is built for that channel; /contact/ is the shortest path to a demo that includes merchant commission, not only a solo passenger trip.