In a regional ride-hailing operation, the difference between an 88% and a 77% completion rate during the morning peak is rarely about the number of drivers connected — it is about where those drivers are when the first request of the peak arrives. If an operator has 22 active drivers at 7:30 a.m. but 14 of them are in peripheral zones or their usual rest spots when the first 7:30–8:15 request block hits, the operation starts every peak from a positioning deficit that takes 12 to 20 minutes to self-correct. That initial deficit produces the rejections, long waits, and passenger cancellations that the metrics show afterward, when the peak is already over and the information that would have prevented it has turned into historical data.

This article is for the operator with 20 to 80 active drivers who already has zone and time-slot data in the platform and who has identified that demand peaks carry higher rejection rates or wait times than the rest of the day. It covers why reactive positioning lag is structural when fleet movement depends on the operator detecting the peak before acting, how to extract the predictable demand map by zone and time slot from the past six to eight weeks of data, when to send the instruction so the driver arrives before the peak, what information to include so the driver understands the value of repositioning, how the agent can generate those instructions systematically, and what indicators confirm that proactive positioning is reducing the initial deficit of every block. The thesis is counterintuitive for anyone managing their fleet reactively: the right positioning doesn't respond to the peak — it anticipates it.

The reactive lag: what the operation loses in the first 15 minutes of every peak

The reactive lag mechanism works like this. At 7:28 a.m. the first morning peak request arrives in the office zone. The nearest driver is 8 minutes away and accepts. At 7:31, three simultaneous requests arrive; drivers within the radius are at 7, 9, and 12 minutes. The 12-minute driver rejects. By 7:35 there are eight active requests and four available drivers; the system assigns to the closest — at 5, 7, 10, and 14 minutes — the two farthest get rejected and the system escalates to the next available driver, who is now at 11 minutes because the 5 and 7-minute drivers are already en route. Between 7:28 and 7:48, the system processed 22 requests: 14 completed, 4 canceled because the wait exceeded 10 minutes, and 4 expired with no driver in the radius. The cause was positioning: at 7:28 there were enough drivers to cover the peak, but they weren't in the zone where the peak was going to happen.

The signal that the problem is positioning rather than headcount is the completion rate in the window just before the peak: if between 7:00 and 7:25 a.m. it was 91% with the same active drivers, the drop in the first peak slots is not a total supply problem but a geographic distribution problem. The operator who detects the drop and takes 15 to 25 minutes to react — identify the zone, communicate to drivers, wait for them to arrive — loses exactly that window. By the time the positioning message reaches the driver and the driver repositions, the peak has already entered its natural decline. Reactivity is not operator slowness: it is the structural consequence of managing the fleet in response to what already happened instead of what is already known to be about to happen.

Demand is predictable: how to read the zone and time-slot map from the last six weeks

Proactive positioning is feasible in regional ride-hailing because demand in cities of 150,000 to 600,000 residents follows a highly repeatable weekly pattern. A Tuesday in a city of 300,000 residents produces peaks in the same slots as the previous Tuesday with less than 12% variation in request volume, barring unplanned events. The same zones that generated 65% of last Tuesday's requests between 7:30 and 9:00 a.m. will generate 60 to 68% the following Tuesday. That level of regularity turns six to eight weeks of historical zone and time-slot data into a predictive positioning map the operator can use before the shift begins, not after the peak has already appeared.

The agent query that produces this map: 'For the last six weeks, show me unique requests from Monday to Friday grouped by origin zone and two-hour slot. For each zone-slot combination, show me the average requests per day of the week — separating Monday through Thursday from Friday — and the week-to-week deviation of that average. Include median wait time and rejection rate for each combination.' The result is a table of twelve to twenty-four rows that shows exactly which zones and slots concentrate demand predictably. For an operator building a weekly positioning calendar, the five or six zone-slot combinations with the highest request averages and the most variable rejection rates are the ones that need proactive positioning before the slot starts, not after.

Message timing: why 20 minutes of lead time changes the outcome

The time it takes a driver to change zones in a city of 200,000 to 400,000 residents ranges from 8 to 18 minutes depending on the distance from their current position to the target zone and the traffic at that moment. An operator who sends the message 5 minutes before the peak gets a response that arrives after the first 10 to 15 requests of the block have already been processed. One who sends it 20 to 25 minutes ahead can expect 60 to 75% of drivers active in the prior slot to arrive or already be near the zone before the request block begins. That is the operational threshold: a message with 20 to 25 minutes of lead time can actually change the fleet's real positioning before the peak starts; one with 5 to 10 minutes cannot, because the driver's transit time exceeds the useful window.

