How GreenCart Cut Last-Mile Delivery Costs by 34% With AI Route Optimization

By mid-2024, GreenCart had become one of India's fastest-growing D2C grocery platforms, operating across 18 cities with a promise of sub-90-minute delivery. Behind that promise was a logistics operation that had grown haphazardly — route planners still relied on static Excel heuristics, delivery partners were assigned zones manually, and real-time traffic, weather, and order-density patterns were largely ignored. The result was a fleet running at 68 percent utilization, escalating fuel costs, and a customer satisfaction score that had slipped from 4.6 to 3.9 stars in six months.

This case study chronicles how GreenCart's engineering and operations teams — led by CTO Meera Iyer, Head of Logistics Arjun Desai, and Data Science Lead Priya Nair — replaced a broken dispatch system with an AI-driven route optimization engine. It is a story about messy legacy infrastructure, the politics of operational change, and how a small, focused team delivered a 34 percent cost reduction in under 20 weeks.

Company and Product Overview

GreenCart is a Bengaluru-based D2C grocery platform founded in 2021. It sources fresh produce, pantry staples, and household essentials directly from farms and manufacturer partnerships, then fulfills orders through a network of dark stores and last-mile delivery partners. The company serves urban and semi-urban households across South and West India, with a stated mission of making fresh groceries affordable and accessible within one hour.

At the time of this intervention, GreenCart operated 42 dark stores, managed 1,200 delivery partners through a mix of full-time and gig workers, and processed roughly 85,000 orders per week. The tech stack was a patchwork: legacy Node.js microservices for order management, a React-native app for delivery partners, and a PostgreSQL-backed dispatch system that had not been meaningfully updated since 2022.

The Challenge

GreenCart's logistics challenges were not a single broken feature — they were a systemic failure to keep pace with the company's own growth:

1. Static route planning. Dispatchers used a rule-based system that assigned delivery partners based on fixed zones and FIFO (first-in, first-out) queue logic. The system had no concept of real-time traffic, order clustering, or delivery-partner location. A partner might be sent three kilometers away for a single small order while larger, time-sensitive orders backed up elsewhere.

2. Poor fleet utilization. Delivery partners returned to hubs with empty bags 32 percent of the time, and many routes were scheduled with only one or two deliveries per trip. Fixed costs — vehicle allowances, insurance, onboarding — were spread across too few deliveries, driving up cost per order.

3. Missed SLAs in dense cities. In Mumbai and Pune, where traffic conditions are volatile and order density is highest, GreenCart failed to meet its 90-minute SLA on 18 percent of orders during peak hours. Customer complaints about late deliveries were the top reason for churn in the app-store reviews.

4. Reactive exception handling. When a delivery partner cancelled or a vehicle broke down, the operations team manually reassigned orders through phone calls and WhatsApp groups. This was slow, error-prone, and nearly impossible to scale beyond a handful of cities.

5. No predictive demand modeling. Because the dispatch system lacked demand forecasting, dark stores were either overstocked or understocked on high-velocity SKUs, leading to both wasted inventory and substitution complaints from customers.

Goals and Success Criteria

The leadership team defined four quantitative goals for the logistics overhaul, with a 20-week deadline and a fixed engineering budget of three backend engineers, one data scientist, and one ML engineer:

1. Reduce cost per delivery by ≥ 30 percent within six months of full deployment.
2. Improve SLA adherence to ≥ 95 percent for all metro cities during peak hours.
3. Increase fleet utilization from 68 to ≥ 80 percent, measured by deliveries per partner per shift.
4. Cut manual intervention in dispatch by 80 percent for plan-ahead orders (orders placed more than 45 minutes before delivery window).

The goals were deliberately constrained. Rather than embracing an open-ended platform rebuild, the team treated the project as a focused dispatch-engine replacement — an approach that kept the scope tight enough to hit the deadline and the risk manageable enough that leadership would not pull funding halfway through.

Approach: From Static Rules to Probabilistic Optimization

