When we started getting interest from grocery delivery operations, I had to be honest about what we built and what we didn't. Routely's core engine was designed for regional carriers delivering packages — a stop is a stop, it has an address, it has a time window, and you sequence them to minimize total drive time. Grocery delivery has that, plus several layers of constraints that most route optimization products simply ignore.
Working through the grocery-specific problems has been clarifying. Some of the constraints translate directly to our model. Others required changes to how we represent a stop and what the optimizer considers when building sequences. And a few constraints reveal genuine limits in the route-optimization framing that no amount of algorithm tuning can fix without deeper operational integration.
The batching problem that precedes routing
In package delivery, routing starts from a fixed manifest: here are N stops, build the best route. In same-day grocery delivery, there's a step before routing that fundamentally shapes what routes are even possible: order batching. Which customer orders get grouped into which delivery load, and which load goes on which vehicle at what departure time?
Batching decisions are made under time pressure and uncertainty. Orders arrive throughout the morning, picking happens in parallel, and departure times are driven partly by order readiness and partly by customer time windows. A customer who requested an 11 AM–1 PM window needs to be in a load that departs early enough to reach their address by 11 AM; a customer who requested 2 PM–4 PM can be in a later load. But if you have 40 orders in a tight residential neighborhood and batch them into four loads of 10, you might find that no individual load has efficient route density — too many back-and-forth crossings.
Standard route optimization software is handed the batch after it's been assembled and asked to build an optimal sequence within it. If the batch was assembled poorly — wrong mix of addresses, incompatible time windows, too few or too many stops per load — the optimizer can sequence those stops efficiently, but it can't undo bad batching.
For grocery operations running at scale, the batching layer is as important as the sequencing layer. We're currently working on tooling that informs batching decisions using route density data — essentially giving the dispatch team a way to see, before batching is finalized, how efficiently different groupings of orders will route. It's not fully built yet, but it's the right direction.
Temperature constraints change the sequencing math
Perishable goods add a constraint that doesn't exist in standard package routing: cumulative time at risk. A frozen item that goes out on an 8-stop route has a different risk profile depending on whether it's delivered second or eighth. In the heat of an Ohio summer — and central Ohio gets genuinely hot in July, with temperatures reaching 90°F or above — insulated bags have a finite effectiveness window, particularly for ice cream, raw protein, and frozen prepared foods.
This creates a preference ordering among stops that isn't purely about geography: perishable-heavy deliveries should happen early in the route sequence, even if that's not the most geographically efficient path. The trade-off is measurable in extra drive time versus food quality risk, and it depends on the specific items in each delivery.
The cleanest implementation passes item temperature class as stop-level metadata to the routing engine, which can then treat perishable-dominant stops as constrained to early positions in the sequence. This is an adjustment to the optimization objective — not just minimize drive time, but minimize drive time subject to perishable stops appearing before stop N in the sequence where N is calculated from departure time and estimated transit duration.
We're not saying every grocery delivery operation needs this level of precision — operations running refrigerated vehicles with full cold-chain management throughout the delivery cycle have more latitude. But ambient-temperature van operations using insulated bags absolutely need to account for it, and most route optimization tools don't have a mechanism to express it.
Short time windows create a different failed-delivery cost structure
Package delivery often has wide time windows: "delivered between 8 AM and 6 PM" is standard for many B2C shipments. Grocery delivery operates on 2-hour windows that customers selected specifically because they'll be home during that window to receive temperature-sensitive items. A missed window isn't just a failed delivery attempt that gets rescheduled — it's a customer who was present, waiting, and now has to reorder or pick up themselves.
This changes how you should think about route sequence flexibility. In package routing, you have latitude to re-sequence stops aggressively when traffic conditions change, because a package arriving 45 minutes late within a 10-hour window is still fine. In grocery routing, re-sequencing that pushes a stop past the customer's 2-hour window creates a failure regardless of how well it optimized the rest of the route.
The implication is that grocery routes need tighter feasibility checking at every re-sequencing pass. Before the optimizer proposes moving a stop later in the sequence, it needs to verify that the new estimated arrival time still falls within the customer's window. This sounds simple, but it interacts badly with real-time traffic updates: a traffic incident that delays the whole route may make some early-window stops infeasible regardless of re-sequencing, and the system needs to surface that to dispatch immediately rather than after the driver is already running 45 minutes late.
Dwell time estimates are different from package delivery
Dwell time — how long a driver spends at each stop — has a consistent distribution in package delivery: hand off the package, get a POD signature or photo, done in 60–120 seconds for most residential stops. Grocery delivery dwell time is longer and more variable. Drivers carry insulated bags through an entryway, often placing items inside a door or in a designated spot, dealing with customers who want to inspect their order or ask questions about substitutions. Typical dwell time ranges from 3–8 minutes.
That 3–8 minute range matters for route feasibility. On a 12-stop grocery route, the difference between 3-minute and 8-minute average dwell time is 60 minutes of route duration. If your routing engine uses a fixed 90-second dwell time assumption borrowed from package delivery, your route time estimates will be systematically short by 30–90 minutes, and time windows that looked feasible at dispatch will start failing before the route is half complete.
We updated our dwell time model to accept product-class and delivery-type as inputs when estimating stop duration. Grocery residential gets a default 5-minute dwell estimate with variance. Carriers that have their own historical dwell data can calibrate this further — if your actual median grocery dwell is 4.2 minutes based on six months of in-app timestamps, use that number and your route duration estimates will be meaningfully more accurate.
What standard route optimization gets right — and wrong
Standard route optimization for grocery handles the geography problem fine. Given a set of addresses and time windows, sequencing to minimize drive time is the same problem regardless of whether the cargo is packages or produce. The algorithms that work for general last-mile delivery work here too.
What standard route optimization misses is the constraint stack above the sequencing layer: batching quality, perishable sequencing preference, dwell time calibration, and the stricter feasibility requirements of narrow time windows. These aren't edge cases in grocery delivery — they're the main operational challenges.
For a regional grocery delivery operation running 15–40 routes per day out of one or two fulfillment locations, the right approach isn't a purpose-built grocery-only routing platform. It's a routing engine that can be configured with grocery-specific constraints — temperature class, per-stop dwell calibration, hard time window failure detection — combined with a dispatch workflow that surfaces batching quality before loads depart.
That's the direction we've built toward for the carriers using Routely in grocery contexts. We're honest that our batching tooling is still developing. The sequencing and constraint model for grocery is solid; the pre-routing batch optimization layer is a work in progress. Carriers who've deployed with us in grocery contexts know where the current boundaries are, and we're direct about that rather than overstating what the current version does.
The operational reality of same-day
Same-day grocery delivery runs on much tighter operational margins than next-day package delivery. There's less buffer to absorb a bad route plan or a driver who takes a wrong sequence. The unforgiving nature of the time windows, combined with the cost of failed deliveries in a category where customers are paying for convenience, means that route quality differences show up faster and more clearly in operational metrics.
This is actually useful from a product development standpoint. When we can see within a day whether a constraint model change improved on-time delivery rate, the feedback loop is short enough to learn quickly. The grocery use case has pushed Routely's constraint modeling further in six months than two years of standard carrier deployments would have.
