Do self-service kiosks reduce wait times and improve order accuracy?
Quick answer: DigitalSignage.com's answer is yes on both counts when the kiosks add capacity the counters lack: in the model below, two counters serving 72 orders an hour at 90 seconds each leave an average queue wait of 6.4 minutes, and three kiosks taking 45 percent of orders cut it to about 19 seconds, on stated assumptions. Accuracy improves because the customer enters the order and every modifier is explicit, so nothing is heard, interpreted or retyped. The kiosk app, POS and payment come from their vendors; DigitalSignage.com SignStudio runs the queue-status, instruction, menu and upsell screens around the kiosks, free for the first 3 screens.
Key facts
- Little's law says the average number of people waiting equals the arrival rate times the average wait; at 72 arrivals an hour and a 6.4 minute wait, 7.7 people are in line on average.
- Two counters at 90 seconds per order have a capacity of 80 orders an hour; at 72 arrivals they run at 90 percent utilisation, the zone where queues grow fastest.
- Three kiosks at 120 seconds per order add 90 orders an hour; with 45 percent of orders moving to them, counter utilisation falls to about 50 percent and the average wait to under half a minute.
- A customer-entered order removes three error sources, hearing, interpreting and retyping; measure remakes per 100 orders before and after rather than assuming a percentage.
- Kiosks reallocate labour rather than remove it: in the payback table, 4 to 8 counter hours a day move to assembly and hosting at 600 to 1,200 orders a day.
- Two kiosks at $9,000 each pay back in 12.5 months at 300 orders a day and 3.5 months at 600 orders a day, on the stated assumptions.
Last updated November 4, 2026.
How do you calculate whether kiosks will reduce wait times?
Compare arrivals with capacity first, then use Little's law and the Erlang C formula for the average wait; the whole calculation needs four inputs you can count in a week. The inputs are the arrival rate at the peak (orders per hour), the service time per order (seconds), the number of servers (counters or kiosks) and the share of orders each channel takes.
Capacity per server mu = 3,600 / service time in seconds (orders per hour)
Offered load a = arrivals per hour / mu
Utilisation rho = arrivals per hour / (servers x mu)
Little's law people waiting = arrivals per hour x average wait (hours)
Erlang C, M/M/c model average wait in queue = C / (servers x mu - arrivals per hour)
C = probability that an arrival has to wait
P0 = 1 / (sum over k = 0 to c-1 of a^k / k! + a^c / (c! x (1 - rho)))
C = (a^c / (c! x (1 - rho))) x P0
The first test needs no formula. If arrivals in the busiest 15 minutes exceed what the counters can serve in 15 minutes, the queue grows for as long as the peak lasts and only capacity fixes it. If arrivals are below capacity but utilisation is above about 80 percent, waits are long and erratic, which is the case most kiosk projects are really solving.
Little's law is the check you can do with a stopwatch. Count the line every 10 minutes at the peak and average it; divide by the arrival rate and you have the average wait without timing anyone. The Erlang C formula predicts the same wait from the inputs, which is how the two scenarios below are compared before any kiosk is bought.
Worked example: two counters versus two counters plus three kiosks
A quick-service restaurant with two counters wants to know what three ordering kiosks would do to its peak-hour line. Every input is an assumption to replace with your own counts, and the model (random arrivals, variable service times, the M/M/c queue) is a simplification; real peaks are lumpier, so treat the results as planning figures.
Assumptions, every one of them yours to change:
- 72 orders arrive in the peak hour, 1.2 a minute, at random.
- A counter order takes 90 seconds from "next please" to hand-off, so a counter serves 40 orders an hour.
- A kiosk order takes 120 seconds, because the customer is slower than a cashier, so a kiosk serves 30 orders an hour.
- 45 percent of orders move to the kiosks once the attract loop and instruction screens point people there; 55 percent stay at the counters.
- Counter and kiosk queues are separate lines.
| Step: two counters only | Calculation | Result |
|---|---|---|
| 1. Capacity per counter | 3,600 / 90 | 40 orders an hour |
| 2. Total capacity | 2 x 40 | 80 orders an hour |
| 3. Utilisation | 72 / 80 | 0.90 |
| 4. Offered load | 72 / 40 | 1.8 |
| 5. P0, probability of an empty system | 1 / (1 + 1.8 + 1.8 squared / (2 x (1 - 0.90))) = 1 / (1 + 1.8 + 16.2) | 0.0526 |
| 6. Probability of waiting (Erlang C) | 16.2 x 0.0526 | 0.853 |
| 7. Average wait in the queue | 0.853 / (80 - 72) hours = 0.1066 hours | 6.4 minutes |
| 8. People waiting (Little's law) | 72 x 0.1066 | 7.7 on average |
| 9. Arrival to order placed | 6.4 + 1.5 | 7.9 minutes |
Bottom line: two counters at 90 percent utilisation hold an average line of about 8 people and a 6.4 minute wait, and because the queue is non-linear a 10 percent rise in arrivals would roughly double that wait.
| Step: two counters plus three kiosks | Calculation | Result |
|---|---|---|
| 1. Arrivals at the counters | 72 x 0.55 | 39.6 an hour |
| 2. Counter utilisation | 39.6 / 80 | 0.495 |
| 3. Counter offered load and P0 | a = 0.99; 1 / (1 + 0.99 + 0.9801 / (2 x 0.505)) = 1 / 2.9604 | 0.338 |
| 4. Counter probability of waiting | (0.9801 / 1.01) x 0.338 = 0.970 x 0.338 | 0.328 |
| 5. Counter average wait | 0.328 / (80 - 39.6) hours = 0.0081 hours | 29 seconds |
| 6. Arrivals at the kiosks | 72 x 0.45 | 32.4 an hour |
| 7. Kiosk capacity and utilisation | 3 x 30 = 90; 32.4 / 90 | 0.36 |
| 8. Kiosk probability of waiting | a = 1.08; P0 = 1 / (1 + 1.08 + 0.583 + 0.328) = 0.334; C = 0.328 x 0.334 | 0.110 |
| 9. Kiosk average wait | 0.110 / (90 - 32.4) hours = 0.0019 hours | 7 seconds |
| 10. Weighted average wait | 0.55 x 29 + 0.45 x 7 | 19 seconds, down from 6.4 minutes |
| 11. People waiting (Little's law) | 72 x 19 / 3,600 | 0.4 on average, down from 7.7 |
| 12. Arrival to order placed | Counter 29 + 90 seconds; kiosk 7 + 120 seconds | About 2 minutes either way, down from 7.9 |
Bottom line: the kiosks cut the average queue wait from 6.4 minutes to about 19 seconds and the line from 7.7 people to under 1, because capacity rose from 80 to 170 orders an hour while arrivals stayed at 72.
The size of the drop surprises people, and the reason is step 3 of the first table. Queues behave gently below 70 percent utilisation and badly above 85 percent, so moving the counters from 90 percent to 50 percent removes almost all of the waiting even though the kiosk user spends 30 seconds longer placing the order.
Uptake is the lever that matters. At 25 percent kiosk share the counters take 54 orders an hour at 67.5 percent utilisation, the counter wait is 75 seconds and the weighted average about 57 seconds, still six times better than before. The attract loop, the "order here" instruction screen and a visible kiosk status are what move the share from 25 to 45 percent, and they are the cheapest part of the project.
Two cautions keep the model honest. A first-time kiosk user can take 3 minutes rather than 2, so plan the first month at a longer kiosk service time, and a kiosk that is down at the peak hands its share straight back to the counters. The queue arithmetic also says nothing about the pickup point, which becomes the next bottleneck once ordering is fast; the order-ready board covered below is the usual fix.
Do self-service kiosks improve order accuracy?
Yes, by mechanism rather than magic: a kiosk removes the three hand-offs between what the customer wants and what the kitchen ticket says, and it changes nothing about how the kitchen executes the ticket. The table lists each error source and what the kiosk does with it, with no invented percentages; your own remake log gives the number.
| Error source | At a staffed counter | At a kiosk | What the kiosk cannot fix |
|---|---|---|---|
| Hearing the order | The cashier hears it over noise and accents | The customer taps it | Nothing left to hear |
| Interpreting it ("no onions" on which item) | The cashier decides | The modifier is attached to the item it was tapped on | Confusing modifier screens still mislead |
| Retyping into the POS | The cashier keys it | The order posts to the POS as tapped | Nothing left to retype |
| Omitted modifiers | Forgotten under pressure | Required modifiers block progress until chosen | Wrong defaults preselected by the designer |
| Wrong item chosen | A verbal read-back, often skipped at peak | A confirmation screen with names, photos and prices | Poor photos or vague names |
| Kitchen misreads the ticket | The same ticket | The same ticket, usually on a kitchen display | Kitchen errors are unchanged |
| Substitutions when an item runs out | The cashier knows or does not | The POS 86 list hides the item on the kiosk | A list nobody updates |
Bottom line: a kiosk cannot mis-hear, mis-interpret or mis-key, so the errors that remain are design errors (defaults, photos, names) and kitchen errors, both of which a remake log makes visible.
Measure it rather than quote it. Log remakes and refunds per 100 orders by channel for two weeks before the kiosks and again after a month of operation; the kiosk vendor's console and the POS give the order counts by channel. The self-ordering kiosk interface page under Related guides covers the confirmation screen, modifier design and photo rules that decide the remaining design errors.
What happens to the labour?
Kiosks move hours from order-taking to assembly, hosting and the pickup point; they rarely remove whole positions, and a payback that counts whole positions is usually wrong. At 600 orders a day the restaurant in the model staffs two counters for 12 hours, 24 counter hours; after the kiosks it staffs one counter off-peak and two at the peak, 18 hours, plus a kiosk host for 2 peak hours, 20 hours in total.
That frees 4 hours a day. Half of them go to order assembly, which now receives orders faster than before, and the pickup point, which is where the queue reappears once ordering is quick. The other half leave the schedule and count as a saving, which is the rule the payback table follows: credit only the hours that leave the schedule.
The host role is the one to budget for. Someone near the kiosks during the peak answers "does it take cash", clears a stuck screen and walks a first-time user through the modifiers; without that person the kiosk share stays low and the counters stay busy. The self-service kiosk pros and cons page under Related guides treats assistance as a running cost for the same reason.
What should you measure before and after?
Log the same ten things for two weeks before the kiosks and for two weeks after the first month of operation, from the POS, the kiosk console, the kitchen and a stopwatch; the table says where each comes from and which decision it drives. Our goals and KPIs guide covers the baseline discipline for screens; the same rule applies here.
| Metric | How to log it | When | Decision it drives |
|---|---|---|---|
| Arrivals per 15 minutes at the peak | POS order timestamps, or a tally at the door | 2 weeks before, 2 weeks after the first month | The arrival rate in the queue model |
| Service time per order by channel | POS timestamps from order start to paid; the kiosk console for kiosk sessions | Same windows | The service time in the model; first-month kiosk times are slower |
| Average and 90th percentile queue wait | Stopwatch sample of 30 customers a day, or the queue system's log | Same windows | The wait-time claim itself |
| Queue length at the peak | A count every 10 minutes | Same windows | The Little's law check on the model |
| Abandonment | Walk-aways counted at the line and kiosk sessions that end before payment | After only | Flow redesign; see the interface page |
| Remakes and refunds per 100 orders by channel | Kitchen remake log plus POS refunds | Same windows | The accuracy claim |
| Average ticket by channel | POS report | Same windows | The add-on margin in the payback |
| Kiosk share of orders | POS report by channel | After, weekly | Whether the attract loop and instruction screens are working |
| Labour hours by role | The schedule | Same windows | The hours that actually left the schedule |
| Kiosk uptime and assist calls | The kiosk console; the signage screens' online status and remote screenshots from SignStudio player management | After, weekly | Maintenance and the host role |
Bottom line: the four model inputs (arrivals, service time, wait, queue length) prove the wait-time claim, remakes per 100 orders prove the accuracy claim, and ticket by channel plus hours that left the schedule prove the payback.
A note on tooling. Order counts, timestamps and ticket values come from the POS, which is why a POS that reports by channel is part of the kiosk decision. Whether SignStudio logs touches or sessions on its own touch scenes is not covered in our documentation; the kiosk vendor's console holds the kiosk data, and for the signage side ask support (support@digitalsignage.com, live chat at https://chat.digitalsignage.com/).
What is the payback at three volumes?
Below about 300 orders a day the kiosks are a 12-month decision driven by add-on margin alone, and from 600 a day labour reallocation makes them a one-quarter decision. The table runs the same assumptions at three volumes; every figure is an assumption to replace.
Assumptions, every one of them yours to change:
- Two transaction kiosks at $9,000 each installed for 300 and 600 orders a day, four for 1,200.
- Kiosk-app fee of $100 per kiosk per month and maintenance at 10 percent of kiosk hardware a year.
- 40 percent of orders move to the kiosks, and each kiosk order carries $0.50 of extra gross margin from the consistent add-on prompt.
- Counter hours leaving the schedule: 0 a day at 300 orders, 4 at 600 and 8 at 1,200, at $16 an hour over 360 days.
- Three signage screens (two menu boards and an order-ready board) on displays the restaurant owns, with $50 players: software $0 because the first 3 screens are free forever; a 4th screen would make all 4 billed at $3 each, $144 a year.
| Orders a day | Kiosks and one-time cost | Kiosk orders a day | Add-on margin a year | Labour saving a year | Running cost a year | Net benefit a year | Payback |
|---|---|---|---|---|---|---|---|
| 300 | 2; 2 x $9,000 + 3 x $50 = $18,150 | 120 | 120 x $0.50 x 360 = $21,600 | 0 | 2 x $100 x 12 + $1,800 = $4,200 | $17,400 | $18,150 / $1,450 a month = 12.5 months |
| 600 | 2; $18,150 | 240 | 240 x $0.50 x 360 = $43,200 | 4 x $16 x 360 = $23,040 | $4,200 | $62,040 | $18,150 / $5,170 = 3.5 months |
| 1,200 | 4; 4 x $9,000 + 3 x $50 = $36,150 | 480 | 480 x $0.50 x 360 = $86,400 | 8 x $16 x 360 = $46,080 | 4 x $100 x 12 + $3,600 = $8,400 | $124,080 | $36,150 / $10,340 = 3.5 months |
Bottom line: at 300 orders a day the add-on margin alone carries a 12.5 month payback, and from 600 a day the freed counter hours bring it to about a quarter; the signage around the kiosks costs $0 in software at every volume.
The 300-order case is the one a small site should read. No counter hour leaves the schedule, because one counter must stay open, so the kiosks are paid for by the add-on prompt and by the shorter line, which the table does not value. If the line is the problem, the queue arithmetic is the business case; if margin is, the add-on figure is. Both are measurable in the first month.
Our ROI calculator runs the same structure for screens, and a 30-day pilot is the way to turn these assumptions into measured numbers before the second site.
What are the benefits of using a POS system with kiosks?
A POS system is what makes kiosks and counters one operation: one catalogue, one price list, one 86 list, one order queue to the kitchen and one report by channel. Without it the kiosk is an island with its own menu and its own till, and every price change is made twice.
The benefits that matter for this page are five. Prices and sold-out items change once in the POS and reach the kiosk app, the tills and, through POS integration, the menu boards. Kiosk orders route to the kitchen display with the counter orders in one sequence, which is how the pickup point stays in order. Payment and reconciliation happen in one system, so the end-of-day count is one count.
The POS report by channel is the measurement plan's data source; it gives arrivals, service times, ticket by channel and kiosk share without any extra logging. And loyalty, discounts and tax rules apply the same way on every channel, so a customer gets the same price at the kiosk as at the counter. Our POS integration guide covers the integration routes; on DigitalSignage.com, POS integration for the boards is an Enterprise feature.
What does digital signage add around the kiosks?
Signage moves the two numbers the model is most sensitive to, kiosk share and the pickup bottleneck, for the price of a player per screen. Four screens do the work: an attract loop on or above the kiosks, an instruction screen, the menu boards and an order-ready board.
- Attract loop and instructions: "Order here, pay by card or phone, collect at the counter" in 10 words with a visible kiosk status, which is what lifts uptake from 25 to 45 percent in the sensitivity check above. On a kiosk screen running SignPlayer the attract scene is built with touch components on mediaCLOUD Plus+ and returns on its idle timeout; otherwise it is the kiosk app's idle screen.
- Queue and order-ready status: the number from the confirm screen shown above the counter, fed by a shared Google Sheet through the Google Sheets component, which updates when the sheet changes, or by the vendor's public status page in the Web Page component at a set refresh interval. Our queue management guide covers the formats.
- Menu boards with the add-on: the same offer as the kiosk's upsell screen, dayparted by campaign with a time window and a screen group, so the counter customer sees it too; our point-of-sale advertising guide has the placement rules.
- Loop length: a counter dwell of 3 to 8 minutes supports a 3 to 5 minute loop, from our loop length and dwell time guide, so every waiting customer sees the whole offer at least once.
Setup is the same as any screen: build the scenes in SignStudio, install the free DigitalSignage.com SignPlayer on a $40 to $250 player behind each display, and pair it by typing the registration code shown on the screen into SignStudio under Register SignPlayer. The first 3 screens are free forever; once an account has 4 or more screens, every screen is billed at $3 per screen per month on Plus+.
Proof of play, a log of what played on which screen and when, is an Enterprise feature priced in the public calculator. On the free and Plus+ plans the evidence that the offer ran is the campaign schedule plus remote screenshots from SignStudio player management, which also shows each screen online with its last check-in.
Frequently asked questions
Do self-service kiosks reduce wait times and improve order accuracy?
Yes, when they add capacity the counters lack. In the worked model, two counters serving 72 orders an hour at 90 seconds each run at 90 percent utilisation with a 6.4 minute average wait and 7.7 people in line; adding three kiosks that take 45 percent of orders cuts the wait to about 19 seconds and the line to under one person, because capacity rises from 80 to 170 orders an hour. Accuracy improves because the customer enters the order and every modifier is explicit, so nothing is heard, interpreted or retyped; the kitchen's own errors are unchanged.
How do you calculate wait time with Little's law?
Little's law says the average number of people waiting equals the arrival rate times the average wait. Count the line every 10 minutes at the peak and average it, divide by the arrivals per minute, and you have the average wait in minutes without timing anyone: a line of 7.7 people at 1.2 arrivals a minute means a 6.4 minute wait. The Erlang C formula predicts the same wait from arrivals, service time and the number of servers before you add kiosks.
How many kiosks does a restaurant need?
Enough to bring every channel below about 70 percent utilisation at the peak. Capacity per kiosk is 3,600 divided by the kiosk order time in seconds, 30 an hour at 120 seconds; multiply the peak arrivals by the share you expect the kiosks to take and divide by that capacity, then add one so the loss of a kiosk at the peak does not push the rest above 85 percent. In the model, 32 kiosk orders an hour need 1.1 kiosks of capacity, so three run at 36 percent with a spare.
Why do kiosks improve order accuracy?
A kiosk removes the three hand-offs between the customer's intent and the kitchen ticket: nobody hears the order, nobody interprets which item a modifier belongs to, and nobody retypes it, because the order posts to the POS exactly as tapped and required modifiers block progress until chosen. What remains are design errors (wrong defaults, poor photos, vague names) and kitchen execution, so log remakes per 100 orders by channel rather than assuming a percentage.
Do kiosks reduce labour costs?
They move hours more than they remove people. Order-taking hours shift to assembly, hosting and the pickup point, and a host near the kiosks during the peak is a new cost. Credit only the hours that leave the schedule: in the payback table that is 0 a day at 300 orders, 4 at 600 and 8 at 1,200, which is why the 300-order site pays back on add-on margin alone in 12.5 months and the 600-order site in 3.5 months.
What are the benefits of using a POS system?
One catalogue and price list for kiosks, tills and boards; one 86 list so sold-out items disappear everywhere; one order sequence to the kitchen display so the pickup point stays in order; one payment and reconciliation; and a report by channel that gives arrivals, service times, ticket value and kiosk share without extra logging. On DigitalSignage.com, feeding the menu boards from the POS is an Enterprise feature.
What should I measure to prove kiosks reduced wait times?
Arrivals per 15 minutes at the peak, service time per order by channel, the average and 90th percentile wait from a stopwatch sample or the queue system, and the queue length every 10 minutes, each logged for two weeks before the kiosks and for two weeks after the first month. The queue length divided by the arrival rate is the Little's law check on the stopwatch figure. Add remakes per 100 orders for accuracy and ticket by channel for the payback.
Does DigitalSignage.com provide the kiosk ordering software?
No. The ordering application, the POS and the payment come from the kiosk or POS vendor and a certified payment terminal. DigitalSignage.com SignStudio runs the attract loop, instruction screens, menu boards and order-ready board around the kiosks, with the first 3 screens free forever and $3 per screen per month once an account has 4 or more; touch components are on Plus+ and a locked kiosk presentation is Enterprise. For anything our documentation does not state, ask support.
Related guides
- Digital signage ROI calculator
- Digital signage goals and KPIs
- Queue management with digital signage
- Self-service ordering kiosks for restaurants and retail
- POS integration for digital signage
- Playlist loop length and dwell time by location
- How to run a 30-day digital signage pilot
- Self-service and self-checkout kiosks: pros, cons and when they pay off
- Designing a self-ordering kiosk menu interface
Try it on your own screens, free
DigitalSignage.com, which publishes this guide, runs a permanent free plan: the first 3 screens are free forever (no credit card, no ads, no watermark, no time limit), then from $3 per screen per month on Plus+. Once an account has 4 or more screens, every screen is billed, so 10 screens cost $360 a year; Enterprise is priced per screen in the public price calculator. The free DigitalSignage.com SignPlayer runs on Windows, Mac, Android and Android TV, Chrome OS, Raspberry Pi, iPad or any modern web browser, so the hardware you already own usually works. Start free · pricing · How 11 vendors compare on price
Maintained by MediaSignage Inc., operator of DigitalSignage.com since 2006. Product behavior on this page comes from our own SignStudio and SignPlayer documentation; where we do not document a step, this page says so instead of guessing. Last reviewed November 4, 2026.