General Information
Project name: Automation of courier resource planning in a delivery service.
Period: March 2025 — September 2025 (pilot deployment).
Team: LamArt — 1 mathematician, 1 data engineer.
Project type: Product development: research, prototyping, and deployment of an automated courier shift scheduling system.
Context and Background
Initial situation. A pizza chain (~100 locations, ~300 couriers) with in-house delivery. Courier scheduling balances two opposing requirements: too few couriers — orders take longer, customers abandon due to wait times; too many couriers — work is diluted, each earns less (payment per delivered order). Logistics planners manually balanced couriers across zones and shifts based on experience.
Reasons for launching the project. Manual planning did not scale — it grew with order volume and hit a ceiling before the service itself. Planners spent several hours building schedules, did not account for courier preferences or ratings, leading to no-shows on confirmed shifts.
Goals and objectives. Translate demand forecasts into courier requirements using a unified rule; assemble schedules automatically, leaving validation to the planner; reduce no-shows on confirmed shifts; maintain shift cost within delivery quality constraints.
Expected outcomes. Automated schedule generation; a unified requirement calculation rule; reduced no-shows; scalability to new cities.
Implementation Process
Key stages.
- Demand forecasting. A time series model predicts order volume two days ahead by logistics zone and hour. Forecast accuracy ~10% MAPE. Recalculated daily.
- Orders to couriers. Queueing theory with a finite queue and finite waiting time (customer leaves when waiting time expires). Business constraints are specified: target average delivery time and acceptable share of undelivered orders. Historical data provides average delivery time per zone and no-show rate.
- Shift assignment. Stable matching problem — a modification of the Gale-Shapley algorithm. On one side: time slots. On the other: couriers with ratings and stated availability preferences. Couriers receive invitations and confirm; unfilled slots go to a second pass.
- Shift cost estimation. An ML regression model estimates payouts given the number of orders and assigned couriers. Features — all historical payout data in various aggregations (rolling windows, etc.). The cheapest option satisfying delivery quality constraints is selected.
- Validation. The schedule is approved by a logistics planner. The business sets parameters explicitly: target delivery time and acceptable undelivered order share.
Technologies used. Python, ClickHouse (historical data storage and aggregation), time series, regression model, Gale-Shapley algorithm, queueing theory.
Methodology. Stable matching with party preferences; queueing theory with finite waiting time; ML regression for cost estimation; explicit business parameters replacing implicit planner experience.
Challenges and obstacles.
Results and Conclusions
Actual results. Deployed to ~100 pizzerias, ~300 couriers in pilot operation.
Deviations from plan. Originally planned direct shift cost calculation, but due to dependency on an external order distribution algorithm, an ML proxy model had to be built.
Qualitative indicators. The trade-off between shift cost and delivery quality is set explicitly through two business parameters, not by intuition. Courier preferences and ratings are accounted for systematically, reducing no-shows.
Lessons Learned and Recommendations
Key successes. The framing "a courier is not a resource unit but a party with preferences" changed the approach: stable matching instead of classical demand coverage reduced no-shows by 20% without additional cost. Explicit business parameters (delivery time, undelivered share) allowed the business to manage the cost-quality trade-off directly, without developer involvement.
Challenges overcome. ClickHouse turned out to be the primary source of complexity — not algorithms, but data infrastructure. Investment in analytics infrastructure paid off multiple times: rolling windows, aggregations, and historical data became the foundation for forecasting, the ML model, and monitoring.
Recommendations for future projects. Build analytics infrastructure (ClickHouse or equivalent) from day one — without it, neither forecasting, ML models, nor monitoring work. Formalize business parameters as explicit model inputs rather than implicit planner knowledge — this gives the business a control lever and reduces dependency on specific people. Use modern tools (LLMs, vibe coding) to accelerate prototyping: what used to require reading two monographs now takes days.
Key success factors. Mathematical depth (queueing theory, stable matching) combined with practical ML (regression on historical data); a compact team (2 people) controlling the full stack from data to deployment; close collaboration with logistics planners for business parameter validation.
Case Tags
resource planning, queueing theory, stable matching, Gale-Shapley algorithm, time series, regression, ClickHouse, delivery, logistics, schedule automation
