[hrabago]

No, because the cashiers handling smaller transactions finish quicker and can process more people. If you're stuck behind a guy which takes 2 minutes to check out, people in other lanes will be in their cars before you even begin checking out.

[kenjackson]

Here's a concrete example to make harabago's point clearer (since I think it is a little tricky). Imagine 9 people in line. Each person takes 1m to checkout except the first guy takes 10m. With three lines it looks like this (these are their wait times before being serviced):

   0   0   0  (first person in each line has no wait time)
   10  1   1
   11  2   2

If you sum up the total wait times you get: 27m

Now do this with a single file line with three cashiers:

   0   (first three people have no wait time)
   0
   0
   1   (only two people get processed at a time now)
   1
   2
   2
   3
   3

What you see is that one guy basically blocked one of the cashiers for the whole time, but the other two cashiers could continue to process. The total wait time: 12m

Change the numbers and you can create different factors for which the single file line is more efficient.

EDIT: Made a typo the first time on the wait times for the 3-line scenario. The wait time is actually 27m, not 25m.

[nkoren]

Good point, well made. In reality, the situation in your example of a multi-line queue is not usually as dire as your example portrays, because the delayed people in queue #1 are likely to jump ship sometime after the other two queues. have cleared. Nonetheless, this queue-jumping behaviour confuses the circulation pattern and causes congestion in the vicinity of the tills, which itself slows down the throughput. There's no doubt that a single-file call-forward queue is more efficient for both the customers and the shop.

One point I didn't see made in the article: single-file queues are also a fair amount more space-efficient, which has value to retailer that is separate from the issue of throughput. This spatial opportunity cost is something that also needs to be considered when designing a queuing system.

I've seen subtle & sophisticated studies which do say that customers prefer multi-line queues to single-line queues, but I rarely see any that bring the other factors into play. Retailers really should base their decisions on the following formula:

average revenue per customer * (% improved customer throuhgput - % of customers you'll lose because of multi-line queues) + extra retail m^2 * average revenue per m^2

In most cases, you'll find that that the value of a single-line queue is a good deal greater than the value of a multi-line queue. So this is one of those cases where it's likely a good idea to not cater to customer preferences.

(I'll also note that single-line queues are much more common here in the UK than in the US; I've become quite accustomed to them and in fact dread multi-line queues and the inevitable idiots that I get stuck behind in them. It seems likely to me that a large part of the American aversion to them is simply a bias against the unfamiliar; this is likely to subside as they become more accustomed to it.)

[ScottBurson]

The problem with your first example is that in real life the queues will rebalance. The two people behind the first guy won't just stand there for 10 minutes with the other two checkouts empty; they'll switch lines.

If they do that, they'll each wait for 3 minutes, giving the same distribution as in the single line.

Ah, you say, but what if other people have entered those lines already? Then you have to count their wait times too, which will be shorter in the three-line case than the one-line case.

Using one line doesn't reduce the mean wait time; it's always the number of people waiting divided by the throughput. What it reduces is the variance in wait times, making the system more fair.

[kenjackson]

Sure, if the line perfectly rebalances then three lines is almost identical to the single line.

BUT as I'm sure you know, it's sometimes hard to know when to move. Is it after you've waited one minute, then hop to the back of another line?

Let me give you a concrete example: Imagine you enter a line with 15 people in it. Your line moves 14 people through perfectly. You're next, but the guy in front of you takes longer -- maybe he can't make up his mind about wanting some bubble gum. Do you hop to the back of another line and wait 15 more minutes (because the average queue length is 15m) or do you wait it out while this guy in front of you goes? How long will this guy take? 1 more minute or 30 minutes?

And of course, once you hop to the back of another line, the guy from your previous line finishes, and there's someone else in your new line who takes forever. Then you're even more upset that you switched lines!! :-)

With a single line you remove the need for an oracle, which you need for the n-line scenario.

[philwelch]

To add to your examples, there's also the case that you've already unloaded your cart, but the idiot in front of you sends the cashier on a wild goose chase to get cigarettes for him and they spend ten minutes sorting that out. Or you're behind some "extreme couponer" who splits their order into six separate orders to maximize their coupon savings, and you have to resist the urge to just pay for their entire order just to shame them into being less of a goddamn miser.

[Natsu]

And then you CAN'T leave the slow line because there are people boxing you in from behind, even though you chose this line because the guy ahead of you had only one item... until he decided to make the cashier search the entire store to make sure they were actually out of his favorite cigarettes.

[djepik]

Perfect. You've even touched on the sunk cost fallacy which plays into one's mind in a slow line like you've described.

[tgrass]

This is theoretically appealing but the data does not always back it up: http://blog.mrmeyer.com/?p=4646