---
title: Table Turnover Rate: How to Calculate It and Raise It Without Rushing Guests
description: How to calculate table turnover rate, time each stage of a visit, and turn tables faster at peak by speeding up the bill, not the meal. Worked examples.
canonical: https://menubeacon.com/blog/table-turnover-rate
author: MenuBeacon Team
published: 2026-10-20
updated: 2026-10-13
category: Guides
tags: Table turnover, Speed of service, Restaurant operations
---

# Table Turnover Rate: How to Calculate It and Raise It Without Rushing Guests

> Table turnover rate is parties seated ÷ tables, for one service. Here's how to work it out, time each stage of a visit, and why the time after the meal, not the meal itself, is the place to speed up first.

Table turnover rate is the average number of parties seated at each table during one service: parties seated ÷ tables. For example, 12 tables that seat 36 parties over lunch turned 3 times.

Faster turns add revenue only when people are waiting for a table. When they are, start after the meal: [research from 2009](https://doi.org/10.1108/09564230910978494) suggests guests mind a faster pace least while they wait for the bill and pay.

**Table turnover formulas, for one daypart at a time.** Checked on October 12, 2026.

| Measure | Formula | What it tells you |
|---|---|---|
| Table turnover rate (also called table turns or the turnover ratio) | Parties seated ÷ tables | Turns per table. It's a count, not a percentage: don't multiply by 100 |
| Minutes per turn | (Daypart minutes × tables) ÷ parties seated | Table time per party, resets and empty time included. "Table turnover time" can mean this or seated time; check which |
| Average seated time | Sum of (time left − time seated) ÷ parties | How long guests actually sat. Measure it with the worksheet below |
| Seat turnover | Covers ÷ seats | How many guests each chair served |
| RevPASH (revenue per available seat-hour) | Revenue ÷ (seats × hours in the period) | What each seat earned per hour, for comparing dayparts |

## How to calculate table turnover rate

*Illustrative numbers, not customer data.*

A restaurant with 18 tables seats 54 parties during a 4-hour (240-minute) dinner.

- **Table turnover rate:** 54 ÷ 18 = **3.0 turns**.
- **Minutes per turn:** 240 × 18 ÷ 54 = **80 minutes**. This isn't dining time: it includes resets and empty time.
- **Add what you measured.** Say the worksheet below gives an average seated time of 62 minutes and an average reset of 8. Then 80 − 62 − 8 = **about 10 minutes per turn when the table stood empty**.

Idle minutes are a demand or seating problem, and the kitchen can't fix them. Look at the host stand, the waitlist and the gaps between bookings.

If you take bookings, check your slot length against what you measured. Here a party needs 62 + 8 = 70 minutes including the reset. If this room booked every table in 80-minute slots, that alone would explain both results: 240 ÷ 80 = 3 seatings per table, with 80 − 70 = 10 minutes empty in each.

Don't cut the slot length to 70 minutes, though: 62 is an average and some parties sit longer, so time twos and fours separately and keep a buffer.

The same numbers give you **table occupancy**: 62 × 54 ÷ (240 × 18) = 3,348 ÷ 4,320 = **77.5%** of available table-minutes had guests at them.

Measure one daypart at a time, because an all-day average hides the peak. If you count from your POS, count tables opened, not checks: split checks inflate the count.

### What is a good table turnover rate?

A good rate is one close to your own ceiling at the hours when guests are waiting. The ceiling is daypart minutes ÷ (average seated time + average reset). In the example, 240 ÷ (62 + 8) = **about 3.4 turns**, against 3.0 achieved.

Few rooms reach their ceiling, since tables start empty and the last seating ends early. The gap is the turns you lose to empty tables: seating and demand, not service speed.

We found no published benchmark worth using. The "average restaurant turns X times" figures that circulate online rarely cite a source, and a rate means little without the concept, daypart, party size and menu behind it.

### Table turnover vs seat turnover

Same dinner: 54 parties averaging 2.8 guests make 151 covers on 72 seats (18 four-tops).

- **Seat turnover:** 151 ÷ 72 = **2.1**.
- **Seat occupancy:** 151 × 62 ÷ (72 × 240) = 9,362 ÷ 17,280 = **54%**, against 77.5% table occupancy.

The gap is empty chairs at occupied tables: twos and threes sitting at four-tops. Faster service can't close that gap; your table mix and seating policy can.

Table type and position can matter too. A Cornell study analyzed 1,413 peak-time meals at one 210-seat casual Mexican restaurant ([Kimes & Robson, *Cornell HRA Quarterly*, 2004](https://doi.org/10.1177/0010880404270063)). Banquettes had the longest stays and the lowest spend per minute.

Tables in "bad" spots, such as by the kitchen door, had shorter stays, higher spend per minute and checks no smaller ([Kimes & Robson, 2004](https://doi.org/10.1177/0010880404270063)). It's one restaurant over 4 weeks, so measure your own tables before you move furniture.

### RevPASH: revenue per available seat-hour

Sheryl Kimes of Cornell and her co-authors proposed RevPASH in place of counting table turns or revenue per daypart ([Kimes et al., 1998](https://doi.org/10.1177/001088049803900308)). Unlike those measures, it builds in how long meals take ([Kimes, 1999](https://doi.org/10.1177/001088049904000315)).

*Illustrative:* $6,000 of dinner revenue ÷ (72 seats × 4 hours) = **$20.83** per available seat-hour.

RevPASH equals covers per seat-hour × average check per cover, so it shows whether a change that trades one for the other pays.

*Illustrative:* the $6,000 dinner served 151 covers at an average of $39.74. If a shorter peak menu cut the average check by 5%, to $37.75, you'd need about 159 covers, 8 more (about 3 more parties), just to stay at $20.83.

## Is table turnover actually your problem?

Faster turns add revenue only when demand exceeds capacity: guests are quoted a wait, walk away, or fill the waitlist at the busiest hour. If tables sit empty at peak, a faster turn just empties them sooner, so work on demand and average check first. A shorter wait for the bill still helps guests, but it won't add covers.

More operators aim at demand than at turn times. In Toast's blind survey of 676 US operators with 16 or fewer locations (April 3–20, 2026; vendor research), 30% ranked increasing guest demand among their top 3 goals for 2026, against 20% for guest throughput or turn times ([Toast, August 26, 2026](https://pos.toasttab.com/blog/data/voice-of-the-restaurant-industry-2026)).

Working faster is still the most common plan if labor gets harder: 51% said they'd increase staff efficiency and speed of service if labor challenges grew ([Toast](https://pos.toasttab.com/blog/data/voice-of-the-restaurant-industry-2026)).

Run a 10-minute check at your busiest hour on 2 different nights. Count 3 things:

- Parties waiting at the door, any that leave without being seated, and booking requests you turned down for that hour.
- Tables where guests have finished and are waiting for the bill, the card reader or their change.
- Empty tables that haven't been reset.

If the first count is zero on both nights, turnover isn't your constraint. If it isn't zero, the other two counts show where to start: a high second count points to the after-the-meal stages below, a high third count to someone on resets at peak.

What to watch depends on how you seat guests:

| If you run | Watch first | Why |
|---|---|---|
| A walk-in room that queues at peak | Turns and walk-aways in the peak hour | A table freed at peak fills at once |
| A dining room that runs on bookings | RevPASH and the empty minutes between bookings | Your slot lengths cap your turns |
| A bar with counter seats and high-tops | Seat turnover | Guests share and swap tables, so table counts blur |

## Time each stage of a visit

Time 2 peak services, following 10–15 tables in each. Give the job to a manager or an extra person, since the host is busiest then, or split it: the host notes arrival, seating, departure and reset; servers note order and bill times; kitchen times come from ticket or screen timestamps, where yours show them.

Log clock times, one row per party, under these headings: date, daypart, table, guests, arrived, seated, order taken, kitchen started, first course served, bill asked, bill on table, paid, left, table reset. Subtract each time from the next to get the stage minutes.

| Stage | Usual causes of delay |
|---|---|
| **Before the meal** | |
| 1. Arrives → sits (waiting to be seated: demand, not part of the turn) | No clean table, incomplete party, wrong table size free |
| 2. Sits → first order taken (**dead time**) | Server covering too many tables, no menus on the table |
| 3. Order taken → kitchen starts it (the ticket time) | Orders batched at the terminal, tickets walked to the kitchen |
| 4. Kitchen starts → first course on the table | Line capacity, long menu, prep not done, slow pass |
| **The meal** | |
| 5. First course → guests ask or signal for the bill (time it, then leave it alone) | None: this is what guests came for |
| **After the meal** | |
| 6. First bill request or signal → bill on the table (**dead time**; time it from the signal, not from when someone noticed it) | Nobody sees the signal, bill not ready |
| 7. Bill on the table → payment complete (**dead time**) | One card reader for the floor, change for cash, splitting the bill |
| 8. Paid → guests leave | Their choice; leave it alone |
| 9. Guests leave → table ready for the next party (**lost seat time**) | Nobody assigned to resets at peak |

Add stages 2–8 to get each party's measured seated time. Dead time (2, 6 and 7) is guests waiting on you; lost seat time (9) is the next party waiting on you.

*Illustrative times, not typical ones:* one party of 4 at dinner, logged with the headings above.

| Logged | Clock | Minutes since the last entry |
|---|---|---|
| Seated | 7:05 | |
| Order taken | 7:13 | 8 (stage 2, dead time) |
| Kitchen started | 7:14 | 1 (stage 3) |
| First course served | 7:29 | 15 (stage 4) |
| Bill asked | 7:54 | 25 (stage 5, the meal) |
| Bill on table | 7:59 | 5 (stage 6, dead time) |
| Paid | 8:03 | 4 (stage 7, dead time) |
| Left | 8:07 | 4 (stage 8) |
| Table reset | 8:15 | 8 (stage 9, lost seat time) |

That's 62 minutes seated and an 8-minute reset, as in the worked example above. Dead time was 17 minutes (8 + 5 + 4), over a quarter of the visit. Start with the reset and the 9 minutes of dead time after the meal; some of the 8 before ordering may be guests still choosing.

**A shortcut from your POS.** If your POS logs when each check opens and closes, that span is a usable estimate of table time; [Kimes and Robson](https://doi.org/10.1177/0010880404270063) timed their meals that way. Merge split checks first.

If checks open at the first order and close at payment, the span misses stages 2 and 8, so it reads short and can't show where the minutes went. Use it for the weekly trend and the stopwatch for the cause.

## How to increase table turnover: start after the meal

Start with the reset and the bill, trim the waits before the meal without hovering, and leave the meal itself alone. The reset (stage 9) starts after the party has left, so speeding it up can't make them feel rushed.

### How to speed up service at each stage

| Stage | Fix | What it costs | What it risks |
|---|---|---|---|
| After guests leave | One person on resets during the peak | Labor hours | Idle time after the peak |
| After the meal | Keep each check current so the bill is ready when asked | A habit, not money | Bringing a bill nobody asked for reads as a push |
| After the meal | A bill-request button guests can tap, or a card they can flip | Software, or nothing | Someone must watch for requests |
| After the meal | Pay at the table: a reader brought over, or payment on the guest's phone | Handheld readers or a phone-payment service; card fees, as on any card payment | Guests who'd rather hand cash to a server |
| Before the meal | A clear rule for seating incomplete parties | Nothing | Some guests dislike it either way |
| Before the meal | A table mix that fits your party sizes | Furniture | Fewer large tables |
| Before the meal | Menus already at the table (paper or QR) and the drinks order first | Printing | Little, if nobody is rushed to order food |
| Before the meal | One order queue for the kitchen, a shorter menu at peak, prep pars set from your busiest night | Setup time, dishes cut from the menu, some waste | A new routine to learn, disappointed regulars |
| The meal | Leave it alone: don't clear one guest's plate while others eat; check back after the first bites, not on a timer | Nothing | This is where rushing costs most |

### Why start after the meal

Beyond the reset, the most useful evidence we found on pace is a study by Noone, Kimes, Mattila and Wirtz ([*Journal of Service Management*, 2009](https://doi.org/10.1108/09564230910978494)). They analyzed 151 usable mail-survey replies from a convenience sample of US diners, each about a social sit-down meal in the past 3 weeks.

Diners rated pace and satisfaction at 3 stages: seated to first course, first course to asking for the bill, and bill to leaving.

- **Satisfaction rose with perceived pace only up to a point, then fell,** for the whole meal and for each stage.
- **Diners tolerated a faster pace after the meal more than before or during it.** Some wrote that they felt rushed at the start when they didn't know the menu or couldn't decide.
- **Satisfaction with the middle stage weighed far more** in overall satisfaction than either other stage.

The limits: it's a survey of remembered meals from a convenience sample, and it measured satisfaction, not revenue.

Guests notice the bill wait. Zonal's undated [Integrated Payments fact sheet](https://insights.zonal.co.uk/hubfs/2025%20Fact%20Sheets/Zonal%20-%20Integrated%20Payments%20Fact%20Sheet.pdf) says 77% of consumers in a UK survey find waiting to receive and settle the bill frustrating on visits to pubs, bars and restaurants.

The sheet cites *GO Technology*, a survey of more than 5,000 British adults from CGA by NIQ and Zonal, a UK hospitality-tech vendor ([NIQ, May 9, 2024](https://nielseniq.com/global/en/insights/report/2024/go-technology-report-fixing-peoples-hospitality-bugbears/)). The bill figure also appears in [Caterer Licensee's report of the survey (May 10, 2024)](https://catererlicensee.com/cold-fold-long-waits-britons-biggest-hospitality-bug-bears/). It's vendor research, and the public pages give no fieldwork dates.

## What technology changes, and what it doesn't

The strongest study we found on table technology and meal length is by Tan and Netessine ([*Management Science*, 2020](https://doi.org/10.1287/mnsc.2019.3430)). A US casual-dining chain installed tablets at its tables in stages during 2013–14, so the authors could compare restaurants with and without them.

The tablets could take whole orders, but the chain had waiters take the food order and the first alcoholic drink. Guests could use the tablet to browse the menu, reorder alcoholic drinks and pay by card without waiting for a server ([authors' 2017 working paper](https://faculty.wharton.upenn.edu/wp-content/uploads/2017/09/2017.9.10_Tabletop_For_Submission_WithNames.pdf)).

Meals were about 10% shorter, sales per check about 1% higher and sales per minute about 11% higher, with no change in staffing; weaker servers improved more than stronger ones ([Tan & Netessine, 2020](https://doi.org/10.1287/mnsc.2019.3430)).

That study measured restaurant-owned tablets, not guests' own phones; we found no published study of how QR ordering on guests' own phones affects meal length or table turns. The chain's guests didn't order their food on the tablet either, so the study can't show what guest food ordering does to meal length.

Guest willingness limits any gain. In the National Restaurant Association's 2024 technology report, fewer US full-service diners said they'd order or pay by QR code on their own phone (48% and 46%) than on a tablet at the table (60% and 65%) ([NRA, March 27, 2024](https://go.restaurant.org/rs/078-ZLA-461/images/NatRestAssoc_TechLandscapeReport_2024.pdf)).

For the wider decision on QR ordering, see our guide to [QR ordering for US restaurants](/blog/qr-code-ordering-system-for-restaurants-usa).

What technology doesn't fix: kitchen capacity, a long menu, too few servers or a slow pass. Software doesn't add burners. Ordering from the table gets an order to the kitchen without waiting for a server, but it doesn't cook the food any faster (see [how a kitchen display works with QR orders](/blog/kitchen-display-system-kds-for-qr-menus)).

## Measure the change

Re-time the same dayparts after 2 weeks, on the same weekdays. Track turns, minutes per turn, measured seated time, RevPASH, walk-aways and guest feedback, with stages 2, 6, 7 and 9 as separate lines.

One week proves nothing. Change one stage at a time, or you won't know which change did the work. If minutes per turn falls but walk-aways were already zero, you've freed tables nobody needed. If seated time falls because stage 5 got shorter, you've sped up the wrong stage.

## How to speed up restaurant service in Pakistan

Where guests pay cash at the counter or to a waiter, time stages 6 and 7 first: the wait for the bill, then the wait to pay and get change. Make the request easy, have change ready before the peak, and let the cashier close a table's bill the moment it's requested.

Ask how the guest will pay as soon as they ask for the bill.

In Punjab the total depends on the payment method: sales tax is 16% on a cash bill and, since July 1, 2026, 8% on one paid by card, mobile wallet or QR ([Geo Fact Check, updated July 16, 2026](https://www.geo.tv/latest/673313-true-punjab-has-increased-sales-tax-on-restaurant-bills-paid-by-card-to-8)). See the rates by province, and which restaurants must use an integrated POS.

PRA's guidelines for Punjab, as reported by [The Nation on August 18, 2026](https://www.nation.com.pk/18-Aug-2026/guidelines-issued-transparent-tax-payments-restaurants-food-points), don't permit handing customers "kitchen orders, unpaid bills, pre-bills or temporary bills". If you bill through a PRA-integrated POS, close the table in that system.

Ask your tax adviser how to show the amount before payment without a pre-bill; this is general information, not tax advice.

In the Pakistan edition, Free is Rs 0 and Pro is Rs 5,000 a month, billed locally in rupees. Guests pay cash or at the counter; there are no online card payments.

On Free in the Pakistan edition, guests order from the table's QR code and can call a waiter or request the bill; staff mark orders paid, and kitchen tickets and order summaries print on 80 mm thermal printers. These printouts aren't the guest's bill or receipt. Pro in the Pakistan edition adds waiter orders with staff PINs, for dine-in and takeaway.

MenuBeacon doesn't connect to FBR, PRA or SRB. It applies one tax rate per restaurant and doesn't set the rate by how the guest pays; whether staff can change the rate on a single order isn't documented, so ask the team if you take both cash and card in Punjab.

Where PRA, SRB or FBR rules require an integrated invoice, the guest's bill or receipt comes from your integrated billing system, and the Pakistan edition handles the menu, ordering and kitchen.

So staff enter each order in that system too: key each one in as it reaches the kitchen, if your billing system lets you keep a table open, so the bill is ready when the guest asks. See [MenuBeacon for restaurants in Pakistan](/pk), or open the [Pakistan demo](https://app.menubeacon.com/login?demo=1&edition=pk), a sample restaurant in rupees.

## What MenuBeacon does at each stage, and where it stops

- **Stages 2–3, ordering (Free and Pro):** guests [order from the table](/table-ordering) by scanning its QR code; later rounds stay on the same table session. Orders land on the live kitchen dashboard (Received, Preparing, Ready and Done columns, with a new-order sound) in a browser on a tablet or computer you already own.
- **Stage 6, the bill request (Free and Pro):** guests can call a waiter or request the bill, and the request appears in the dashboard for staff.
- **Stage 7, payment:** on Free, guests pay cash or at the counter and staff mark orders paid. In the US, UK and EU editions, guests can [pay at the table on Pro](/pay-at-table) from their own phone, by card through the restaurant's own Stripe account, at standard Stripe fees, with tips. In those editions, Pro is $20 a month, billed in US dollars, month to month.
- **Planning the peak (Pro, US, UK and EU editions):** heatmaps and peak-hour forecasts from historical day-of-week averages (not AI).
- **Booking slots (Pro, US, UK and EU editions):** guests request a table and your team confirms each request; it isn't instant booking. You set the slot length, so you can apply what your timings show.

**Where it stops.** MenuBeacon doesn't document a table-turn report, so the worksheet is manual. It is not a full POS replacement and has no full two-way POS sync, so if you also run a POS, decide which one holds the bill before you re-time stage 6.

On Pro in the US, UK and EU editions, bills split equally into up to 10 parts, not by item. There are no card-preauthorized bar tabs and no reservation floor plan.

To see the kitchen board with live orders, [open the live demo](https://app.menubeacon.com/login?demo=1), a shared demo restaurant with simulated payments that resets every few hours, or [start free](https://app.menubeacon.com/register).

## Sources, checked on October 12, 2026

- Kimes & Robson, "The Impact of Restaurant Table Characteristics on Meal Duration and Spending", *Cornell Hotel and Restaurant Administration Quarterly* 45(4), November 2004 ([DOI](https://doi.org/10.1177/0010880404270063))
- Kimes, Chase, Choi, Lee & Ngonzi, "Restaurant Revenue Management: Applying Yield Management to the Restaurant Industry", *Cornell HRA Quarterly* 39(3), June 1998 ([DOI](https://doi.org/10.1177/001088049803900308)); Kimes, "Implementing Restaurant Revenue Management: A Five-Step Approach", *Cornell HRA Quarterly* 40(3), June 1999 ([DOI](https://doi.org/10.1177/001088049904000315))
- Noone, Kimes, Mattila & Wirtz, "Perceived Service Encounter Pace and Customer Satisfaction: An Empirical Study of Restaurant Experiences", *Journal of Service Management* 20(4), 2009 ([DOI](https://doi.org/10.1108/09564230910978494))
- Tan & Netessine, "At Your Service on the Table: Impact of Tabletop Technology on Restaurant Performance", *Management Science* 66(10), October 2020 ([DOI](https://doi.org/10.1287/mnsc.2019.3430)); study setting from the authors' working paper, September 2017, section 2.2 ([PDF](https://faculty.wharton.upenn.edu/wp-content/uploads/2017/09/2017.9.10_Tabletop_For_Submission_WithNames.pdf))
- National Restaurant Association, *Restaurant Technology Landscape Report 2024*, March 27, 2024 ([PDF](https://go.restaurant.org/rs/078-ZLA-461/images/NatRestAssoc_TechLandscapeReport_2024.pdf))
- CGA by NIQ and Zonal, *GO Technology: Fixing people's hospitality bugbears*, May 9, 2024 ([NIQ](https://nielseniq.com/global/en/insights/report/2024/go-technology-report-fixing-peoples-hospitality-bugbears/)); Caterer Licensee, "Cold Food, Long Waits – Britons' Biggest Hospitality Bug Bears", May 10, 2024 ([Caterer Licensee](https://catererlicensee.com/cold-fold-long-waits-britons-biggest-hospitality-bug-bears/)); Zonal, *Integrated Payments* fact sheet, undated, filed with Zonal's 2025 fact sheets ([PDF](https://insights.zonal.co.uk/hubfs/2025%20Fact%20Sheets/Zonal%20-%20Integrated%20Payments%20Fact%20Sheet.pdf))
- Toast, *2026 Voice of the Restaurant Industry*, August 26, 2026 ([Toast](https://pos.toasttab.com/blog/data/voice-of-the-restaurant-industry-2026))
- Geo Fact Check, Punjab sales tax on restaurant bills paid by card, updated July 16, 2026 ([Geo](https://www.geo.tv/latest/673313-true-punjab-has-increased-sales-tax-on-restaurant-bills-paid-by-card-to-8))
- The Nation, "Guidelines issued for transparent tax payments at restaurants, food points", August 18, 2026 ([The Nation](https://www.nation.com.pk/18-Aug-2026/guidelines-issued-transparent-tax-payments-restaurants-food-points))


## Frequently asked questions

**How do you calculate table turnover rate?**

Divide the parties you seated by your tables, for one daypart. With illustrative numbers, 35 parties at 14 tables over lunch is 2.5 turns; the result needn't be a whole number. Count every party seated at a table, booked or walk-in, but not takeout orders, and leave bar seats out unless you always count them as tables. If you push 2 tables together for one party, count one party and keep the table count from your floor plan.

**How can a server turn tables faster without rushing guests?**

Take the drinks order promptly, let guests choose food in their own time, and send each order to the kitchen as soon as you take it. If they turn down dessert or coffee, offer the bill rather than bringing it unasked. Once they ask, bring the bill and the card reader together, and bring change straight back: research found diners accept a faster pace best at that stage. Tell whoever resets tables as soon as a table pays.

**How do you get guests to give up a table without being rude?**

Set the limit before they sit, not at the end. Tell guests who book when you need the table back, and tell walk-ins at a busy peak when you seat them: "we have this table until 8:30." When the time comes, say so plainly and offer somewhere to finish, such as the bar, if you have room. Avoid hints such as hovering or clearing plates early.

**What is RevPASH and how do you calculate it?**

RevPASH is revenue per available seat-hour: revenue for a period ÷ (seats × hours in the period). For example (illustrative numbers), a 40-seat café taking $1,800 over a 3-hour lunch earns $1,800 ÷ (40 × 3) = $15 per seat-hour. Work it out hour by hour from your sales by hour, not only per daypart. A weak hour inside your peak is where to look first for empty seats, lingering tables or small checks.

**Does QR code ordering increase table turnover?**

The strongest study we found measured restaurant-owned tablets, not guests' own phones: meals were about 10% shorter, but waiters still took the food order, and guests used the tablets to reorder alcoholic drinks and pay. We found no published study of how QR ordering on guests' own phones affects meal length or table turns, so measure your own before-and-after. Time the waits for ordering, the bill and payment over 2 peak services before and after you switch, and count walk-aways.


---
Source: https://menubeacon.com/blog/table-turnover-rate
Publisher: MenuBeacon — https://menubeacon.com/