Restaurant Floor Plan Design: Build Your Floor Map From Ticket Data

Your floor map was probably born from instinct: you walked into an empty space, spread the tables out, and left a lane for staff to walk through. The trouble is that map lives on the floor and in your head, and nowhere inside your system. While that's true, you can't answer the simplest question there is: which section actually earns more, and how many seats sit empty every night while still counting against your capacity? This guide flips the order. We pull restaurant floor plan design out of your own tickets, put a number on seat waste, turn sections into records that own seats and sales and yield, and only then assign servers using a report instead of a hunch.

You'll leave with three concrete things: a table showing what share of your business each party size really is, a table mix sized to that table instead of to the shape of the room, and a floor map defined inside your system so every number that follows can actually be produced: occupancy, table time, revenue per seat hour, and sales per server. Do it in that order, because dining-room numbers taken before the map is defined don't come out wrong, they don't come out at all.

You can't measure a drawing: the data the map is built on

Before you move a single table, look at what data you actually hold. Everything that follows hangs on one small field: the number of guests on each dine-in ticket. If the cashier never records it, you own sales but you don't own a dining room. You know what you sold, and you don't know how many people sat down, where they sat, or how many seats were booked and empty at the same moment. Here's what you need before you start:

• A cover count recorded on every dine-in ticket at the moment the table opens, not a guess typed in at closing.
• The table number attached to the ticket, so you can see which table size received which party size.
• Table open time and ticket close time, so table duration is measured in minutes rather than felt.
• A list of your current tables with their real capacity, and the seat total for each area of the room.
• At least four weeks of closed tickets, so the gap between midweek and weekend actually shows up.
• Your licensed capacity, used as a ceiling that no drawing of yours ever crosses.

If you're not capturing covers today, start now and wait four weeks before analysing anything. In theory you could infer party size from the number of items on the ticket, but that estimate misleads more than it helps: two people order four items, a solo diner orders three, and a party of six shares two plates with a drink each. The real field is cheaper than any inference, and it costs one tap on the cashier screen when the table opens.

Table capacity means the number of seats you work that table at day to day, not the maximum number of chairs you can squeeze around it. Record a four-top as a six because you once seated six there and you'll generate inflated seat-waste figures and decisions built on them. Put down the number you actually run, and keep squeezing as a manual exception rather than a rule written into your data.

Four weeks is enough to see your weekly rhythm and nowhere near enough to see your season. Ramadan, school holidays and summer flip the party mix completely: some stretches are nothing but large groups, others nothing but pairs. So don't pull one month and call it your dining room forever. Run the same pull every quarter and compare the tables side by side, because the change between two of them is information in itself.

Here's what the output looks like, using a hypothetical 60-seat restaurant with 2,000 dine-in tickets pulled over four weeks:

Read the table one way: 55% of your parties are one or two people, and only 10% are five or more. Your room, meanwhile, is probably built around the four-top because it works for everyone. It does work for everyone, and that's exactly what it costs you. Every time two people sit at it you've reserved four seats and sold to two, and for the whole session those other two seats count toward your capacity and bring in nothing.

Before any drawing, mind the ceiling. Permitted seat counts and the conditions attached to how a dining room is laid out vary by activity, area and municipality, and they change over time, so check them at the source on Balady or in the text of your own licence, and never rely on a number someone told you. What this guide owns starts above that ceiling: how to use the seats you're allowed as efficiently as possible. And if you're still in the setup phase, how to open a cafe in Saudi Arabia walks through the licensing order that comes before this step.

From tickets to a floor map: seven steps

The order here is deliberate: each step produces the input for the next one. Jump straight to drawing before you measure and you'll do the work twice, and pay to move the furniture twice along with it.

1. 1
   Pull your party-size distribution

   Group closed dine-in tickets by cover count and work out the ticket count and share for each size. Run the pull at least twice, once for lunch and once for dinner, because the mix shifts noticeably between them in most restaurants. What you get is one row per party size, and that table governs every decision after it.

2. 2
   Put a number on seat waste

   For each ticket, subtract the cover count from the capacity of the table those guests sat at, then multiply the gap by the session length in minutes. Add it all up and divide by (total seats x trading minutes) and you have the share of your seating that was booked with nobody in it. In the hypothetical above, the average party is 2.75 people at a table averaging 4.2 seats, so roughly 35% of occupied seating is running empty.