The team rejected two tempting alternatives out of hand: importing a third-party fleet-management SaaS (too expensive, too generic for GreenCart's dark-store model) and rewriting the entire logistics stack from scratch (too slow, too many dependencies). Instead, they adopted an approach they called "probabilistic dispatch" — a targeted engine that sits on top of the existing order-management system, ingests real-time signals, and assigns orders to partners using a cost-minimization objective function.

Phase 1: Data Infrastructure and Signal Mapping (Weeks 1–3)

Before building any model, the team spent three weeks simply understanding what data was available and what was missing. They instrumented the delivery-partner app to stream GPS coordinates every 15 seconds, captured order timestamps and dark-store locations, and ingested Mumbai Traffic Police's open API for real-time congestion data. Weather data from the Indian Meteorological Department was added to account for monsoon disruptions.

The critical insight from this phase was that GreenCart already had most of the data it needed — it was just siloed in Postgres tables, Firebase event logs, and WhatsApp chat histories. Consolidating it into a single analytics warehouse (BigQuery) took two weeks and immediately surfaced patterns: peak ordering windows varied by city, delivery partners clustered inefficiently near popular hubs, and 40 percent of late deliveries could be traced to a single traffic corridor that planners had never mapped.

Phase 2: The Optimization Model (Weeks 4–8)

Priya Nair built a custom vehicle-routing model using OR-Tools, Google's open-source optimization suite. Rather than solving the academic traveling-salesman problem in its full complexity, she framed the routing as a capacitated vehicle routing problem with time windows (CVRPTW) — a formulation well-suited to grocery delivery, where each partner has a limited bag capacity, fixed shift times, and customer-facing delivery windows.

The objective function minimized a weighted combination of: delivery cost per kilometer, time-window violation probability, and partner idle time between assignments. The team deliberately excluded "fairness" metrics (e.g., equal订单分配 across partners) from the objective because early A/B tests showed that purely cost-optimal routing also produced higher partner earnings, which correlated with retention.

Model outputs were validated against two months of historical dispatch data. The optimized routes would have reduced total fleet kilometers by 27 percent while improving SLA adherence by 11 percentage points — a promising result that convinced leadership to greenlight the integration phase.

Phase 3: Integration and Incremental Rollout (Weeks 9–16)

Rather than switching all cities at once, the team deployed the new engine in a single tier-2 city (Coimbatore) with 8 dark stores and roughly 120 delivery partners. This "minimum viable rollout" served as a live stress test: the model had to handle real cancellations, real weather events, and real partner behavior without a safety net of manual overrides.

The integration itself required building an adapter layer between the existing Node.js dispatch service and the new Python-based optimization engine. Arjun Desai chose a strangler-fig pattern: incoming order events were duplicated to a new Kafka topic, the optimization engine consumed that topic and emitted route assignments to another topic, and a lightweight consumer applied those assignments back into the legacy database. This meant the old system remained the source of truth while the new engine proved itself in production.

Three significant problems emerged during the Coimbatore rollout:

• Partner non-compliance: Delivery partners ignored suggested routes 18 percent of the time, preferring familiar paths. The team responded by adding a "confidence score" to each route suggestion; routes with scores below 0.7 triggered a lightweight notification rather than a hard assignment, giving partners agency while still nudging them toward optimal paths.
• Demand spikes: A local festival caused a 3.2× normal order volume on a single day. The model timed out on the full-city optimization because the problem size exceeded its 30-second solve limit. The team implemented a fallback heuristic that partitions the city into quadrants and solves each independently when total orders exceed a threshold.
• Cold-start problem: New delivery partners with insufficient trip history were poorly predicted by the optimization model. The team introduced a default "exploratory zone" assignment for partners with fewer than five completed trips, allowing the system to learn their patterns before fully integrating them into the optimization loop.

Phase 4: Scaling Across Cities (Weeks 17–20)

After two weeks of stable operation in Coimbatore — fleet utilization up 12 percent, cost per delivery down 21 percent, SLA adherence up 9 points — the team began rolling out to larger markets. Mumbai, the highest-complexity city, was deployed last, after Pune and Hyderabad had already validated the model in denser environments.

The Mumbai rollout required one unplanned adjustment: the model initially failed to account for the city's local train network, which some delivery partners used to cross the breadth of the city quickly during peak hours. Once the team added "metro station" as a valid transfer node in the road graph, routing efficiency in Mumbai improved by another 6 percent.

By week 20, the engine was live in all 18 cities, processing roughly 85,000 order assignments per week with a mean solve time of 1.2 seconds per batch.

Implementation Details

The production architecture had four main components:

• Ingestion layer: Apache Kafka streams for order events, partner GPS, traffic APIs, and weather data. All streams were windowed into 60-second batches for the optimizer.
• Optimization engine: A Python service wrapping Google OR-Tools, deployed on GCP Cloud Run with a 5 GB memory limit and a 30-second timeout. The service exposed a single REST endpoint: POST /optimize with a payload of unassigned orders and available partners.
• Assignment adapter: A Node.js microservice that consumed optimization outputs and wrote assignments back to the legacy Postgres database, preserving backward compatibility with the existing driver app.
• Dashboard and monitoring: A custom Grafana dashboard tracking fleet utilization, cost per delivery, SLA adherence, and model solve time. Alerts fired when any metric deviated more than 10 percent from its 7-day rolling average.

Data quality was the unsung challenge. The GPS stream from delivery-partner phones was noisy: 8 percent of coordinates were off by more than 200 meters due to poor signal in dense urban areas. The team applied a lightweight Kalman filter to smooth trajectories before feeding them into the optimizer, which reduced spurious detours and improved route stability.

Results

Sixty days after full deployment, the results across the four primary goals were:

Cost per delivery. The metric fell from ₹42 to ₹28 — a 33.3 percent reduction. The single largest driver was reduced fleet kilometers (down 28 percent), followed by fewer failed-delivery attempts (down 19 percent) and lower fuel consumption (down 24 percent).

SLA adherence. Metro-city on-time delivery improved from 82 to 96 percent. The remaining 4 percent of failures were attributable to partner-side delays and warehouse dispatch lags, not routing errors. The operations team used the new visibility to identify two slow dark stores and restaffed their picking teams, bringing the metro SLA to 97 percent by month three.

Fleet utilization. Deliveries per partner per shift rose from 6.8 to 9.4 — a 38 percent increase. Idle time between assignments dropped from 42 minutes to 19 minutes per shift. Notably, partner churn also decreased by 12 percent, presumably because higher utilization translated to higher daily earnings.

Manual intervention. For plan-ahead orders (those placed more than 45 minutes before the delivery window), 88 percent were fully auto-dispatched with zero human involvement. The remaining 12 percent were flagged by the confidence-score system and handled by a three-person operations pod rather than the previous ad-hoc WhatsApp group of 12 people.

Key Metrics at a Glance

• Cost per delivery: ₹42 → ₹28 (-33 percent)
• SLA adherence (metro peak): 82% → 96% (+14 points)
• Fleet utilization: 68% → 85% active delivery time (+17 points)
• Deliveries per partner per shift: 6.8 → 9.4 (+38 percent)
• Partner churn: Down 12 percent
• Manual dispatch interventions: Down 88 percent
• False-reassignment rate: Under 2 percent, down from 15 percent
• Customer satisfaction (app store): 3.9 → 4.5 stars

Business Impact

GreenCart's CFO validated the improvement against unit economics: the cost reduction added roughly ₹2.1 crore in annualized EBITDA at the existing order volume. More importantly, the freed-up operational capacity allowed the company to enter three new tier-2 cities in Q2 2025 without increasing the headcount of the logistics operations team — a strategic expansion that would have required at least 12 additional hires under the old model.

The partner experience improvement also reduced acquisition costs. GreenCart's referral bonus program for delivery partners, previously underutilized because earnings were unpredictable, saw a 40 percent increase in referrals after utilization rates stabilized. The company now fills partner slots in new cities through internal referrals rather than paid recruitment channels.

Lessons Learned

1. Scope discipline beats platform ambition. The team could have proposed a full logistics-platform rebuild. Instead, they treated the dispatch engine as a bounded problem that could be solved, tested, and deployed independently. That decision — to optimize the routing decision rather than the surrounding ecosystem — was what made the 20-week deadline credible.

2. Production rollout beats perfect simulation. The Coimbatore pilot was messier than any dry-run would have been. Partner non-compliance, demand spikes, and GPS noise all surfaced only in live traffic. But dealing with them in a city of 120 partners, where the blast radius was small, was infinitely cheaper than discovering them during a Mumbai-wide cutover.

3. Partner behavior is a first-class constraint. Early versions of the model optimized for pure cost minimization and produced routes that partners actively resisted. Adding a confidence threshold and a fallback exploratory zone turned the model from a dictatorial planner into a collaborative assistant. Human-in-the-loop design was not a compromise — it was the feature that made the system work.

4. Data hygiene is 80 percent of the job. The Kalman filter for GPS smoothing, the BigQuery consolidation, the traffic-graph enrichment for metro stations — none of these were glamorous, and none appeared in the final product pitch. But without them, the optimizer would have produced overconfident, brittle routes that failed unpredictably. The unglamorous preprocessing layer was the real product.

5. Metrics must be standardized before you optimize them. The team spent the first three weeks auditing dashboards and agreeing on definitions — not because they loved analytics governance, but because they knew that without a shared definition of "cost per delivery," they could not prove improvement or defend the budget. The metric audit was the unglamorous prerequisite that made the rest of the project defensible.

What Comes Next

GreenCart's leadership has already approved a second phase: demand forecasting at the SKU level to reduce substitution rates and improve dark-store inventory turns. The data infrastructure built for the dispatch engine — Kafka streams, BigQuery warehouse, Grafana monitoring — is being reused as the foundation for that next project. The team's bet is that the same discipline — bounded scope, incremental rollout, production-tested data pipelines — will deliver another step-change in operational efficiency by the end of 2025.