Designated Driver Order Disputes: Fare, Route, and Payment Feedback

After a night job, the argument is rarely abstract. Someone thinks the meter ran long. Someone thinks the path was wrong. Someone thinks the amount collected is not the amount that was shown. If that fight lives in a private chat, your desk has no record to audit, and the next shift will hear two memories that cannot be compared. Ptaxi’s designated driver app documents a passenger order dispute path for exactly that moment: if the passenger disputes trip pricing, trip route, or payment amount, they can submit feedback on the order.

That sentence is the product claim. It is not a courtroom wizard, and it is not a promise that money moves when the form is sent. This article stays on that feedback path, on the admin surfaces the designated-driver list actually names, and on the lines you should not blur. Bill confirm is a different drill. So is cancel responsibility after a reschedule. Point people at those posts rather than retelling them here.

Why a private chat is a bad dispute file

Designated-driver work happens late, often when a driver is standing next to a private car that is not a taxi with a sealed meter ritual the whole city already agrees on. Pricing may be metered or fixed, and add-ons may have been entered at the curb. The route may have changed because a passenger asked, or because a road was closed. Collection may have been online, advanced by the driver, or settled face to face against a QR. Any one of those facts can be honest and still be disputed ten minutes later.

If the only place to object is a message thread, the desk cannot see the objection next to the order, the two sides keep separate screenshots, and the next supervisor has to reconstruct a night from memory. We think disputes about price, path, or the amount collected should land on the order itself, as feedback, so the record and the trip stay together. A desk cannot audit a conversation it was never in.

What the passenger can actually submit

The documented item is short: order dispute — if the passenger disputes trip pricing, trip route, or payment amount, they can submit feedback on the order. Teach those three grounds as a closed set. Trip pricing is the fare construction: the metered stack, a fixed price if that mode was on, or add-ons that appeared at bill confirm. Trip route is the path the job took versus the path the passenger believes should have been taken. Payment amount is the money side: what was collected or requested versus what the passenger thinks is owed.

Do not stretch the form into a general inbox. Service quality has its own passenger action: complain about the driver, with a custom reason. That is a different item in the same passenger list. A rude comment and a disputed parking add-on should not be filed as the same ticket, even if both feel like “a problem with the trip.” Keep dispute feedback on the three grounds the list names, and keep service complaints on the service path.

The lists do not publish the exact fields on the dispute form, a photo-upload requirement, or a countdown after which feedback is refused. Do not invent a window or a mandatory photo rule in a brochure. If your policy needs those, write them as your policy and say so.

Keep this distinct from bill confirm

Bill confirm and offline collection is the end-of-trip settlement drill. After the driver confirms arrival at the destination, the bill is confirmed, allowed add-ons can be entered, and a pay path is chosen: the bill is pushed for the passenger to pay, the driver advances payment, or the driver shows a collection QR for offline settlement and then marks the passenger as having paid. Those paths are how money is supposed to be agreed at the curb. They are not the dispute form.

A clean launch treats them as a sequence, not as substitutes. If bill confirm was skipped or the add-ons were never shown, you will get more payment-amount disputes, and you should fix the confirm habit first. If bill confirm was done and the passenger still disagrees, that disagreement belongs on the order as feedback. Do not tell drivers to “just settle it in chat and end the order.” Do not tell passengers that submitting feedback is how they pay. Payment methods themselves are a local-wallet and balance-settlement topic; this article does not need to name them.

Fixed-price versus metered pricing is also a neighboring conversation, not a retelling. If a rider expected a shouted fixed number and the trip ran a meter, the training problem started in the fare mode. The dispute form can still receive a pricing objection. It should not be your only explanation of why two fare religions exist.

Keep this distinct from cancel responsibility after a reschedule

Passengers can cancel, and admins configure cancel rules, including daily limits and liable versus non-liable cases. After a driver has accepted and before boarding is confirmed, a passenger may change the trip time. If either side then cancels, that order belongs on an admin reserved-cancel list so staff can assign passenger or driver responsibility. That desk is already covered in cancellations, training, and withdrawals. This article does not retell it.

A cancel fight is about who broke the booking. An order dispute is about the fare, the path, or the amount collected. If a night supervisor files every unhappy passenger as a cancel, you will smear responsibility tags onto jobs that need a pricing or route review. If they file every cancel as a payment dispute, the reserved-cancel list will look empty and the refund queue will look noisy. Split the coaching.

Admin surfaces the designated-driver list actually names

You can mention admin tools that are in the designated-driver list. You should not invent a pipeline the list does not write. Order details can include complaint information, along with track, push logs, and trip audio. Complaint management lets staff view complaint status and replies. Feedback management is documented as a place to view passenger comments on using the app, and to reply. Exception orders can be viewed in detail, with actions the list names: false report, penalize, reject, refund, and reprice. Evaluation-tag configuration includes complaint reasons and refund reasons. Staff can also cancel an order in admin before the driver has confirmed the bill.

That is a real desk toolbox. It is not the same thing as a documented automatic hop from “passenger submitted order feedback” to “this is now an exception order.” The list does not write that hop. We think you should still have a written procedure: who reads order-dispute feedback, when a case is opened as an exception, when a refund or reprice is used, and when a complaint stays a service complaint. Configure the reason tags so the desk is not inventing categories in a chat. Show the passenger path and the admin surfaces in the demo. Do not narrate a workflow the source does not describe.

Feedback management, in the wording we have, is about comments after using the app. Do not assume it is the only inbox for order-dispute feedback unless your own tested build shows that. If the queues differ, train both. If they are the same screen in your build, say that as a build fact, not as a sentence from the list.

What this is not

It is not a published SLA for how fast a dispute is answered. It is not an automatic refund or reprice. It is not bill confirm, and it is not the reserved-cancel responsibility desk. It is not a claim about emergency calling, and it is not a named local-wallet brand. It is not permission to skip add-on policy at bill confirm and then hope exception-order reprice will clean the night. Driver cancel rules can deduct service score for a violating cancel; that is a cancel fact, not a dispute-form fact.

Soft next step

If your night arguments still live in private chats, run one launch rehearsal on a finished test trip, then come back to the designated driver app page or contact us when the desk can open the order and find the feedback without asking someone to forward a screenshot.

1. Complete a test trip through bill confirm (passenger pay, driver advance, or show-QR collection) so the settlement path is on the record first.
2. From the passenger side, submit order feedback on each named ground: trip pricing, trip route, and payment amount. Confirm the objection sits on the order.
3. File a separate service complaint with a custom reason, and show staff that complaint management is a different queue from a fare or route dispute.
4. Open admin order details, complaint management, feedback management, and exception orders. Name the exception actions the list actually gives you (false report, penalize, reject, refund, reprice) without claiming the passenger form triggers them automatically.
5. Walk one reserved-cancel case after a post-accept time change, then say out loud that this is not an order dispute.
6. Write a one-page desk procedure for who reads dispute feedback and when a refund or reprice is allowed. If you cannot write it, do not promise passengers an outcome the form does not itself perform.