3. 3
   Size the table mix to the distribution, not to the room

   The rule is simple: the share of tables at each size should track the share of parties at that size, with a clear bias toward smaller, because small tables join and big ones don't split. Two deuces pushed together serve a four; a four-top never becomes two twos. And the constraint that binds you isn't how many guests you serve in a day, it's the most parties seated at the same moment during your peak.

4. 4
   Make every table a record, not a square on paper

   Each table needs a stable name or number, a real seat capacity, and a section it belongs to. Those three fields are what let a ticket know where it was born, and every dining-room report later is built on them. If you run QR ordering at the table, the code binds to the table record itself, so the order reaches the kitchen already knowing where it goes without anyone writing it down.

5. 5
   Decide joinability once, in setup

   Spell out now which tables combine, what capacity each combination produces, and which tables never move, like the ones by the walkway or the exit. Leave the decision to the rush and it becomes improvisation: two tables joined and a third one blocked, or a party of six turned away that could have been seated. Every merge closes a path for someone else, so make that cost defined and decided in advance.

6. 6
   Build sections as records that own seats and sales

   A section isn't a colour on a drawing, it's a container that owns a list of tables, a seat total, and a server on duty each shift. Defined that way, every ticket rolls up under its section automatically, and you can ask what the terrace brought in last week and how many seats it had. Without that definition the question has no answer inside the system, however detailed your reports are.

7. 7
   Assign staff per shift, then re-measure after four weeks

   The assignment has to be recorded against the shift rather than kept in the manager's head, because no report attributes sales to a person unless the system knows who owned what. Four weeks after you start running the new map, pull the same reports and compare. Change one variable per cycle, or you'll never know which of your changes did the work.

Merging is a setup decision, not a rush-hour decision

Combining tables isn't a feature, it's a decision with a price. When a server pushes two deuces together for a party of four, they haven't added seats, they've closed a path for two parties who would have sat separately. That price is fine when the party is standing in front of you, and it isn't fine when it becomes habit: tables joined at the start of service just in case, then sitting empty half the night while you count yourself full.

So make the call in setup, not in the moment. Define which tables can combine, what capacity each combination gives, and which ones are fixed. Define when they come apart again too, and the practical rule is that tables revert to their default layout at every ticket close rather than at the end of service, so the map inside the system keeps matching the one on the floor. Any drift between the two turns into an occupancy report nobody believes within a week.

Sections are records, not colours on a drawing

The difference between a section as a record and a section as a colour is that the first one you can aggregate, compare and change, and the second one you can only look at. A record means the section has a stable name, a list of tables that belong to it, a seat total that updates itself when you add or remove a table, and a server tied to it per shift. Those four things are what let any report later split sales by section without someone rebuilding it by hand in a side spreadsheet.

Base the split on a real difference in service or conditions: indoor and outdoor, high tops, terrace, upper floor. Don't split it for looks, because every extra section means a smaller sample, weaker numbers and a slower decision. Three clear sections beat eight lookalikes. Table management and floor mapping inside the system works on the same principle: the table is a record, the section is a container, and the ticket knows from its first second where it was born.

Table time: the second variable after party size

Party size decides how many seats you reserve; table time decides how many times you can sell the same seat in a night. Multiply the two and that, not the chair count, is your real capacity. Table time breaks into clear segments: seated to ordered, ordered to fired, fired to served, the meal itself, and asking for the bill to paying. The first and last segments add nothing for the guest, and they're exactly the ones you can cut without rushing anybody through their food.

To measure any of it you need the table open time and the close time, and that comes down to operational discipline: the table opens when the guest sits, not when the first item is entered. If your staff open it late, table time reads shorter than reality, and you'll think your turns are excellent while you quietly lose seats every night. The last segment is the easiest one to cut: QR order-and-pay at the table removes waiting for the bill and waiting for the card machine from the equation entirely.

An open table with nobody on it poisons every number after it

A table left open in the system after the guests have gone corrupts three numbers at once: table time reads longer than it was, occupancy reads higher, and turns read lower. Worse, it makes your host turn away a party while the table sits empty on the floor. The fix isn't a general lecture about discipline, it's tying the close to the payment: the ticket closes when it's settled and the table goes back to available in the same instant, automatically, with no manual step for someone to forget mid-rush.

If your system asks staff to release the table as a separate step after payment, treat that as a permanent source of error and discount every number it produces accordingly. That's one of the questions worth asking before you buy rather than after, along with the rest of them in how to choose a restaurant POS.

What you can measure once the room is data

