Taxi One-Tap Booking: Confirm Origin Now, Enter Destination After Boarding
A street hail is fast because the passenger does not have to name the destination first. A lot of taxi software still forces that pin before a car will move. If your desk only sells “origin plus destination, then dispatch,” you will keep losing the rider who is already at the curb and will tell the driver where to go after the door closes. Ptaxi’s taxi dispatch software documents one-tap booking for that case: confirm the origin, hail now, and enter the destination after the driver confirms the passenger has boarded.
This is not a new fare engine. Taxi orders still use in-vehicle meter pricing. It is also not dial-a-ride simple flow, and it is not a scheduled booking. The useful work is teaching the hail, the boarding step where the destination appears, and the admin switch that turns the path on.
Why a full destination pin loses curb work
The standard passenger path is honest for appointment and airport work: set pickup, set drop-off, confirm, then wait. That path is already in the taxi list. One-tap exists because some trips do not start that way. A rider leaving a station, a bar, or a workplace often knows the origin and wants a car now. The drop-off comes after they sit down. If your app refuses to hail without a pin, the trip goes back to a wave on the street, and your dispatch software never sees it.
The pain is operational, not cosmetic. Drivers hear offers that look incomplete if you trained them only on origin-plus-destination broadcasts. Supervisors argue about accept range when drop-off is still blank. Support treats a missing destination as a broken order instead of the documented sequence. None of that is solved by adding another tariff. The meter still runs the fare once the trip is underway. The product has to make the hail legal in your ops policy, then record the destination at the right moment.
What the passenger actually confirms at hail time
Say the passenger step exactly as the list allows. The rider taps one-tap booking, confirms the trip origin, and hails a car quickly from that point. The origin can be the current location; the list describes pickup as defaulting to the current position and remaining editable on the ordinary booking path. For one-tap, the documented action is confirm origin and hail. Do not add a required destination field in the sales script if you are walking this path.
What you should not invent is equally important. The taxi list does not say one-tap carries a platform estimated fare at hail time. It does not say the passenger must pick a vehicle type, a prepaid amount, or a scheduled time on this path. It does not say one-tap can be combined with booking for someone else, or with a QR scan at the driver’s door. If a prospect asks for those combinations, say they are not written into the one-tap row. Keep the demo short: confirm origin, send the hail, wait for accept.
When the order is placed, taxi work is still pushed according to dispatch configuration, including how far an offer may spread. One-tap does not get a second radio network in the list. Pair this with driver accept range and company territory. A driver may accept a job only when at least one of the pickup or drop-off addresses sits inside the affiliated company’s range. On a one-tap hail, the destination may not exist yet. The list does not publish a special one-tap exception to that rule. Train the desk that the first filter may be origin-only, and do not invent a “destination-later bypass” in a proposal.
When the destination is entered, and what the in-trip flow still requires
The distinctive rule is timing. On this order type, the destination is entered after the driver confirms the passenger has boarded, and it is entered based on passenger feedback. That is a curb conversation, not a planning pin. Coach it as a sequence, not a slogan.
The documented taxi in-trip path is still the spine. The driver goes to the pickup point and confirms arrival, waits for the passenger, then confirms that the passenger has boarded. Only then does the one-tap destination get entered from what the passenger says. The driver then goes to that destination, confirms arrival, and confirms the bill. At bill confirm the driver enters the fare and may add highway, bridge or road, and parking fees. Payment is passenger payment, which pushes the bill to the passenger for an online payment, or cash, which is collected offline and deducts platform commission from the driver’s wallet. That bill path is the same family already covered in bill confirm, add-ons, and cash settlement. One-tap does not rewrite it.
Stay inside what the list actually names. “Based on passenger feedback” does not tell you whether the driver types the address, the passenger edits a field, or a dispatcher keys it in. Do not pick a typist in marketing copy. “Entered after boarding confirm” does not tell you whether the meter is already running, or whether a missing destination blocks the next slide. Do not invent a lock or a timeout. In a rehearsal, confirm boarding, record the stated destination, then drive the rest of the documented trip.
Driver order broadcast is a neighboring problem, not a second one-tap feature. Immediate taxi broadcasts are documented as origin, destination, and distance from the driver to the origin. Scheduled broadcasts add departure time and full-trip mileage. The list does not publish a separate one-tap broadcast script for the moment when destination is still unknown. Do not write “the offer always includes drop-off” into a one-tap training card. If your rehearsal plays an offer with a blank destination, record what drivers actually hear. Then write the ops note from that recording, not from a guessed prompt.
The admin switch, and the paths you should not merge
Admin business modules include a one-tap order switch, in the same cluster as online payment, cash payment, order simple flow, income freeze, driver accept range, scheduled-order acceptance, reminder settings, and service-score rules. That row is a map of neighboring levers. It is not a claim that they all write into one-tap.
If you sell curb hails with the switch off, passengers will look for a button the build does not offer. If you turn it on and still train drivers only on origin-plus-destination jobs, they will reject offers that look unfinished. Show the switch in the demo. Say what “on” means in one sentence: passengers may hail from a confirmed origin without entering a destination first. Then stop. The list does not publish a per-company override, a per-driver permission, or a score threshold that grants one-tap work.
Do not merge neighboring paths just because they also feel “simple.” Order simple flow is the dial-a-ride style trip: a simplified in-trip path without navigation, settled offline. One-tap is a passenger hail with a late destination. They can both exist in the same taxi company. They are not the same button. QR scan booking is a face-to-face hail from the driver’s code, and it already has its own article. Scheduled-order acceptance is about future pickup times, not curb work. Keep those sentences apart in training.
Leave China-only booking channels out of an overseas demo. The taxi list also describes phone and official-account paths. This article does not teach them, and it does not treat one-tap as a substitute for a call center.
Tradeoffs to say out loud before launch
Leave the switch off, and curb trips that have no pin yet stay off the platform. Turn it on without rewriting driver training, and origin-only offers will look like broken jobs. Promise a destination in the first broadcast even though the list does not give you a one-tap prompt, and you will spend the first week explaining missing drop-offs. Treat one-tap as a platform fare, and you will have to unsay a claim the meter still owns. Write a one-page curb script: confirm origin, hail, accept, arrive, confirm boarding, record the destination the passenger states, then finish the documented trip and bill.
Soft next step
If your ranks already take street work that names the drop-off after the door closes, run one rehearsal before you promise the app will replace the wave. Use the checklist, then come back to taxi dispatch software or contact us when a lead can demo the hail, the boarding step, and the bill without borrowing dial-a-ride or scheduled-order language.
- Open admin business modules and find one-tap order. Say out loud whether passengers may use this path tonight.
- In the passenger app, start a one-tap hail. Confirm origin only. Refuse to “fix” the flow by adding a destination pin if the path does not ask for one.
- Recheck accept range: pickup or drop-off must sit in company range. Note that drop-off may still be blank at offer time, and do not invent a special exception.
- After accept, walk the in-trip spine: arrive at pickup, confirm boarding, then enter the destination based on passenger feedback. Do not name a typist the list does not name.
- Finish the trip and confirm the bill: meter fare, optional highway, bridge or road, and parking add-ons, then passenger payment or cash with commission deducted from the driver wallet.
- Write a one-page driver note that one-tap is not simple-flow dial-a-ride, not a QR scan, and not a platform taxi-meter replacement.
Frequently asked questions
What does taxi one-tap booking capture at the moment the passenger hails?
The passenger taps one-tap booking, confirms the trip origin, and hails a car from that point. The documented flow does not ask for a destination at hail time. Do not demo this path as a full origin-and-destination booking.
When is the destination entered on a taxi one-tap order?
After the driver confirms that the passenger has boarded, the destination is entered based on passenger feedback. The list does not name which screen types it, and it does not publish a rule that the passenger must have typed a pin before the meter trip starts. Train the curb step: confirm boarding, then record the destination the passenger actually states.
Does one-tap booking replace the in-vehicle taxi meter?
No. Taxi orders use in-vehicle meter pricing. One-tap changes when the destination is known, not who calculates the fare. At bill confirm the driver still enters the fare and may add highway, bridge or road, and parking fees, then chooses passenger payment or cash.
Is one-tap booking the same as taxi dial-a-ride simple flow?
No. One-tap is a passenger hail from a confirmed origin, with the destination entered after boarding. Dial-a-ride simple flow is a neighboring taxi path: a simplified in-trip flow without navigation, settled offline. Do not train them as one product, and do not import phone-dispatch channels into a one-tap demo.