A drive-thru is a queue with one exit, and that single fact decides almost everything about the till that runs it. A dining room can absorb a slow order because the guest is already seated and the table is already yours for an hour. A lane cannot absorb anything. Every extra second at the window is paid for by every car behind it, and the car at the back can still leave. That is why a takeaway POS system built for counter service and delivery gets you most of the way there but not all of it, and the gap is where the money is.
The kitchen side is stranger still. Orders do not leave a lane in the order they arrived, because one car pulls forward to wait for fries while the two behind it collect and go. Any kitchen display system that assumes first in, first out will fight you all shift, and the crew will work around it with a paper cup on the counter and a good memory. That workaround holds until Saturday lunch, and then it does not.
What follows is about the two numbers people constantly mix up, cars per hour and total time, why the fix for one is almost never the fix for the other, and what to test in a system before you sign. If your off-premise question is really about marketplaces and commission rather than a lane, third party delivery covers that math instead.
Cars per hour is the only score, and it is not the number on your timer
Here is the distinction that reorganises everything else. Total time is what a customer experiences, the whole journey from joining the queue to pulling away with a bag. Throughput is how many cars you can clear in an hour. They sound like the same measurement expressed differently. They are not, and they respond to completely different repairs.
Throughput is set by the slowest single station in the lane, not by the total. If your pickup window takes 32 seconds per car and nothing else takes longer, you can clear roughly 3,600 divided by 32, so about 112 cars an hour, no matter how quick the order point is. Speed up the speaker post and you have not gained a car. You have simply moved the same number of vehicles into a longer wait in the middle of the lane.
Total time, meanwhile, is the sum of every stage plus all the queueing between them. A lane can post a healthy 3 minute average at 10am with four cars an hour and a miserable 7 minutes at noon with the exact same crew and equipment, because queueing time grows viciously as you approach the capacity of that bottleneck station. Nothing got worse. You just got busy.
Once you separate the two, the arithmetic gets useful. Take 6 seconds off the cycle time at the bottleneck and 32 becomes 26, which takes you from about 112 cars an hour to about 138. At a 14 average ticket across three peak hours, that is roughly 1,000 a day in sales you could not previously physically serve. Not more marketing, not a bigger menu. Six seconds at one station.
The corollary is the part that saves money: an improvement anywhere other than the bottleneck buys you nothing in throughput. A second menu board is a genuine fix when order taking is the constraint and a waste of a capital budget when the constraint is a single pickup window and one person bagging. Find the slowest station first. Time it with a phone for one hour on a Saturday if you have to, because the instinct about which station is slow is wrong about as often as it is right.
Where the seconds actually go
A lane has more stages than most operators count, and the till touches most of them. Worth walking through them, with rough times from a decently run quick service site, because the shape of the distribution matters more than any single figure.
Approach and menu board. 15 to 45 seconds, almost entirely outside your control and almost entirely determined by menu design. A regular ordering a usual takes 8 seconds. A family of four reading a board for the first time takes a minute and a half, and no POS feature shortens that. Board layout does.
Order taking. 20 to 40 seconds of actual conversation. This is where till design earns or loses real time: how many taps a combo takes, whether a size change re-rings the whole item, whether a modifier is two screens deep.
Transit to the pay window. 5 to 15 seconds, fixed by your concrete. You can do nothing about it, which is precisely why it is worth knowing.
Payment. 10 to 30 seconds, and the widest variance of any stage. Contactless resolves in about 2 seconds. A chip and PIN transaction with a signature and a receipt question can eat 40. Cash with change is worse, and cash is still a third or more of lane volume in plenty of markets.
Assembly wait. 0 to 120 seconds, the one the kitchen owns, and the only stage where a customer sits still doing nothing. This is the stage people remember.
Hand-off. 10 to 25 seconds. Bag, drinks, napkins, the sauce question, the double-check. Quietly the most common bottleneck in lanes that have already optimised everything upstream, because it is the one stage nobody thinks of as a station.
Add the low ends and you get about a minute. Add the high ends and you are past 5 minutes. Both are the same lane on different days, which is the whole reason a single average is close to useless as a management tool. Track the distribution, or at least the worst 10 percent, because the tail is where the walkaways live.
The order confirmation screen pays for itself in remakes, not in delight
An order confirmation screen is the display at the speaker post that shows the customer what has been rung up. Marketing describes it as reassurance. That undersells it. Its real job is moving error discovery from the window to the speaker, and the difference between those two locations is enormous.
Catch a wrong order at the speaker and it costs 8 seconds of correction. Catch it at the window and it costs the food, a remake, an apology, and 60 to 90 seconds of the bottleneck station while the car sits in the only position that blocks everybody. One remake at the window can cost you two cars of throughput. Order accuracy in drive-thru sits somewhere in the high 80s to low 90s as a percentage for most operators, so on 120 cars an hour you are looking at maybe 8 to 15 problems an hour to catch somewhere.
Two things make a confirmation screen much less useful than the brochure suggests, and both are worth checking before buying. It has to update live as the order is rung rather than at the end, because a customer will not re-read a finished list. And it has to show price per line, since a missing modifier is invisible but a wrong total is not.
Pull-forward parking, and the timer it quietly breaks
When an order is not ready, the crew asks the car to pull into a bay so the lane keeps moving. Operationally this is correct and you should keep doing it. The problem is what it does to your data.
Most timer systems stop the clock when the car leaves the window loop. Pull a car forward and its time stops at 90 seconds while the customer goes on to wait another 4 minutes in a bay with no fries. The board says you are fast. The customer would disagree, and the review will side with the customer.
This matters beyond hurt feelings, because if pull-forward rates drift up and average times drift down, people congratulate themselves on an improvement that is actually a decline. Any system worth buying should let you record the hand-off separately from the window departure, so a pulled car keeps accruing time until somebody hands over a bag. If a vendor cannot do that, at least log pull-forwards as a count and read the two numbers together, because a timer average without a pull-forward rate beside it does not mean anything.
What the timers measure, and what they hide
Lane timers are genuinely good tools that become bad tools the moment they become the target. Every trick below is real and shows up in lanes where a bonus is attached to the average.
Orders get rung early, before the customer has finished speaking, so the clock starts late. Cars get pulled forward more aggressively. In the worst version, an order is closed on the till and immediately reopened as a correction, which splits one slow car into two quick ones. None of this is fraud exactly. It is a rational response to being measured on one number.
The defence is not more surveillance, it is measuring more than one thing. Put cars per hour next to the average time next to the pull-forward rate next to the remake count, and the tricks stop flattering anyone, because gaming any one of them visibly degrades another. This is the same reason a dining room watches covers and average spend together rather than either alone, an idea covered properly in average check.
Cars leave the sequence, and most kitchen screens do not
Here is the design problem nobody puts in a sales deck. In a dining room, ticket order and delivery order are roughly the same thing, and first in first out is a reasonable default. A lane breaks that assumption constantly. Car three pulls forward, cars four and five collect and leave, and car three is now behind two cars that arrived after it while its food sits under a lamp.
A kitchen screen that only knows arrival order cannot express this. The crew compensates with memory and a marked cup, which works beautifully with one pulled car and collapses with four. What you actually want on the screen is a state per order rather than a position in a list: ringing, cooking, ready, waiting in a bay, handed over. Then a pulled car stays visible, in its own state, with its own clock, instead of quietly vanishing off the bottom.
Two specifics to test on a demo, because they are where systems differ most. Can an order be flagged as pulled forward without being marked complete? And can the expo screen sort by hand-off urgency rather than arrival time, so a car that has been in a bay for 3 minutes outranks one that just reached the window? If the answer to either is no, you will be running the lane on paper cups. For the general case of how these screens should behave, kitchen display screens goes into the mechanics.
A second order point, and when it stops helping
Once the lane consistently backs up past the menu board, the standard answer is to add a second order point, either a second speaker and board or a person outside with a handheld. Both work. Both also stop working, in a way worth understanding before you spend.
Adding order capacity helps only while order taking is the bottleneck. The moment the constraint moves downstream to assembly or hand-off, a second order point makes the lane worse, not better, because you are now injecting orders faster than the kitchen clears them and converting a queue of cars into a queue of finished bags going cold. You will see it in the data as average time rising while cars per hour stays flat. That is the signature of a bottleneck that has moved, and the signal to stop adding order capacity and start looking at the window.
A person outside with a handheld has one advantage over a second speaker that rarely gets mentioned: they can see the queue. They can take the simple orders from the back, skip the ones already ordering, and tell you in real time what the lane is doing. The equipment matters less than you would think. What matters is that the handheld rings into the same ticket stream as the lane, with the same modifiers, and that a mid-lane order does not arrive in the kitchen as a separate channel nobody is watching.
Paying before the window
Payment is the stage with the most variance and therefore the most available time. Three approaches, with honest trade-offs.
Pay at the window, card or cash. The default. Nothing to build, works for everyone, and costs you the full 10 to 30 seconds. Contactless is the single highest-return change available here: putting a reader the customer taps themselves, rather than handing a card over, typically removes 10 to 15 seconds and a hand-over.
Pay in the app before arriving. Removes the payment stage entirely for those customers, which is worth 15 to 25 seconds each. The catch is arrival detection. If the crew does not know which car is which, you have replaced a payment step with an identification step and saved nothing. Number plate recognition solves it well and costs real money; a code the customer reads at the speaker solves it adequately and costs nothing.
Account or subscription regulars. Coffee-led sites with heavy morning repeat traffic can get a meaningful share of the lane onto a stored card. When it works it is the fastest possible transaction, because there is not one. It only works with genuine daily frequency, so it is a coffee and breakfast play rather than a dinner one.
Whichever you choose, the reader has to be on the same system as the till. A standalone card machine beside a POS that does not know about it means somebody keys the amount by hand, which is 6 extra seconds, a typo risk, and a reconciliation job at close that nobody enjoys.
Menu boards are read at walking pace, not reading pace
Menu design is a till question now that boards are screens driven by the same system. A few things change in a lane that do not apply to a printed menu on a table.
Decision time is the largest controllable chunk of the whole journey, so structure beats completeness. Six to eight headline items with obvious combo logic will clear faster than 30 items arranged by category, and the difference is 20 to 30 seconds per unfamiliar car. Position the popular things where eyes land first, which is the upper left for most readers, and put the things people order without reading, the coffee and the usual, where a regular can point at them without slowing down.
If the boards are digital, dayparting is close to free and genuinely worth doing: breakfast off the board at 11 removes a conversation you do not want to have at the speaker. Resist the temptation to animate anything. Motion on a board increases dwell time, which is fine in a shopping centre and expensive in a lane. And keep the second board, the one at the pay window, for upsell rather than menu, because by then the decision is made and the only useful message is one more item.
What breaks at 40 cars an hour that was fine at 15
Systems fail by volume, not by feature. Things that are invisible at quiet times and structural at peak:
One ticket stream, several channels. A site running a lane, a counter, and delivery apps has three order sources landing in one kitchen. At 15 cars an hour the crew reconciles that in their heads. At 40, with delivery riders arriving, the kitchen needs one sequenced view with channel visible per ticket, or the lane starts losing to the channel that shouts loudest. This is the same integration problem described in order management system, just with less patience.
Modifier depth. A modifier two taps deep costs 2 seconds. At 40 cars an hour with two modifiers each that is roughly 2 minutes of lane capacity per hour, gone into menu navigation.
Receipt printing. A thermal printer that takes 4 seconds and occasionally jams is a genuine bottleneck at volume. Digital receipts and a printer you only use on request is a cheap 4 seconds.
Shift change. Nothing exposes a till like a handover at noon. If clocking in requires the order screen, you have just stopped the lane to change staff.
Offline behaviour. A lane cannot pause. If the connection drops, the question is not whether the system keeps taking orders, which most now do, but whether it keeps authorising cards, which is a different feature entirely. Know which one your vendor means, because the words sound identical and the consequences are not.
Staffing the lane
A lane at volume is usually four roles, and they are worth naming because the split is what makes the numbers achievable: an order taker, a cashier, an assembler, and a hand-off person. Small sites combine them, and each combination costs time in a predictable place. One person doing payment and hand-off is the most common merge and the most expensive one, because it puts two stages in series at the single position that blocks the lane.
The thing to protect is the hand-off position. It is the least glamorous job in the building, it is the one most often given to whoever is newest, and it is frequently the actual bottleneck. Put your quickest person at the window during peak and you will see it in cars per hour the same day, which is a cheaper experiment than any hardware.
Choosing a drive-thru POS: what to actually test
Demos are designed to look fast. Bring your own test script instead, and time it with a phone. Seven things worth checking, all of which have failed in real evaluations:
Ring your actual peak order in taps. Not a burger, your real modal order with its real modifiers. Count taps and seconds. Then change the drink size at the end and see whether that re-rings the combo from scratch.
Pull a car forward without closing it. If the only way to clear a screen is to mark the order complete, your data and your lane will disagree permanently.
Ask what the timer starts and stops on. Specifically whether hand-off can be a separate event from window departure.
Pull the network cable mid-order. Then try to take a card. Watch what the screen says, and ask who carries the loss on an offline authorisation that later declines.
Ask for the throughput report by half hour. Cars per hour by 30 minute block, with average and worst decile. If it only reports daily averages, you cannot manage a lane with it.
Ring a mid-lane handheld order into the same stream. Then find it on the kitchen screen in the right sequence.
Run a shift change. With the lane busy, in the demo. It is the least impressive thing you can ask to see and among the most revealing.
On cost, a lane adds hardware rather than software complexity: the order point, the confirmation screen, headsets, usually a second card reader, sometimes a timer system and boards. Software for a single site is commonly in the same bracket as any serious system, with the lane-specific hardware and the boards being where a quote grows. Get the boards quoted separately, because digital menu boards are frequently the largest line and are easy to phase.
The numbers worth putting on the wall
Five, and no more, because a board with 12 numbers on it is decoration. Cars per hour by half hour block, which is the score. Cycle time at the bottleneck station, named, so everyone knows which station it currently is. Pull-forward rate, so the timer cannot lie. Remakes per hundred cars, which is accuracy in a form that connects to throughput. And the worst decile of total time, because your reviews are written by the tail, not the mean.
Review which station is the bottleneck monthly rather than annually. It moves. Fix the window and it becomes assembly; fix assembly and it becomes order taking; fix order taking and it is the window again at a higher volume. That circulation is not failure, it is what improvement looks like in a queue with one exit, and a system that reports per station is the only way to see it happen.
If you are weighing a lane against other ways to serve people who are not sitting down, self ordering kiosks solve a similar throughput problem indoors and have a much lower build cost, and the two coexist well in sites with both a car queue and a foot queue.
Read next: POS with online ordering for how the digital channel plugs into the same ticket stream, table turnover for the dining room version of the same capacity arithmetic, and restaurant KPIs for where cars per hour sits among everything else you measure.