The numbers below weren't hidden before you defined the room, they didn't exist. That distinction matters: you're not unlocking a report that was closed, you're starting to generate data that was never being recorded.

Table mix before and after: same seats, more parties

Back to the hypothetical: 60 seats, an average party of 2.75, and a current mix of 12 four-tops and two six-tops. Parties of one to four go to a four-top and five-plus go to a six-top, so the average party ties up 4.2 seats to serve 2.75 people. Rebuild the mix as 12 deuces, seven four-tops and one eight-top and you stay at the same 60 seats while the result changes:

Notice that the seat count didn't move and you didn't add a square metre of space. What changed is how many parties you can seat at the same moment: from 14 to 20, six more at the peak. And be honest with yourself reading that number, because the gain does nothing for you in a dead hour. It only pays in the hour when people are standing at the door waiting. If you have no wait at all, your problem isn't the table mix, and it lives in menu engineering or in your sales channels rather than in the drawing.

Revenue per seat hour: the metric that exposes the big section

Total section sales is a misleading number, because it rewards the big section for being big and punishes the small one for being small. The metric that compares sections of different sizes is revenue per seat hour: section sales divided by (its seat count x trading hours in the period). Same hypothetical, one week, ten trading hours a day, so 70 hours:

On raw sales, indoor is the hero and the terrace is last. On revenue per seat, the ranking inverts: your smallest section is your most productive one and your biggest is merely average. The decision isn't to scrap the terrace, it's to ask why. Is it seasonal and only works certain months? Does it have no permanently assigned server, so service arrives late? Are the items ordered out there lower margin? Three different causes with three different fixes, and you can't tell them apart until the section is a record that carries its own numbers.

Server fairness, calculated instead of felt

This argument repeats in every restaurant with a dining room: the server says their section is dead, the manager says the difference is you not the section, and it never resolves because both sides are talking in impressions. The way to end it is to work out two numbers per server and divide one by the other: their share of sales and their share of seats. Same hypothetical, with each server responsible for one full section:

• Server A (indoor): 54% of the week's sales on 53% of the seats, a ratio of 1.02.
• Server B (terrace): 20% of sales on 27% of the seats, a ratio of 0.74.
• Server C (high tops): 25% of sales on 20% of the seats, a ratio of 1.25.
• The raw gap between top and bottom server reaches 34 percentage points of sales, and most of it is explained by section size rather than performance.

A ratio near 1 means the server and the section are in balance, below 1 means the section is returning less than its seats deserve, and above 1 means the opposite. The ratio doesn't tell you who's better, it tells you where to look, and one experiment separates the two possibilities: swap two sections between two servers for two weeks and see which the number follows. Followed the person? It's performance or training. Stayed put? It's the section: its location, its temperature, its distance from the kitchen, or its table mix.

And don't adopt a threshold you heard somewhere, like a 25% gap meaning unfairness. Your threshold comes out of your own data: compare the sales gap to the seat gap, treat any gap that repeats four weeks running in the same direction as worth acting on, and treat any gap that flips week to week as noise not worth a meeting. The same logic applies to splitting tips: once each server's sales are tied to their shift, the split rests on a record anyone can check. Shift reports fill in the other half of the picture, and we covered those in the X report and Z report guide.

From the map to the shift schedule: staffing as a number

The last thing a defined dining room opens up is staffing by number instead of by guess. Pull the count of simultaneously open tables for every hour across four weeks and a clear curve appears: hours with four active tables and hours with eighteen. If one server can cover four active tables well, the hour with 18 tables needs five and the hour with four needs one. How many a server can actually cover isn't a universal constant, so measure yours: compare table time and error counts in your busiest hours against your quiet ones, and you'll find the count at which performance starts to break.

This is where the real money sits. One extra staff hour a day compounds quietly across a month, and one missing hour at the peak costs you tables that never turned and guests who walked. Neither is solved by a fixed schedule repeated every week. Both are solved by a curve pulled from your data and refreshed each quarter.

Once the map and the sections are records, decisions that used to be closed open up:

• Shrinking a low-yield section and converting its space to smaller tables, on a number instead of an impression.
• Running an offer or a price for one hour in one section, and measuring the effect on that section alone.
• Setting staff per shift from the open-tables curve rather than from the belief that Friday is busy.
• Knowing which section justifies investment like cooling, shade or lighting, based on its current yield rather than its looks.
• Measuring the effect of any change: move one thing, then compare against the same week before it and the same period last month.