Ride-Hailing Book for Someone Else: Name, Phone and Proxy Booking

Parents book for kids. Assistants book for executives. A sober friend books for someone who should not be navigating an app at midnight. If your ride-hailing product only assumes “the phone in the car is the phone that tapped Call,” you will get wrong-number calls, missed pickups and support threads that start with “I ordered for my mom.”

Ptaxi’s ride-hailing platform documents Book for Someone Else inside the passenger booking flow: enter the rider’s name and phone, pulled from contacts or typed manually, then continue with pickup, destination and vehicle type like any other trip. This article stays on that documented path — no invented family accounts, no tip jars, no claim that the rider automatically inherits the booker’s coupons.

What proxy booking is solving

The hard problem is identity at the curb. Drivers need a name and a reachable number for the person standing outside, not only for the account that paid. Ops needs the same when a trip goes quiet. The booker needs a way to place the job without handing over their login.

Documented fields are deliberately small: name + phone. That is enough for dispatch contact and passenger-facing labels. It is not a full KYC pack for the rider. If your compliance team wants ID photos for every proxy rider, that is a process layer on top — not something to pretend the feature list already ships.

Trade-offs you should accept out loud:

• Light fields = higher completion, weaker fraud resistance.
• Heavy fields = fewer mistaken pickups for high-risk trips, more abandoned bookings for casual family use.
• Contacts import is convenient and privacy-sensitive; manual entry is slower and clearer for one-off riders.

Where it sits in the booking stack

On the passenger app, book-for-someone-else lives with the rest of the hail flow:

1. Pickup (defaults to current location, editable and searchable).
2. Destination (search and select).
3. Now or Schedule.
4. Book for Someone Else — name and phone via contacts or manual entry.
5. Vehicle type list from system configuration (examples in docs include carpool, charter, discounted express, standard express, premium, airport car), each with estimate and pricing detail.
6. Confirm → push to drivers by configured dispatch distance; calling screen shows wait time.

Carpool and charter stay prepaid regardless of the backend prepayment toggle. Proxy booking does not invent a new fare engine. It attaches rider contact data to a normal product choice.

Cancellation still follows backend passenger cancel rules — including a possible cancel fee after a driver has accepted, when rule conditions match. Tell bookers that canceling “for someone else” can still cost the account that placed the order.

Contacts versus manual entry

Contacts save typing when the rider is already in the phone book. Manual entry covers hotel concierges, paper notes and numbers the booker does not want stored as a full contact. Both paths feed the same name and phone fields.

Ops implications:

• Train drivers that the in-trip contact number may differ from the account phone.
• Keep private number protection (documented under safety settings) in mind when explaining how calls are masked — proxy trips still need a reachable rider number in the order.
• Do not assume the contacts picker works the same on every OS permission prompt; manual entry is the reliable fallback in field training.

If a market bans reading contacts, you still have manual entry. The feature is “name and phone,” not “must use the address book API.”

What still belongs to the booker’s account

Proxy booking does not move the whole profile. The account that taps Call still owns:

• Login and password prompts after verification-code habits.
• Wallet balance, coupons and invoice requests tied to that user.
• Trip history under My Trips (completed, canceled, in progress).
• Safety settings such as emergency contacts, real-name verification and private number protection on that account.
• Ratings, complaints and dispute flows after the trip.

The rider named on the order gets the car and the phone call. They do not automatically get the booker’s saved places, corporate approval role or promoter binding. If you need the rider to become a full user later, that is a normal register/login path — separate from this toggle.

Corporate ride approval is its own admin-backed flow for company administrators. Do not blur “book for my colleague” proxy fields with enterprise approval unless your implementation demo shows both wired together.

Driver and dispatch side effects

Drivers see a job with pickup, destination and contact cues. When the passenger phone on the order is the proxy rider, a call reaches the person at the curb. That reduces the classic failure mode where the driver calls the booker three neighborhoods away.

Documented driver tools that still matter on proxy trips:

• Smart dispatch versus grab modes, go-online / go-offline, order broadcast (including lock-screen style alerts where configured).
• Trip stages: to pickup, wait, to destination, bill confirm with add-ons such as highway, bridge or parking when needed.
• Pay paths at confirm: passenger pay, driver pay-on-behalf, offline pay, driver collection — as enabled in business switches.

Heatmaps and listening checks do not care who booked. They care whether the driver is actually online near demand. Proxy volume often clusters around airports, hospitals and nightlife — watch those zones in ops rather than treating proxy as a rare edge case.

For city launch sequencing that includes passenger UX choices, see how to start a ride-hailing service in a new city. Pair it with this proxy checklist so support scripts mention name/phone entry before go-live.

Safety and support without overclaiming

Passenger apps document trip share, customer service chat or hotline, driver complaints and order disputes. SOS is documented as a one-tap emergency dial pattern with alarm records in admin — for overseas readers, treat emergency calling as a configurable local concept, not a promise that Ptaxi dials a specific national number in every country. Proxy trips should still allow the person in the car to use in-trip safety tools on the device they have; do not assume the booker’s phone is in the vehicle.

Support macros worth writing once:

• “Who is the rider name/phone on the order?”
• “Who paid, and which account holds the receipt?”
• “Did cancel fee rules already fire after accept?”

Those three questions clear most proxy tickets faster than rebuilding the trip.

What not to invent in an RFP answer

Stay inside the feature list:

• No claim that proxy booking auto-splits payment to the rider’s bank card (cards/Stripe are not in the docs).
• No claim that selecting a contact creates a full sub-account with its own wallet.
• No mini-program-only framing for overseas pages; describe the passenger app capability.
• No fake conversion metrics for “family booking.”

If a buyer needs the rider to pay at dropoff on the rider’s own balance, say so in requirements and verify the payer UX in demo. Documented proxy copy stops at name and phone.

Close

Book-for-someone-else is a small form with outsized curb impact: name, phone, contacts or manual entry, then the same hail stack the booker already knows. Keep payment and profile ownership honest, train drivers to call the rider on the order, and write support macros that ask who rode versus who booked.

Bring two real proxy scenarios (airport pickup for a parent, assistant booking for an executive) to a session on ride-hailing app development and we can walk the fields live. Contact us.