For peaks that occur at the start of the shift — the 7:00 to 9:00 a.m. block that exists in most markets with concentrated work activity — the optimal send time is not 20 minutes before the peak but at the driver's session start: when they activate the app or mark shift start, they receive the positioning instruction for the next 90 minutes. That driver starts the session already oriented toward the highest-expected-demand zone, without needing to reposition from anywhere. For midday peaks — between 12:30 and 2:00 p.m. — and exit peaks — between 5:30 and 7:30 p.m. — the message should go out 20 to 25 minutes before each slot's start, using the mean fleet transit time to the peak zones as the calibration variable.

What a positioning message the driver actually follows includes

The difference between a positioning message the driver uses and one they ignore is not tone — it is the specificity of the information. A message that says 'there's demand in the northern zone this morning' doesn't change behavior because it gives no new information: the driver already knows the north has morning demand. A message that says 'For 7:30 to 8:45 a.m.: position at the Av. Juárez and Blvd. Morelos intersection. We expect 18 to 22 requests within 2.5 km. Last Tuesday that zone averaged 340 MXN between 7:30 and 9:00 a.m., with trips of 12 to 15 minutes. There are 3 active drivers in the zone now' has everything the driver needs to make a repositioning decision based on actual opportunity cost.

How the agent builds positioning instructions for each shift

The proactive positioning cycle doesn't require the operator to manually generate the demand map every morning: the agent can build that instruction from the historical data available in the platform. The query that produces the next day's message: 'For tomorrow Tuesday, based on the last six Tuesdays, identify the two or three zone-slot combinations with the highest average request volume and historical rejection rate. For each, generate a positioning message directed at drivers that includes: the most specific geographic reference point within the zone, the exact time slot, the average expected requests, the median income of active drivers in that zone-slot over the past four weeks, and the time the message should be sent so drivers can arrive before the slot begins.' The result is a message ready to send, with the specific instruction, the time window, and the economic reference point the driver can evaluate before deciding whether to reposition.

To integrate this into the weekly routine without querying every day: 'Every Sunday before 8:00 p.m., generate the positioning messages for the coming week — Monday through Saturday — with the two zone-slot combinations of highest expected demand for each day of the week. For each message, include the send timing, the geographic reference point, the demand window, the average expected requests, and the reference median income of active drivers in that combination on the same day in the prior month.' With that routine, the operator starts each week with six days of positioning messages generated, reviewed in 15 minutes on Sunday, and sent in the correct time window before each peak. The production cost is effectively zero; the cost of not having them is the positioning deficit the operation paid for in the peaks of the prior week.

How to know whether proactive positioning is working

The most direct indicator that proactive positioning is changing peak outcomes is the completion rate in the first slot of each peak, compared week over week. If before implementing it the first slot of the morning peak — 7:30 to 8:00 a.m. — had a 76% completion rate, and after it rises to 87%, the difference represents 11 additional completed requests each morning that were previously lost during the reactive lag window. Over 26 business days, that amounts to 286 additional completed requests per month — approximately 24,000 MXN in additional income in an operation with an 85 MXN average trip — without adding a single driver. The first-slot metric is more diagnostic than the full-block average because the effects of positioning concentrate in the first 20 to 30 minutes; the rest of the peak tends to self-correct as active drivers redistribute in response to in-progress requests.

The weekly follow-up query: 'For last week, show me the completion rate for the first slot of each peak — 7:30 to 8:00 a.m., 12:30 to 1:00 p.m., and 5:30 to 6:00 p.m. — compared to the four-week average. For each slot, include median wait time and rejection rate. If the rate dropped more than four percentage points in any of those slots versus the average, show me the zones with the largest increase in uncompleted requests.' If the first-slot completion rate improved consistently over three weeks after implementing proactive positioning, that confirms it is working. If it didn't improve, the problem may be message timing — drivers don't have enough transit time — or that the drivers who received the message were already in a zone with sufficient demand, making the reposition opportunity cost negative. That second situation signals the historical demand map needs refreshing.

The zone, time-slot, and assignment radius diagnosis that previous articles in this series described produces the exact map of where and when the operation loses demand. Proactive positioning is the execution layer that acts on that map before the peak begins. The difference between the operator who diagnoses and acts after the peak and the one who diagnoses and acts before is structural: the first recovers useful information when the cost has already been incurred; the second uses that same information to prevent the cost from occurring. That difference doesn't require more drivers or different technology: it requires that the information already in the platform leave the reports and reach drivers at the moment they can still use it.

The operator who implements the complete cycle — historical zone and time-slot map queried weekly, positioning instructions generated with the agent the night before, sent with 20 to 25 minutes of lead time, and first-slot completion rate tracked for every peak block — has access to a revenue improvement that doesn't involve changing the fare or hiring more drivers. Peaks that previously started with a 15-minute positioning deficit begin with drivers already where demand is going to be. The passenger who requests in the first peak window gets the wait time that would otherwise only appear midway through the block. The driver who starts the block correctly positioned makes more trips per session hour. And the operator stops managing peaks reactively and begins confirming that yesterday's plan worked.