Priority for Company-Owned Drivers in Ride-Hailing Dispatch
Fleets that employ drivers and also take affiliates have a split loyalty problem. If every offer is a free-for-all, employed drivers sit idle while affiliates clear the board. If you reserve work for in-house drivers with no fallback, affiliates learn that the app is a closed club and stop listening. Ptaxi’s ride-hailing app development stack documents a business-module switch for that exact tension: priority for company-owned drivers.
The confirmed wording is short, and we think you should repeat it without decoration. Orders are first matched to in-house drivers. If no driver accepts within the timeout, affiliated drivers are matched next. That is a first pass, then a fallback. The lists do not publish the timeout length. They do not say the switch rewrites smart dispatch versus grab. They do not add a pay difference, a score boost, or an auto-offline rule. This article stays on the documented matching order, and on the honesty required when you turn it on.
Why mixed fleets starve one side or lock the other out
A company that only employs drivers can talk about “our cars” and stop there. A common setup is already mixed. They have staff drivers with shifts, vehicles, and a payroll conversation. They also have affiliated drivers who fill peaks, airports, and nights the payroll cannot cover. If the product has no first-pass rule, the night desk invents one in a group chat: hold the job, call a staff name, then maybe release it. That ritual does not scale, and it does not leave an audit trail.
The opposite failure is a hard lock. Affiliated drivers never see the offer. Staff drivers miss it because they are on a break, out of range, or already on a trip. The passenger waits. The desk then does a manual assign and wonders why affiliates “are not loyal.” Loyalty is a weak explanation when the match never reached them. A documented fallback after a timeout is how you protect employed drivers without pretending affiliates do not exist.
Keep the language clean in training. “In-house” and “company-owned” are the employed side. “Affiliated” is the fallback side. Do not rename those groups mid-workshop. Do not promise that the switch also changes commission, because the confirmed item does not say that. Platform commission is a separate setting for companies and affiliated drivers. Adjacent is not the same as combined.
What the documented first pass actually does
Admin business modules include priority for company-owned drivers. The list’s sentence is the whole product claim: orders are first matched to in-house drivers; if no driver accepts within the timeout, affiliated drivers are matched next. Demo that sentence. Then stop adding verbs.
“Matched first” means the first pass is restricted to the in-house set. It does not mean an employed driver is forced to accept. Drivers still accept or decline inside whatever mode they are running. If the in-house set is silent through the timeout, the second pass includes affiliated drivers. That is the fairness the switch owes the affiliate side. Train both audiences on the same story. Employed drivers should hear: you get the first look, not a guaranteed trip. Affiliates should hear: you may wait through a first pass, and then you are eligible. If you only tell one side, the other side will invent a darker version.
The switch lives with other order settings in the same business-modules list: one-tap order, prepayment, fixed-price surcharge, offline payment, driver-placed orders, income freeze, and more. Those are neighbors. Do not teach priority as a bundle that turns all of them on. A first-pass match is not a fare rule and it is not a wallet freeze.
The timeout you configure, not a number we invent
The lists say “within the timeout.” They do not publish minutes. That absence is a bound, not a hole for a sales figure. If a prospect asks for “two minutes” or “thirty seconds,” say the product documents a timeout and your operations team will set and publish the duration. Write the number in the SOP. Say the same number in driver onboarding. Do not print a guess in a brochure and then change it on night one.
Timeout length is a tradeoff you should say out loud. A very short first pass barely protects employed drivers; affiliates are in the mix almost immediately. A very long first pass protects payroll and risks a passenger staring at a waiting timer while affiliates could have taken the trip. We cannot tell you the right duration from the docs, because the docs do not give one. We can tell you not to hide the duration after you set it. Drivers will time it anyway. If your spoken policy and the actual wait disagree, you will spend the week arguing about a clock.
When nobody in either group accepts, that is a different problem. Manual dispatch is the documented admin tool for assigning a trip when no driver accepts, and scheduled long-distance carpool bookings have their own dispatch-only rule. Priority does not replace the desk override. If the first pass and the fallback both fail, use the manual path rather than inventing a third unofficial hold.
Keep smart dispatch versus grab as a neighboring choice
Drivers still choose smart dispatch or instant grab. Under smart dispatch they can choose whether to take airport or train-station orders. Under grab they can choose whether to take long-distance carpool. Transfer limits and driver-placed orders sit in that grab-plus-carpool corner. Those mode facts belong in the modes article. They are not a restatement of company-owned priority.
Does the priority switch change grab-mode behavior? The confirmed lists do not say so. They describe a matching order: in-house first, then affiliated after the timeout. They do not say grab hunting is rewritten, paused, or hidden for affiliates during the first pass. They also do not say the switch only applies in smart dispatch. If you do not know the mode interaction from the docs, do not claim one. In a demo, show the priority switch, then show the mode toggle, and say they are separate controls until your own tested build proves a tighter coupling. A slide that says “priority means dispatch mode” is a story the lists do not tell.
Push distance and geofence tags remain their own work. A first pass that only includes in-house drivers who are far outside a sensible push range will still fail, and the timeout will just be a delay before affiliates see an already stale offer. Fix range and go-online hygiene first. Then use priority as a matching order, not as a cure for a quiet rank.
What this switch does not do
It does not publish a timeout in minutes. It does not, on the documented wording, change grab-mode behavior. It does not set a different pay rate for employed drivers versus affiliates. It does not boost service score, and it does not automatically take an affiliated driver offline. It does not replace manual dispatch when both passes fail. It does not replace cancel rules, trip recording, or certification review. Those surfaces exist elsewhere in the ride-hailing lists. Keep them off this training card.
It also does not invent a “staff only” product line. Affiliated drivers are in the fallback. If your commercial plan is truly in-house only, that is a hiring plan, not a hidden meaning of this switch. If your plan is mixed, say the first-pass-plus-fallback sentence until people can repeat it.
Soft next step
If you already argue about who “should have gotten” tonight’s airport work, run a launch rehearsal with one employed driver and one affiliated driver on the same offer, then come back to ride-hailing app development or contact us when the desk can explain the first pass, the timeout, and the fallback without inventing a pay rule the lists do not contain.
- Open admin business modules and point at priority for company-owned drivers. Read the documented sentence aloud: in-house first, then affiliated after the timeout.
- Write the timeout duration you will actually use into a one-page SOP. If you cannot write a number because you have not decided it, you are not ready to turn the switch on for drivers.
- Place a test order. Confirm that the in-house driver is in the first match set, and that an affiliated driver becomes eligible only after the timeout you wrote down.
- Open the driver mode toggle (smart dispatch versus instant grab) and say it is a neighboring choice, not a restatement of this switch.
- Let the offer expire with nobody accepting, and show manual dispatch as the desk path. Do not invent a third unofficial hold.
- Tell employed drivers and affiliates the same story in the same words. If the two briefings disagree, rewrite them before launch night.
Frequently asked questions
What does company-owned driver priority do in ride-hailing?
The documented business-module switch says orders are first matched to in-house drivers. If no driver accepts within the timeout, affiliated drivers are matched next. That is a matching order: a first pass, then a fallback. It is not a promise that affiliates never see the job.
How long is the timeout before affiliated drivers are matched?
The confirmed lists call it a timeout. They do not publish the length in minutes. Do not invent a figure for a brochure. Treat the duration as an operations configuration, write it into your SOP, and say that same number to employed drivers and to affiliates.
Does this switch change smart dispatch versus grab mode?
The docs describe the matching order (in-house first, then affiliated after the timeout). They do not say the switch rewrites grab-mode hunt behavior. Keep smart dispatch versus instant grab as a neighboring mode choice, and keep admin manual dispatch as the desk tool for jobs nobody accepts.
Does priority change pay, service score, or auto-offline rules?
No such claim is in the confirmed lists. The switch is about who is matched first. It does not document a higher rate for employed drivers, a score boost, or an automatic offline rule for affiliates who wait through the timeout. If you want pay or coaching differences, write them as your own policy, not as product facts.