Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Queueing Theory — Why the other lines always seem to move faster than yours (flowingdata.com)
49 points by hugoahlberg on Dec 25, 2010 | hide | past | favorite | 15 comments


I remember discussing this in operations class. If I recall correctly, the biggest issue with the single line approach is one of perception. Customers see a really, really long line and decide to skip shopping at a location. Despite the fact that this is more efficient allocation mode of checkout "supply" for the checkout "demand".

I believe Disney may have put some effort in masking the length of the single line to address this issue. Might be something that grocers could learn.

A couple factors, though, would seem to undermine grocers' incentives to change their queuing approach:

One is the need to maximize inventory on the sales floor. They would need to do a lot of reconfiguration to handle the single line. And that might potentially reduce floor space for stock.

The other issue is that grocery stores fill a core human need: food. We're going there regardless of the line configuration.

I'll bet some grocer out there could make a name for themselves by shaking up the traditional ways we shop. This queuing idea is one example. Would be a smart move in fairly commoditized industry..


I'll bet some grocer out there could make a name for themselves by shaking up the traditional ways we shop. This queuing idea is one example. Would be a smart move in fairly commoditized industry..

Great comment, but I'd want to ask a few questions before committing to a start-up :-) One conjecture is that grocers aren't in the sales business, they're in the real estate business. They make their money by renting shelf space to major brands and the rest of the groceries are just there to get the customers to visit the shelves owned by their tenants.

They certainly would like anything that gets more customers to shop, but if the conjecture holds, the perception of a convenient check-out is far more important than its actual efficiency.


That only holds up in so far as perception is out of whack with reality, and on the long term too.

If store A uses a multi-headed single queue and store B uses multiple queues, eventually it's going to dawn on you that some days in store B you get in and out very quickly, but on other days you get caught up behind a bunch of slowpokes. Meanwhile, in store A, you never get those bad days, because the parallelism of the front of the queue ensures there's always some progress.

Most of the grocery shops I go to either have a single teller (so it doesn't make a difference), a single queue with multiple tellers at the head (most Tesco Express etc.), or a choice of multiple queues or single queue with multiple heads (pretty much all large supermarkets have multi-headed queues for the automated tellers, though it's usually too awkward to buy more than a basket's worth of groceries there). When there's a choice of queue, the multi-headed queue is usually longer than the single-headed queue, though not quite in proportion to its extra expected speed (it's perhaps 75% of what you'd expect), but on the other hand, these queues are sometimes slower because of the inexperience of the people using the automated systems.


Trader Joe's has a single queue with multiple registers.

They do plenty of other "shaking up traditional ways we shop", or at least their marketing folks would have you believe.


"Trader Joe's has a single queue with multiple registers."

Wish they did that in Phoenix/Scottsdale.


the whole foods in union square NYC was using a multiple register, multiple lines feeding those registers, using an employee as gatekeeper of 'who' got to be next between the 6 lines.

From a customer point of view, it looks like you are standing in a short line (and kinda have to due to limited space in NYC). but it's basically managed by a person to be a single queue to multiple registers.


tl;dr; Out of 3 lines, yours will be the fastest only ⅓ of the time.


It will also be the slowest only 1/3 of the time, so in fact this isn't an explanation why "the other lines" seem to be faster.


I think the effect is the result of fixating on the fact that there was a faster line, not that there are slower lines.


I'm interested whether that would mean that Monty Hall problem solution can be applied here and whether switching lines would actually improve your chances for being in the fastest line.


Interesting, Fry's electronics does exactly this. They have one line which feeds into n registers.


In Walmarts in Mexico there are many 20 items or fewer registers; these are all fed by a single line. At busy stores during busy times these single lines can extend well over 100m. People complain about the long lines, but they do move quickly -- well, as quickly as anything moves here.


I've wondered about the effectiveness of these "express" lanes.

What's the biggest time sink? Ringing up items? Payment processing? Bagging?

I think it's payment, unless there are a lot of items, and/or the casiher is the one doing the bagging as well.

Many cashiers can pull through dozens of items pretty quickly, faster than it takes for the customer to dig up the right card or find the checkbook, and then some ID, etc.

It may be best to just pick the line with the fewest customers regardless of whether any line is supposedly express, unless the cashier is also the one doing the bagging.


I've wondered as well.

I worked as a cashier in a grocery store when I was in high school. At our store we had two "main" express lines, one for twelve items or fewer, one for eight. Except for very quiet times, when there was only one cashier on duty, the twelve item line was open and the eight item line wasn't. (Any of the other lines could also be turned into express lines by setting a switch at the register, but they were less clearly marked, so lots of customers didn't notice them. They were only rarely activated.)

Your intuitions square with mine: payment was usually the biggest time sink, especially with checks and cards. Still, there were plenty of sources of variation: some items were hard to scan quickly, some customers had more produce that needed to be weighed, sometimes an item wasn't in the database or there was a dispute about its price and it needed to be checked, some lines had baggers--excuse me, service clerks--and some didn't.

And, of course, some cashiers were just faster than others. Interestingly, there was no clear pattern here. Experience (having produce codes memorized, knowing how to scan tricky items or even having their UPC codes memorized, and being good at counting cash quickly and accurately) played a role. Mostly, however, people seemed to be intrinsically motivated to do their work well, or else they weren't. We high school kids weren't collectively faster or slower than the "old people."

Some customers were faster than others too: cash payment was definitely faster than card, and both were much faster than check. (This was 15 odd years ago; card is likely faster than it used to be, but likely still slower than cash.) Some customers insisted on paying with exact change, and many of them would take their sweet time doing so. Also, some customers would come with lots of coupons, which would take time to scan.

My hunch at the time was that we'd have gotten better throughput by keeping the eight item line open, cash-only, no coupons. I think I was probably right, given the constraints: we were going to have an express line, regardless of whether it was really more efficient or not. Might as well optimize it.

Now, I think that several feeder lines would be more efficient. Maybe just two (express and regular), maybe three or four (although I distrust people's honesty as well as their ability to count).

http://blog.mrmeyer.com/?p=4646 has shown up on HN at least twice, and it's worth reading.


That time were there was an onslaught of erlang articles on HN there was one called something like "Erlang the movie", for some reason Erlang telephony videos make me happy :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: