Taxi Scheduled Orders: Booking Window, Acceptance, and Broadcast

If your taxi desk only sells trips that start now, you will keep losing work that was decided last night. Airport runs, shift changes, clinic visits, and hotel departures still need a car. They need a booking window, a switch that decides whether drivers may take scheduled work, and a broadcast that tells a driver when, not only where. Ptaxi’s taxi dispatch software documents taxi scheduled orders on those three surfaces.

The passenger appointment path lets a rider choose a scheduled pickup time. The nearest selectable time is the current time plus 30 minutes, rounded in 10-minute units. The latest is within three days, including today. On confirm, the order is pushed according to dispatch and spread settings. Whether a driver may accept that work is an admin business switch: scheduled-order acceptance. If the offer is allowed, the scheduled broadcast has to carry departure time, origin, destination, and full-trip mileage. This piece is about training those facts. It is not a rewrite of ride-hailing reminder channels, and it is not a claim that the platform replaces the meter.

Why “now only” leaves appointment work on the street

Immediate work is easy to demo. A pin appears, a car moves, a meter starts. Appointment work is quieter and easier to under-build. A passenger with a morning airport run does not want a “try again at 5 a.m. and hope someone is listening” product. If your software cannot hold a future time, or if drivers hear that job as a now-trip, the booking leaks into a phone call and a spreadsheet.

The pain shows up in three places. The passenger app has no honest window, so agents invent times in chat. Drivers may be forbidden from scheduled work, or nobody told them the switch exists, so the offer rings people who will swipe it away. The broadcast names a place but not a departure time, so a driver accepts a job that starts in two hours as if it starts in two minutes. None of those failures is a pricing problem. Taxi orders still use in-vehicle meter pricing. The platform is not the meter. It has to get the time, the permission, and the prompt right so the meter can do its job later.

The booking window passengers can actually select

Say the window in workshops exactly as the list allows. The nearest selectable time is current time plus 30 minutes, then rounded in 10-minute units. The latest selectable time is within three days, including today. That is a tight, documented range. It is not “book any week,” and it is not “book for five minutes from now.” If a buyer wants a closer same-morning slot, or a week-ahead tour booking, the confirmed taxi list does not give you that floor or that ceiling. Write the passenger-facing copy to match the window you actually ship.

Rounding is easy to skip in a slide and expensive at the curb. A rider who thinks they booked 9:07 will argue with a driver who was shown 9:10. Train support to read the selectable time, not the raw clock the passenger glanced at. The list does not publish a worked example of the rounding; do not invent one. Show the picker in a demo and write a one-line rule: the time on the order is the time that was selected. Today is included in the three-day horizon. Keep the documented phrase tight: three days, including today.

Confirm, dispatch spread, and the meter

When the passenger confirms, the order is pushed according to dispatch configuration, and that configuration can set how far the offer spreads. This is the same push family already used for taxi work, not a second radio network. Pair the push story with driver accept range and company territory so a scheduled job is not treated as a city-wide free-for-all. A future pickup still has an origin and a destination. The company-range accept rule still asks whether pickup or drop-off sits inside the affiliated company. Diffusion widens the first push. It does not replace that filter, and it does not replace the scheduled-order acceptance switch.

Taxi orders use in-vehicle meter pricing. Repeat that in the same breath as scheduled work, because sales decks love to describe a “platform fare” as if the taxi meter had been retired. The confirmed taxi list does not describe a platform fare engine as the taxi meter. When you walk a scheduled airport job in a demo, show the booking time and the push, then say the fare is still the meter’s job once the trip runs. Dial-a-ride simple flow is a neighboring path, not a scheduled-order tariff. Do not turn a scheduled booking into a special commission class the taxi list does not define.

What the scheduled broadcast must tell the driver

Taxi driver order broadcast already covers the hearing problem: offers that exist on a server and never reach an ear. This article only needs the content contrast. For a scheduled taxi order, the broadcast includes departure time, origin, destination, and full-trip mileage. Immediate taxi broadcasts are origin, destination, and distance from the driver to the origin. Those two scripts are easy to mash into one training card. They should not be.

A now-trip driver needs to know how far the pickup is. A scheduled-trip driver needs to know when the work starts, where it starts, where it ends, and how long the trip is in mileage. Full-trip mileage is not the same figure as distance-to-origin. If you only announce distance to the hall, a driver cannot plan a long airport run that begins at 04:30. Coach the four scheduled fields as a set. If drivers in your rehearsal hear a future job without a departure time, stop and fix the prompt before you talk about commission.

The acceptance switch, and what reminder settings are not

Admin business modules include a scheduled-order acceptance switch and reminder settings, among other taxi operating controls. That row is a map of neighboring levers. It is not a claim that they all write into scheduled work.

The acceptance switch answers a simple question: may drivers take scheduled orders? If you sell appointment work with the switch off, passengers will book times the rank is not allowed to serve. If you turn the switch on and never tell drivers, you will get accidental accepts from people who only wanted street work. We think this should be a written ops policy, not a tribal setting one supervisor remembers. Show the switch in the demo. Say what “on” means in one sentence. Then stop. The list does not publish a per-driver override, a per-company exception table, or a score threshold that grants scheduled work. Do not invent those.

Reminder settings sit next to the switch. The taxi list confirms that reminders can be configured. It does not say the reminders are SMS plus voice. That wording lives on the ride-hailing list, and this article does not import it. The taxi list also does not document ride-hailing early-start rules, or a rule that a user with an existing scheduled order cannot place another order for a nearby time. If a prospect asks for those behaviors on taxi, say they are not in the confirmed taxi list. Configure the reminder surface you actually have, and publish a passenger-facing note about what, if anything, they will receive.

Tradeoffs to say out loud before launch

Leave the switch off and sell only now-trips, and appointment work stays on the phone. Turn the switch on without rewriting the broadcast, and drivers will accept a future job that sounds like a street hail. Publish the booking window and then let agents promise “any time this week,” and you will spend support time unsaying your own sales sentence. Write what you actually send as a reminder, including “we do not promise a text,” if the taxi list does not name a channel.

Soft next step

If you already take appointment calls on paper, run one launch rehearsal before promising the app will replace the notebook. Use the checklist, then come back to taxi dispatch software or contact us when a lead can demo the window, the switch, and the scheduled broadcast without borrowing reminder language from another product line.

1. In the passenger app, show the earliest selectable time (current time plus 30 minutes, rounded in 10-minute units) and a latest time inside three days, including today. Refuse a closer or a farther slot if the picker refuses it.
2. Confirm the order and point at dispatch and spread settings as the push path, not as a new radio. Recheck that pickup or drop-off still has to sit in company range for a driver to accept.
3. Listen to the scheduled broadcast and tick four fields: departure time, origin, destination, full-trip mileage. Play an immediate broadcast next and name the contrast (origin, destination, distance to origin).
4. Open admin business modules and find scheduled-order acceptance. Say out loud whether drivers may take this work tonight.
5. Open reminder settings. Record what the taxi surface actually lets you configure. Do not write “SMS and voice” unless your own policy and build, not the taxi list, say so.
6. Write a one-page passenger note that quotes the booking window and does not invent early-start, nearby-time blocks, or a platform taxi-meter fare.