Multi-stop route optimization that respects prayer times

Why manual planning stops working

With 10 orders a day, a supervisor can sequence stops in his head or in a WhatsApp group, and mistakes stay cheap. The trouble is that this approach does not scale: a round of just 15 stops has mathematically more than a trillion possible orderings, and no human — however experienced — can weigh them. So planners fall back on rules of thumb like "nearest first" that look sensible and quietly burn fuel and time on every single round.

Meanwhile, as Saudi Arabia's logistics sector grows under the Vision 2030 programmes, order density keeps climbing and so do end-customer expectations: a specific delivery window, a heads-up before arrival, and a courier who does not have to call and ask for directions. Stop sequencing has become a daily operational decision that deserves real tooling, not a morning improvisation that changes with whoever happens to plan that day.

The cost also has a hidden face that never shows up in fuel invoices alone: a failed delivery attempt means a second visit at full cost, an extra hour past end of shift means fatigue that accumulates into faster courier turnover, and repeated lateness means a customer who buys from someone else next time. None of this appears in the daily operations log — all of it is paid, in full, out of the month's margin.

Manual planning fails at three specific points: it never sees the whole round at once, it cannot adapt as the day unfolds, and it handles fixed time constraints poorly — and in Saudi Arabia the most important of those constraints is prayer time.

Prayer times are a real planning constraint, not a footnote

Across the Kingdom, many pickup and delivery points pause with every prayer: a warehouse stops receiving, a shop closes, a customer is at the mosque. A courier who arrives at a closed door does not just lose the minutes spent waiting — the delay cascades into every remaining stop, the day's plan collapses from the middle, and the promised arrival times become numbers without meaning.

What makes this hard is that the constraint is not static. Prayer times shift every single day through the year, and they differ between cities at the same moment — a plan that works in Riyadh does not transfer to Jeddah or Dammam. Printed timetables go stale within weeks, and relying on each courier's judgement brings you back to square one: a plan on paper and a different reality on the road.

Seasons sharpen the effect. In Ramadan the operating windows compress and peak hours flip to the evening; on Fridays, Jumu'ah prayer takes precedence over any midday delivery plan. Even within a single day you may have one team working Riyadh and another Jeddah, with the gap between the two cities' times present in every round. Managing all of this with static tables means, in practice, rebuilding the plan by hand every morning — which is exactly the work the algorithm should be doing for you.

That is why it is not enough for a system to merely "know" prayer times as information on a screen. They have to be treated as unavailable windows inside the sequencing algorithm itself — exactly like a delivery window the customer has insisted on.

How prayer-aware optimization works in Pixa

The Pixa dispatch module treats a delivery round as a multi-constraint problem solved in one pass, not a list sorted by eye. The process starts from clear inputs:

• Orders with addresses, coordinates, and required delivery windows.
• Predefined coverage zones with their boundaries and pricing.
• The couriers available and each route's capacity.
• Prayer times for every stop's location, produced by a built-in astronomical calculation from coordinates and date — no manual entry at all.

The engine then re-sequences the stops so that total distance drops and every time constraint is respected — and, critically, the closure window around each prayer is treated as a period in which no arrival may be scheduled. In practice, the plan pushes long drives between districts into the closure windows, when deliveries could not happen anyway, so the courier reaches the next stop just as doors reopen instead of idling at the kerb.

And because a good plan is only a theory until it meets the road, live tracking closes the loop: the dispatcher sees each courier's position streamed in real time and can reassign orders on the fly, while the automatic delivery monitor flags stalled orders before the customer calls. The courier, meanwhile, works from a mobile web app — OTP login, the day's tasks in sequence, and proof of delivery captured at every door.

Take a simplified example: an ordinary morning with 40 orders across 3 couriers in one city. The engine distributes orders into routes by coverage zone and each courier's capacity, then sequences every route so the longest inter-district drive falls inside the Dhuhr closure window — each courier reaching his next stop just as prayer ends. When an urgent order lands after Asr, the plan is not rebuilt from scratch; the order is slotted into the best-fitting route and only the remainder of that route is re-sequenced. The result is not a theoretical "perfect path" but an executable plan that respects the reality the courier actually moves through.

Side by side: manual planning vs. prayer-aware optimization

The table below summarizes the difference as it shows up on a real operating day, not in a sales deck:

Practical groundwork before you switch it on

Technology alone does not make a good round; input quality decides plan quality. Before running optimization at full scale, get these basics in order:

• Clean addresses: accurate coordinates for every recurring delivery point — no algorithm can fix a wrong address.
• Defined coverage zones: draw zone boundaries and set their pricing so the system knows where orders are accepted and which courier serves them.
• Realistic service time: estimate the average minutes at the door (handover, collection, signature) and feed it into planning instead of assuming instant delivery.
• Courier readiness: train the team on the driver app and on following the suggested sequence — a plan that gets ignored is worse than no plan.
• A contained pilot: start with one zone or one team, and compare a before-week with an after-week prior to rolling out everywhere.

Do not underestimate the human side either. A courier used to sequencing his own round will resist the suggested plan in the first days, especially where it contradicts his local instinct. Involve him in the pilot and listen when he says a particular street jams at a particular hour — some of those observations are inputs that improve the plan itself. The goal is not to replace field experience but to free it from the mental burden of ordering dozens of stops every morning.

Measuring the impact in numbers

Do not accept "we got faster" as an answer. Pick a small set of indicators and track them on a schedule: completed orders per courier per day, kilometers per order, on-window delivery rate, and failed delivery attempts. With the custom report builder you can assemble exactly these indicators and schedule them to arrive by email or WhatsApp without anyone having to remember, and pair them with alert rules that fire on deviation instead of discovering it at month end.

Make review a fixed rhythm: a short weekly meeting in front of the same indicators, and one actionable decision per meeting — adjust a zone boundary, rebalance a courier, correct an overestimated service time. Small continuous improvement beats any grand fix that keeps waiting for perfect conditions.

The bottom line: respecting prayer times in route planning is not a cosmetic feature on a checklist. It is a precondition for any realistic delivery plan inside the Kingdom — a plan that ignores 5 daily closure windows lies to its owner before it lies to the customer.

Want to see multi-stop optimization run on your actual orders rather than demo data? Talk to the Pixa team for a working session on a scenario from your own operation.