Designated Driver Min Mileage Gate and Post-Accept Reschedule Rules

Designated driving fails in two boring ways that never make it onto marketing sites. First: passengers book two-kilometer hops that waste a driver’s positioning time and tank acceptance morale. Second: after a driver already accepted an appointment, the passenger slides the clock, the driver rearranges their night, then someone cancels and support guesses who owes whom.

Ptaxi’s designated driver app line documents both controls explicitly. Admin can require estimated mileage ≥ a configured minimum or the passenger cannot place the order. After accept and before boarding confirm, the passenger may modify use time. If cancel follows that reschedule, the job lands on the admin appointment cancel list so staff assign passenger vs driver responsibility. Preferential-by-mileage pricing exists as a separate fare tool and only gets a light mention here — the focus is the gate and the reschedule/responsibility path. Related wallet and cancel themes live in designated driver cancellations, training and withdrawals and multi-driver and preferential pricing.

Why a minimum estimated mileage gate exists

Not every short move deserves a professional driver. Positioning, accept, navigation and settle all have fixed cost. If your city allows arbitrarily short estimated trips, you will watch:

• Acceptance rates fall on “real” jobs while drivers dodge micro-hops.
• Support fill with “driver took forever for a three-minute ride” tickets that are really product design debt.
• Heatmaps look busy with demand you cannot fulfill economically.

The documented business switch is blunt: minimum mileage limit — estimated mileage must be ≥ the minimum kilometers setting to place an order. On the passenger flow, destination entry is where the note belongs: backend can restrict orders below the minimum estimated mileage so the user cannot proceed.

Ops choices when you set the number:

• Too low: the gate is theater; micro-hops still win.
• Too high: you block legitimate neighborhood trips and push users to informal drivers.
• No passenger-facing explanation: users hit a dead end and churn, then blame “the app is broken.”

Publish the minimum in the booking UI copy and in driver onboarding. Drivers should know why tiny pins disappeared; passengers should know the floor before they type a destination two blocks away.

Estimated mileage is a gate, not a final fare promise

The gate uses estimated mileage at place time. Final billed distance can still differ once the trip runs under your pricing scheme (start fare / base, distance, time, long-distance, waiting — with optional preferential stages by mileage if you enable that fare tool). Do not train support to say “you passed the minimum so the final bill cannot change.” The minimum answers “may this order exist?” Pricing answers “what does the completed service cost?”

Keep preferential-by-mileage in its lane: it softens or stages distance price; it does not replace the hard placeability floor. If you need both, configure both and document both in the partner packet as separate rows.

Appointment time rules passengers already feel

Use-time selection follows the same family of appointment rules as other mobility lines in the docs: nearest selectable time is pushed forward from now (about thirty minutes, rounded on a ten-minute grid in the documented pattern) and booking can reach up to about three days ahead including today. That calendar discipline matters because reschedule only makes sense inside a product that already treats time as a first-class field.

When you demo, show a passenger picking a future slot, not only “now.” Appointment inventory is where reschedule fights are born.

The reschedule window: after accept, before boarding confirm

Documented passenger capability: modify use time when the driver has accepted and the driver has not yet confirmed passenger boarding. That window is narrow on purpose.

Why after accept?

• Before accept, changing time is closer to editing a still-forming request; the dangerous case is moving a driver who already committed.

Why before boarding confirm?

• Once boarding is confirmed, the trip has entered in-service reality. Sliding the clock then is not “reschedule” — it is breaking a live job.

Train both apps with the same sentence. Passengers who think they can freestyle the clock forever will cancel in anger when the button disappears. Drivers who think any passenger time change voids responsibility will abuse cancel paths.

Practical UX notes for implementation reviews:

• Show the original use time and new use time on driver and passenger order detail after a change.
• Notify the driver when the passenger reschedules — silent reschedule is how no-shows get mis-blamed.
• If your market uses SMS/voice appointment reminders, confirm whether reminders re-arm on the new time (deployment detail; do not invent a vendor promise beyond “reminder settings exist in business switches”).

Cancels after reschedule belong on a responsibility desk

Here is the rule that separates toys from ops software: after the passenger modified use time, if the passenger or the driver cancels, the order is recorded on the admin appointment-cancel list, and customer-service staff can manually confirm passenger responsibility or driver responsibility.

That list exists because chronology changed the fairness baseline. A cancel before any time change is one story. A cancel after the passenger moved the slot — maybe later into the driver’s peak, maybe earlier into a conflict — is another. Without a queue, agents argue in chat and finance never sees a consistent liability tag.

How to run the desk:

1. Open appointment-cancel items daily; do not let them rot into unassigned limbo.
2. Read the timeline: accept time, reschedule time, cancel time, who canceled.
3. Assign responsibility with a short internal note the next agent can trust.
4. Apply your cancel-fee / wallet consequences from that assignment — not from whoever yelled first.

Related cancel and training themes are broader in the cancellations article; keep this article’s claim tight: reschedule-then-cancel gets a dedicated admin list for responsibility.

Multi-driver bookings still obey the same gate

Passengers can request more than one driver on a job where you enable that capability. The minimum mileage gate still applies to the order’s estimated mileage at place time — it is not a per-seat loophole that lets someone book four drivers for a trivial hop. If anything, multi-driver short hops are more expensive for the network, so the floor matters more, not less.

Reschedule rules likewise attach to the order’s use time. When one passenger moves the clock for a multi-driver appointment, every assigned driver inherits the new commitment. That is exactly why a later cancel needs the appointment-cancel responsibility desk instead of a shrug.

What drivers experience when the gate and window are clear

Drivers stay online when the bookable set matches the money. A visible minimum mileage floor removes insultingly small pins. A bounded reschedule window removes “I accepted at 9, they moved me to 1, then canceled at 12:50” as an unpaid surprise — at least it becomes a reviewed case instead of a shrug.

Combine with other documented supply controls you may already use (go-online balance reserve, heatmap awareness, bill confirm options) without conflating them. Reserve gates who can go online. Mileage gates which demand may exist. Reschedule rules gate how appointment commitment can flex. Three different levers.

What this is not

• This is not a claim that every short trip is banned forever — you configure the kilometers.
• This is not preferential pricing cosplay. Preferential-by-mileage is optional fare staging; the minimum is a boolean placeability check.
• This is not WeChat-mini-program or China-hotline packaging. Overseas pages stay on passenger app, driver app and admin responsibility tools.
• This is not invented tip culture, card rails or fake “30% fewer cancels” metrics.

Soft next step

Sit with one ops lead and one lead driver. Pick a candidate minimum mileage for your densest night district. Walk a staging passenger through a below-minimum destination (should block) and a valid appointment accept → time change → cancel (should appear on appointment-cancel for responsibility). When that path is boringly clear, you are ready to continue on the designated driver product page or request a demo that starts on business switches and ends on the appointment-cancel queue — not on a homepage animation.