Book a Designated Driver for Someone Else: Name, Phone, and Who Rides
The person who needs the driver is not always the person holding the phone. A colleague is leaving a dinner. A parent is picking up a relative who should not drive home. A hotel desk is trying to help a guest without becoming a dispatch center. If your designated-driver app can only book for the logged-in user, those trips leak into a phone call and a texted pin. Ptaxi’s designated driver app documents booking for someone else: the account holder sets the rider’s name and phone number, from contacts or by hand, and places a normal designated-driver order.
This is not merchant-assisted booking. It is not a second product line. The useful work is teaching the two fields, the dispatch path that still applies, and the facts the list does not give you — especially who pays, and who receives a trip share.
Why “book for myself only” fails the people who actually need the car
Designated driving is often arranged by a third person. The rider may be with friends, already at a venue, or simply less able to finish a booking. If the app insists that the account on the phone must also be the person getting in the car, you force a workaround. Someone logs in on the rider’s phone. Someone books to their own pin and hopes the driver will agree to a change. Someone calls a manager and asks for a manual order. All of those paths lose the record you wanted: who requested the job, who is at the door, and which policy applies when the trip is canceled.
The product answer in the list is small and specific. You may book a designated driver for someone else. You set a name, sometimes written as a form of address, and a phone number. You can pull those from the phone’s contacts, or type them. That is the whole data contract. It is enough to put the right person in the driver’s call list. It is not a corporate travel product, and it is not a merchant counter.
What the booker actually enters, and how the order is still dispatched
Walk the passenger path in the same order the list uses. The booker still sets origin and destination. Admin may block the job if estimated mileage is under the configured minimum; that gate is already covered in minimum mileage and post-accept reschedule. The booker still confirms price, including the estimate, any preferential price, and the fare breakdown. The difference is the rider: name and phone, from contacts or manual entry.
When the details are confirmed, the booker taps the one-tap call control and the order is pushed to drivers according to the configured dispatch range. Booking for someone else does not get a private dispatch radius in the list. If your company already debated how far an offer should travel, use the same setting. Do not invent a “family booking” radius, a rule that only nearby drivers may take third-party jobs, or a requirement that the rider accept a push before the driver is assigned.
Stay inside the fields you have. The list does not say the rider must already have an app account. It does not say the booker must be on an approved contact list. It does not say a verification code is sent to the rider before the job can be placed — that kind of check appears on other channels in other product lines, and this article does not import it. If a prospect wants a rider confirmation SMS, say it is not in the confirmed designated-driver row for this path.
Who pays, who is called, and what trip share does not automatically do
Payment is the question every buyer asks, and the list does not answer it directly. Designated-driver passenger payment methods are documented on the account: balance and the documented online methods, plus the in-trip bill options already described on this line (passenger payment, driver advance payment, or showing the driver’s collection code for an offline collection). The “book for someone else” row only adds name and phone. It does not say the rider is billed. It does not say the booker’s wallet is always charged. In a demo, show the account that is placing the order, show the rider fields, and stop. If your company needs a written ops rule — “the booker pays” — write it as your policy, not as a Ptaxi guarantee.
The same discipline applies to calling and sharing. The rider’s phone is there so the driver can reach the person at the door. The list does not spell out a two-number call tree, a masked-number exception for third-party bookings, or a rule that the booker stays on the line. Trip share exists on the designated-driver passenger app: the user can share trip details. The list does not say a book-for-someone-else order automatically sends that share to the booker, or to a fixed emergency contact. Safety settings are not a substitute sentence either. Emergency contacts, real-name verification, and private-number protection are documented on the account’s safety settings. Do not claim they automatically attach to the rider’s phone.
If you need the booker to watch the trip, train a manual share after the driver accepts. If you need privacy numbers, show the safety setting on the account you actually have. Do not bundle those into the two rider fields.
Merchant booking, multi-driver call, and other paths to keep separate
Merchant-assisted booking is the path people confuse with this one. A merchant’s staff can place an order on a user’s behalf. After the trip is completed, the merchant can be settled a commission under configured rules. The admin console can create merchants. That is a venue or hotel counter flow with a commercial split. Booking for someone else is a passenger-app flow with a name and a phone. A hotel may need both. They should not share a training slide.
Multi-driver call is another neighbor. The passenger may request more than one driver on the same booking. That is about party size, not about who the rider is. Scan-to-book at a venue is a face-to-face hail. Appointment reminders and early start are about scheduled jobs. Cancel rules still apply to a third-party booking: the passenger cancel path can charge a fee when a driver has accepted and the rule conditions are met, and driver cancel rules can deduct service score for a violating cancel. Booking for someone else does not waive those rules, and the list does not publish a special third-party cancel table. Use the same cancel policy you already configured, and say so in the passenger note.
Tradeoffs to say out loud before launch
If you leave this path off, third-party requests stay in chat, and drivers arrive at the booker’s pin instead of the rider’s. If you turn it on and never decide who pays, support will invent a split after the first dispute. If you promise automatic trip share to the booker, you will be explaining a notification the list does not document. If you train this as merchant commission, the hotel will expect a settlement that belongs to a different module. Write a short ops page: whose account places the job, whose name and phone go on the order, who the driver should call, and how trip share is sent if you want the booker to watch.
Soft next step
If your drivers already take “my friend is at this address” calls, run one rehearsal before you promise the app will replace that text thread. Use the checklist, then come back to designated driver app or contact us when a lead can demo the rider fields, the dispatch range, and the payment screen without borrowing merchant commission language.
- In the passenger app, choose book for someone else. Enter a rider name and phone from contacts, then enter a second job by typing the fields by hand.
- Confirm that origin, destination, and the minimum-mileage gate still apply. Refuse a short hop if the gate refuses it.
- Confirm the estimate and place the job. Point at the same dispatch range you use for ordinary designated-driver work.
- Open the payment and bill options on the account that placed the order. Say out loud that the list does not name the rider as the payer.
- After accept, show trip share as a manual action if the booker needs to watch the trip. Do not claim an automatic copy.
- Write a one-page contrast: booking for someone else versus merchant-assisted booking, including who is settled a commission and who is not.
Frequently asked questions
What information is required to book a designated driver for someone else?
The booker sets the rider’s name and phone number. Those values can be picked from phone contacts or typed by hand. The list does not add a second destination field, a permission PIN, or a requirement that the rider already has an account. Do not invent those in a demo.
Is booking for someone else the same as merchant-assisted booking?
No. Booking for someone else is a passenger-app path: one account places a designated-driver order for a named rider. Merchant-assisted booking is a merchant staff path. After the trip is completed, the merchant can be settled a commission under configured rules, and the admin console can create merchants. Keep the two flows on separate training cards.
Does the rider’s phone automatically become the paying account?
The list does not say who pays. It documents the name and phone you enter for the person who will use the service. It does not say the rider is charged, and it does not say the booker’s wallet always pays. In a sales conversation, say that payment follows the confirmed designated-driver methods on the account that places the order, unless your own ops policy says otherwise — and do not present that policy as a product guarantee.
Do minimum mileage and dispatch range still apply?
Yes. The order is still a designated-driver job. If admin has set a minimum estimated mileage, a trip under that gate cannot be placed. After confirm, the order is pushed to drivers according to the configured dispatch range. Booking for someone else does not bypass those controls.