All Articles Case Study

Cutting Pickup Wait Times: What the Data From Our Pilot Shows

Gabriela Matos
Visual showing wait time reduction concept with abstract time and flow elements

This post is about numbers. Specifically, the wait-time numbers from three stores in the Sao Paulo metro that ran PickNGo for 60 days starting in early 2026. We're sharing the data because we think the pattern is instructive, and because an honest account of what changed, and what didn't, is more useful than a cleaned-up headline.

The three stores: a mid-size electronics and home goods retailer in Vila Madalena, a grocery chain branch in Moema with a dedicated curbside pickup lane, and a sporting goods store in the ABC region that handles both in-store pickup and same-day courier dispatch. Different formats, different volume profiles, and different baseline conditions when we started. That variety is part of why the aggregate results are meaningful.

Baseline: What We Measured Before Go-Live

We measured average pickup wait time as the interval from order confirmation (POS event) to courier departure confirmation (staff action in the dispatch view). That definition captures the full customer-facing delay, including picking time, queue wait, and counter handoff. It's the number that shows up in customer satisfaction feedback.

Baseline averages across the three stores, measured over two weeks before go-live: 17.4 minutes during the 12-to-2 lunch window, and 11.2 minutes during the 5-to-7 evening window. The lunch window was consistently worse because order volume peaked and courier availability dipped simultaneously. The evening window benefited from higher courier density but suffered from a different problem: large-format orders (bicycles, appliance accessories) that slowed counter throughput.

We also measured queue incident count, which we define as any shift where the pending order queue exceeded 10 items for more than 5 consecutive minutes. During the baseline period, the lunch window averaged 4.2 queue incidents per week per store.

What Changed in the First Two Weeks

The first two weeks were noisier than we expected, and we want to be honest about that. Staff were learning a new queue interface, courier signals were calibrating to store-specific proximity distributions, and one store had an API timing issue with their POS that we resolved on day 8. The aggregate wait-time average for week one was actually slightly higher than baseline at two of the three stores.

By the end of week two, the Moema grocery location showed the first clear signal: lunch-window wait time dropped to 9.1 minutes, down from a 16.8-minute baseline. The mechanism was exactly what we expected. Their curbside lane had been consistently losing couriers to idle-wait: a courier would arrive, find the order not yet bagged, wait 4 to 6 minutes, then leave to take another job. The ranked queue prevented that by ensuring orders were only assigned to incoming couriers when bag status confirmed ready. Courier retention at the curb went from roughly 55% to over 90% in that two-week window.

The Vila Madalena electronics store showed more gradual improvement. Their baseline problem was different: they had adequate courier retention but slow decision-making at the counter. Their operation lead told us the ranked list cut his dispatch decision time from roughly 90 seconds per order to under 15. That doesn't sound dramatic in isolation, but at 18 orders during a busy lunch hour, it frees up 22 minutes of active decision time that now goes into exception handling and customer interaction.

The 30-Day Numbers

By day 30, all three stores had cleared below 6 minutes average for the lunch window. The Moema location was at 3.8 minutes. The Vila Madalena store was at 5.4 minutes. The ABC sporting goods store, which had the most complex order mix, was at 5.9 minutes.

Queue incidents dropped across all three. The Moema location had zero qualifying queue incidents in weeks three through eight. The ABC store still had occasional incidents on Saturdays when large-format order volume spiked, which is expected: the dispatch layer can't accelerate picking for a bicycle that needs assembly.

Courier utilization, which we measure as the percentage of courier arrivals that result in a same-visit pickup, improved by 31 percentage points on average across the three stores. That's the number that most directly ties to operational cost: a courier who picks up on arrival is a courier you've retained for your next order.

What the Data Doesn't Show

We're not claiming this data proves anything about stores we haven't worked with. Three locations over 60 days is a pilot cohort, not a controlled study. The stores self-selected for the early-access program and had motivated operations leads who engaged actively with the setup. Those conditions favor good results.

The data also doesn't capture everything that matters. Customer satisfaction feedback is a lagging signal and we don't have pre/post NPS splits that are clean enough to publish. Revenue impact from reduced walk-offs is real but indirect. We have anecdotal accounts from operations leads about fewer complaint calls in the weeks after go-live, but that's not a number we can stand behind rigorously.

What we can say with confidence is this: for stores that have adequate courier coverage and a reasonably functional picking operation, the dispatch sequencing layer removes a specific class of wait-time waste, and it does so in a way that shows up in measurable numbers within two to three weeks.

What We're Doing with This Data

The pilot results are feeding back into the priority scoring model. The Moema location's courier-retention pattern, in particular, showed us that the courier ETA signal was under-weighted in our initial configuration. We've since adjusted the weight for stores where curbside courier retention is the primary bottleneck, and we're building a configuration interface that lets operations leads tune that weight without contacting us.

We're also tracking queue incident frequency as a leading indicator for POS integration health. The day-8 API timing issue at one pilot store showed up in the queue incident count two days before the operations lead flagged it to us. That kind of early signal is exactly what we want the system to surface automatically, not wait for a human to report.

If you're running a pickup operation in the Sao Paulo metro and want to see the full dataset, we're open to sharing it under a mutual non-disclosure framework. The store names are masked but the daily time-series is complete.