RevPASH: revenue per available seat hour

What RevPASH is, and who put the name on it

RevPASH — revenue for a period divided by available seats multiplied by the hours those seats were available for sale, for the same period.

Available seat hours — seats physically available for sale multiplied by the hours of the trading period.

Seat occupancy — occupied seat hours ÷ available seat hours. Definition quoted from table turnover and seat occupancy, which owns the term. This page uses it as the first factor of RevPASH and introduces no second definition of its own.

The measure is not folklore and it is not a vendor invention. It comes from Sheryl E. Kimes at the Cornell Center for Hospitality Research. Everything quoted on this page is her report Cornell CHR, "Restaurant Revenue Management", CHR Reports Vol. 4 No. 2, February 2004 — full PDF, read end to end on 26 August 2026. Note what the report itself says about its own origins: footnote 3 sends the section that argues for RevPASH back to her earlier article, "Implementing Restaurant Revenue Management: A Five-step Approach", Cornell Hotel and Restaurant Administration Quarterly, vol. 40, no. 3 (1999), pp. 16–21. The 2004 report is where the measure is set out at length, not where it first appeared. Her wording, verbatim: "When a restaurant's operation is gauged by the time-related measure called revenue per available seat-hour, or RevPASH, managers can analyze operations and menus to improve that statistic."

And the reason she proposed it over the things restaurants were already counting, again verbatim from the same report: "Instead of counting table turns or revenue for a given day part, restaurant operators should measure revenue per available seat hour (RevPASH). This measure captures the time factor involved in restaurant seating."

That last phrase is the whole point. A dining room does not sell food; it sells a seat for a length of time, and the seat that stood empty between seven and eight o'clock cannot be sold again tomorrow. Kimes puts it plainly in the same paper: a restaurant's inventory "is best thought of as time — or, in this case, the time during which a seat or table is available. If a seat is not occupied for a period of time, that part of the restaurant's inventory perishes."

There is no published benchmark for RevPASH, and the reason is specific to this measure rather than a general suspicion of numbers. RevPASH is not a percentage — it is denominated in your currency, at your price level, against your seat count and your trading hours. Two restaurants two doors apart on the same Warsaw street, one selling lunch sets and one selling tasting menus, will differ by a factor that says nothing about which of them is managed better. It is also not collected. Eurostat's structural business statistics publish forty-eight indicators for the food and beverage service sector, and not one of them is a seat, a seat-hour or an occupancy rate — turnover, purchases, employee benefits, hours worked by employees, investment, but nothing about the room (dataset sbs_ovw_act, NACE I56, reporting year 2023, dataset updated 10 March 2026, read through the Eurostat API on 26 August 2026). Poland’s own statistical office publishes those same two things and stops there. In "Rynek wewnętrzny w 2024 r.", GUS, published 3 November 2025 — the PDF was opened and read on 26 August 2026 — Tablica 6 counts catering outlets (total, restaurants, bars, canteens, food stands) and Tablica 7 gives the sector’s revenue at current prices, VAT included. A seat is not counted anywhere in the publication: the phrase for consumption seats does not occur in it once. The machine-readable side says the same thing. A search of the GUS Local Data Bank API on 26 August 2026 returns 455 catering variables, measured in thousands of zloty, persons, percent, zloty, full-time posts, millions of zloty and premises — and not one of them in seats. What circulates in the trade instead comes from software vendors quoting one another. So this page prints a method, not a norm, and the only comparison base you will ever have is your own history. The general argument about why our pages refuse to print invented industry ranges is set out on the prime cost page.

The formula: money over seats times hours

RevPASH = Revenue ÷ (Seats × Trading hours)

• Revenue — net dining-room revenue for the period, PLN. Excludes VAT, discounts and voided checks. Also excludes delivery and takeaway, and that exclusion is not a detail — see below;
• Seats — guest seats physically available for sale in that period, seats;
• Trading hours — hours the room was open for sale in that period, hours;
• result — PLN per seat-hour.

Read the units out loud, because this is where the measure is most often broken. PLN divided by (seats × hours) gives PLN per seat per hour. That is the unit of the answer, and any version of the formula that does not resolve to PLN per seat-hour is not RevPASH, whatever it is called.

The denominator has its own name and its own line:

Available seat hours = Seats × Trading hours

• Seats — seats available for sale, seats;
• Trading hours — hours of the trading period, hours;
• result — seat-hours.

Forty-eight seats open for six hours is two hundred and eighty-eight seat-hours of inventory. If the room takes 7 440 PLN across those six hours, RevPASH is 7 440 ÷ 288 = 25.83 PLN per seat-hour. Kimes's own worked example uses the same arithmetic in dollars: "assume that a 100-seat restaurant makes $3,000 on Fridays between 6:00 and 8:00 PM. Its RevPASH for those hours would be $15 ($3,000/100 seats/2 hours)."

Why delivery and takeaway come out of the numerator. They have no seats. Putting their revenue on top of a denominator built from seats makes the dining room look as though it earns money it never earned, and the effect grows exactly when the room is emptiest — the evening the weather is bad and everybody orders in is the evening your seat-hour productivity is worst and your till is fine. Measure the off-premise channel on its own terms; what actually stays with you from an online order is a separate question, and we wrote about it in online orders for restaurants.

The same number written a second way — and the trap between the two

Kimes gives a second definition in the same report, and it looks nothing like the first: "RevPASH is defined as seat occupancy multiplied by average check and divided by average meal duration."

Both are correct. Both give the same number. And the trap between them has a name: the middle term is not the average check unless every guest sits for exactly one hour.

Start with the decomposition that is safe:

RevPASH = Seat occupancy × Average spend per occupied seat hour

• Seat occupancy — occupied seat hours ÷ available seat hours, a dimensionless share;
• Average spend per occupied seat hour — revenue ÷ occupied seat hours, PLN per seat-hour;
• result — PLN per seat-hour.

Units: a dimensionless share multiplied by PLN per seat-hour gives PLN per seat-hour. The occupied seat hours cancel — they are in the numerator of the first factor and the denominator of the second — and what survives is the available seat hours from the bottom of the occupancy term. That cancellation is the whole reason the decomposition is legitimate.

Average spend per occupied seat hour — dining-room revenue divided by occupied seat hours. This is not the average check. The two would coincide only if each guest occupied exactly one seat for exactly one hour.

Average check per guest — net sales divided by the number of guests, PLN per guest. Cornell's Exhibit 1 labels its column "Average check (per person)", so the per-person reading is the source's own, not our gloss.

The bridge between them is the meal duration:

Average spend per occupied seat hour = Average check per guest ÷ Average meal duration

• Average check per guest — net sales ÷ guests, PLN per guest;
• Average meal duration — average time one guest occupies one seat, hours per guest;
• result — PLN per seat-hour.

Units again: (PLN per guest) divided by (hours per guest) gives PLN per hour, per occupied seat. Substituting the bridge into the safe decomposition reproduces Cornell's second sentence exactly:

RevPASH = Seat occupancy × Average check per guest ÷ Average meal duration

• Seat occupancy — dimensionless share;
• Average check per guest — PLN per guest;
• Average meal duration — hours per guest;
• result — PLN per seat-hour.

Now the trap, with the arithmetic done. In the evening laid out below, the room takes 7 440 PLN from 78 guests, so the average check per guest is 95.38 PLN. Seat occupancy for the evening is 117 ÷ 288 = 40.625 %, which the table below rounds to 40.6 % for reading. Multiply the unrounded share by the check, as it is tempting to do — 0.40625 × 95.38 — and you get 38.75 PLN per seat-hour. The true figure is 25.83. The error is a factor of exactly 1.5 — the average meal duration in hours — and it runs in the direction that flatters you.

Kimes's own exhibit is only readable because of a footnote most summaries drop.

Set the duration to one hour and occupancy times check equals RevPASH. Change the duration and it does not. Any page that repeats the exhibit without the footnote has copied a special case and called it a formula.

Two more identities are worth having on paper. The first turns guests into seat-hours:

Occupied seat hours = Covers × Average meal duration

• Covers — guests served in the period, guests;
• Average meal duration — hours per guest;
• result — seat-hours.

Note what this formula is not. Covers = available seat hours × seat occupancy is dimensionally broken — seat-hours multiplied by a share gives occupied seat-hours, and guests are not measured in seat-hours. Covers are Seats × Turns, and turns belong to the table turnover page.

The second runs the formula backwards, which is how you price a decision:

Revenue = Available seat hours × RevPASH

• Available seat hours — seats × trading hours, seat-hours;
• RevPASH — PLN per seat-hour;
• result — PLN.

Lift one weak hour in a forty-eight-seat room from 8.00 to 16.00 PLN per seat-hour and you have added 48 × 8.00 = 384 PLN to that evening. Over twenty-five comparable evenings a month that is 9 600 PLN, and it came from one hour of the six.

Why a healthy average check and a full room can both be lying to you

Kimes is blunt about the check on its own: "Having a restaurant manager concentrate only on a high average check, for instance, is equivalent to a hotel's focusing solely on achieving a high average room rate." She then says the same about the other half: "A restaurant can run at 90 percent of capacity and still not make money if menu items are sold at too low a price…"

The reason both mislead is that they are the two factors of one product, and either one can be raised by pushing the other down. Discount into the empty hours and occupancy climbs while the check falls. Push the wine list and the check climbs while the guests who came for a quick plate go elsewhere. In Kimes's words, "RevPASH indicates the rate at which revenue is generated and captures the trade-off between average check and facility use. If occupancy percentage increases even as the average check decreases, for instance, a restaurant can still achieve the same RevPASH."

There is a subtler version of the same trap, and it is the one that catches good operators. A high check in a busy hour can be a symptom rather than an achievement: guests who linger over coffee and dessert while a queue stands at the door produce a beautiful check and a poor seat-hour, because the seat they are holding is the thing you are actually selling. Kimes flags exactly this — a high average check "may even be an indication of detrimental practices in times of strong demand".

So the practical test is not "is my check good" and not "is my room full". It is: what did one seat earn in one hour, and which of the two factors moved. That question has an answer, and the answer changes the decision. The other one does not.

The dollars in Cornell's paper are an illustration, not a target for a Warsaw dining room

This section exists because the figures in the founding paper are the ones most often lifted out of it and pinned to a wall.

The $7.20 in Exhibit 1 belongs to four hypothetical restaurants that the author constructed to show one principle: that the same RevPASH can be reached from opposite directions.

The Chevys Arrowhead case in the same report is real — a 230-seat main dining room whose hourly RevPASH "ranged from $0.43 on Tuesdays at 2:00 PM to $7.03 on Fridays at 6:00 PM" — but those are United States dollars at 2004 prices, in a chain casual-dining format, in a suburb of Phoenix.

None of it transfers. Not the level, not the ratio, not the occupancy. A Warsaw restaurant that measures itself against $7.20 is comparing a zloty figure from this decade against a dollar figure from twenty years ago, at a different price level, in a different format, with a different seat plan. What does transfer is everything that is not a number: the definition, the two ways of writing the formula, the footnote about meal duration, the principle that check and occupancy trade against each other, and the method for reading the number hour by hour.

Take the method. Leave the values in the paper.

One evening in a forty-eight-seat dining room, hour by hour

The numbers below are illustrative — a worked arithmetic example built to be checked, not a measurement of any real restaurant and not a benchmark. Use them to verify that your own spreadsheet does the same thing to your own data.

The room: 48 seats, dinner service 17:00 to 23:00, six trading hours, 288 available seat-hours for the evening. No terrace, no banquet, delivery excluded.

Every cell is checkable. 384 ÷ 48 = 8.00. 2 520 ÷ 48 = 52.50. The evening line is 7 440 ÷ 288 = 25.83, and the decomposition agrees once the occupancy is taken unrounded: the evening is 117 ÷ 288 = 40.625 %, rounded to 40.6 % in the table above, and 0.40625 × 63.59 = 25.83. The evening served 78 guests at an average meal duration of an hour and a half, which is where 117 occupied seat-hours comes from.

What the sag in each hour actually means

The single most useful thing this table says is that a third of the evening's inventory produces a tenth of its money.

But the two weak hours are weak for opposite reasons, and this is why the decomposition matters more than the headline number.

The people who came spent normally. There simply were not any. That is a demand problem: an early sitting nobody knows about, no reason to arrive at five, no pre-theatre offer, no booking pressure. Discounting the menu here would attack the factor that is not broken.

Both legs are down. The few guests still in the room are on a last drink; the kitchen is closing; each occupied seat is earning barely two thirds of what it earned at eight o'clock. This is not a demand problem, it is a question about whether the hour should be sold at all — which is the fourth lever, and the most dangerous one.

Here is what happens if you take it. Close at 22:00 and the denominator becomes 240 seat-hours, the revenue becomes 7 044 PLN, and RevPASH rises to 29.35 PLN per seat-hour. The ratio improved by three and a half zloty. The business is 396 PLN a night poorer. Both statements are true, and a page that shows you only the first one is selling you a smaller restaurant as an improvement.

Weekdays and seasons: the denominator has to stand still

One number for the month tells you almost nothing, because the month contains a Tuesday lunch and a Saturday dinner and the average of those two describes neither. Kimes's own case study reports RevPASH "by day of week and hour of day" for exactly this reason, and reports the lowest values "after 9:00 PM every day, and before noon and between 2:00 and 5:00 PM on all weekdays".

Build the grid the same way: hours down one axis, days of the week across the other, one figure in each cell, and read it as a map rather than as a score. Compare a cell against the same cell in earlier weeks — this Friday at eight against the last eight Fridays at eight — never against the cell next to it. Friday at eight and Tuesday at two were never the same product.

The rule that makes the grid trustworthy is a rule about the bottom of the fraction, not the top. The denominator must be identical in every period you compare. Change the seat count, change the trading hours, add the terrace, close the mezzanine, and the new figure is a different measurement wearing the same name. If the denominator has to change — and sometimes it has to — say so in the row, restate the earlier periods on the new denominator, or start a new series. Do not quietly compare across the break.

Seasonality has the same shape one level up. A Warsaw restaurant with a terrace has two different businesses in one address, and the July figure and the February figure are not comparable unless the terrace is measured separately all year. Compare July against last July.

A closed section of the room does not shrink the denominator — it shows up as lost occupancy

This is the point at which most spreadsheets quietly start lying, and it follows directly from the rule above.

You close the back room on a slow Monday because you cannot staff it. The tempting move is to take those sixteen seats out of the denominator for the evening, on the grounds that they were not really available. Do that and Monday's RevPASH goes up, every Monday looks better than it is, and the series stops being comparable with any other day — you have changed the denominator to make the numerator look bigger.

The honest treatment is the opposite. The seats stay in the denominator, and their emptiness lands where it belongs, in seat occupancy. Closing the back room did not make the room smaller; it made the room emptier, and the number is supposed to tell you that. If the back room is closed every Monday for a whole quarter, you now have a real management question with a real cost attached — sixteen seats times the trading hours times the RevPASH those seat-hours would have earned — instead of a flattering ratio.

Rain on the terrace works the same way inside the season. The chairs are out, the terrace is open for sale, the weather kept people away: lost occupancy, not a smaller terrace. Out of season is genuinely different — the chairs are in storage, nothing there is for sale, and the terrace leaves the denominator entirely. That is precisely why it needs its own series rather than being folded into the dining room.

The same logic covers the seats you lose to guests who never arrive. A no-show at eight o'clock on a Saturday does not remove seats from your inventory; it removes the revenue those seats were going to make, at the most expensive hour of the week, and usually too late to resell them. The seat-hours stay in the denominator and the occupancy falls. If you want the mechanics of stopping that leak rather than measuring it, our article on the no-show confirmation chain covers the operational side, and our booking service is where the confirmations actually get sent.

Dining room, bar, terrace, banquet: four denominators that must never be summed

A restaurant with more than one selling area does not have one RevPASH. It has one per area, because each area has a different definition of "an available seat".

The bar deserves the sharpest warning, because it is the zone most often measured wrongly. A bar with heavy standing trade earns money from people who occupy no seat; its RevPASH will look extraordinary and will keep looking better the more crowded and less seated it becomes. If that describes your bar, measure revenue per trading hour instead and say which measure you are using. A metric whose denominator does not cover the way the revenue is actually made is not a strict measure, it is a flattering one.

The banquet hall breaks in the other direction. It is sold as a whole block, not seat by seat, so its inventory is the block. A hall that could hold ninety and was contracted for sixty has thirty seats of unsold capacity in that block, and that is a real number worth watching — but it belongs to the banquet series, not to the dining room's. Fold one wedding into your Saturday dining-room figures and the Saturday grid becomes unreadable for a month. How those enquiries even reach you is its own subject, covered in restaurant event enquiries.

If you want a single figure for the whole site, build it from the parts and never from the parts' results:

Site RevPASH = Total revenue of all zones ÷ Sum of available seat hours of all zones

• Total revenue of all zones — PLN, dining room plus bar plus terrace plus banquet, off-premise excluded;
• Sum of available seat hours of all zones — seat-hours, each zone on its own seat count and its own open hours;
• result — PLN per seat-hour.

Averaging the four zones' RevPASH values instead would weight a twelve-stool bar the same as a hundred-seat dining room. Sum the money, sum the seat-hours, divide once.

Four levers for a weak hour, and the order in which they stop fighting each other

The decomposition tells you which lever to reach for. It is a two-factor product, so exactly one of two things is wrong in any weak hour — the room was empty, or the occupied seats earned too little — and occasionally both, as at 22:00 in the table above.

The order is not a matter of taste. Start with occupancy in the weak blocks, because filling an empty seat at a normal check takes nothing away from anyone: the guests already in the room are unaffected, the kitchen is not stretched, and the seat-hour was going to perish anyway. Move to spend per occupied seat-hour second, in the hours where the room is already full — that is where a better wine pairing or a properly built set menu adds money without adding pressure.

Third, and only in hours with a genuine queue, comes the time each guest holds a seat. This lever is the most powerful and the easiest to misuse, and it is not this page's subject: the definition of turnover, the anatomy of the time a party spends at a table, and the awkward case of a queue forming while seats stand empty all belong to table turnover and seat occupancy, which owns them in full. One line from that page is worth carrying into this one, in its words rather than ours, because two of our own definitions of the same term would be worse than none:

Table turnover rate — parties served ÷ tables, for a defined shift. Definition quoted from table turnover and seat occupancy, which owns it. A count of parties, not of guests and not of seat-hours; this page introduces no second definition of its own.

Trading hours come last, for the reason the worked example demonstrated. Cutting the dead hour raises the ratio and lowers the revenue, and there is no arithmetic that will tell you which of those two you should care about more. That is a decision about what the business is for.

One arrangement of the levers is worth stating on its own, because it is the mistake this measure was invented to prevent: do not pull all four at once. Discount the empty hours, push the check, speed the turns and trim the closing hour in the same month, and you will not be able to say which one moved the number — or which one moved it the wrong way while another covered for it. Change one factor, hold the denominator still, and read the grid.

RevPASH against revenue per table, per cover and per square metre

Every one of these is a real measure. They differ only in what sits under the line, and the denominator decides which question the measure can answer.

Revenue per square metre is the interesting comparison, because it is the one that looks closest and is furthest away. It is a property measure. It answers whether the lease is worth what you pay for it, and it answers that well. It cannot tell you anything about Tuesday at two o'clock, because the square metres are identical at every hour of every day: the denominator does not vary with time, so the measure cannot see time. RevPASH exists precisely to put time into the denominator.

Revenue per table is the one to be most careful with, because it is the easiest to produce and the easiest to misread. Two rooms with identical revenue per table, one built from twelve four-tops and one from twenty-four two-tops, are running completely different businesses. Seats normalise that; tables do not.

Where each of these sits relative to the others, and which of them deserve a place on a weekly screen at all, is mapped on the restaurant KPI tree — that page owns the hierarchy and the question of what belongs in front of whom.

Building your own comparison base out of your POS hour blocks

Since there is no benchmark, the comparison base has to be built, and it is built from three inputs you already own: the hourly sales export, the seat plan, and the opening hours. Kimes's own instruction to operators is the same one: "Collect at least a month of detailed POS data and analyze your seat occupancy, average check, RevPASH, party mix, and dining duration by day of week and hour of day."

One: pull the hourly export and the seat map for the same dates

Net sales by hour, for the dining room only, for a set of comparable dates — same weekday, same season, no public holidays, no private hire, no closure. Alongside it, the seat count as it actually stood on each of those dates, and the hours the room was genuinely open for sale rather than the hours on the door. If the two disagree, the export is right and the door sign is wrong.

Occupied seat-hours are the input most restaurants do not have directly. If your point-of-sale records the seating and clearing time of each party, the sum of party size multiplied by time seated gives them to you. If it does not, derive them from covers and an average meal duration you have actually timed — a fortnight of noting seating and clearing times by hand is enough, and it is the only part of this that costs anyone effort.

Two: write the denominator down and freeze it

One line, in words, saved with the file: which zone, how many seats, which hours, what is excluded. "Dining room, 48 seats, 17:00–23:00, terrace and banquet and off-premise excluded." Every future comparison is against that sentence. The day it changes, it changes with a date and the earlier periods get restated or the series gets cut. This single line is what separates a metric from an anecdote, and it is the step people skip.

Three: take the median of the same weekday, not the average of the month

For each cell of the grid — Friday 20:00, Tuesday 13:00 — take the median across the comparable dates rather than the mean. The median survives one catastrophic evening and one freak private booking; the mean does not, and a mean built on five Fridays is one storm away from being fiction.

What you have at the end is a grid of your own medians. Every subsequent reading is a deviation from that grid, in your currency, on your denominator — which is the only kind of comparison that was ever available for this measure. At what size of deviation the number should stop waiting to be read and call someone is a separate question with its own arithmetic, and it belongs to the page on the AI management layer, which owns thresholds in full.

What RevPASH cannot see

It cannot see profit. It is a revenue measure, and an hour with high RevPASH built on discounted covers served by three extra staff can be worth less than a quiet hour with two. Read it alongside the cost side, never instead of it.

It cannot see anything without a seat. Delivery, takeaway, catering out of the building and the six people standing at your bar are all real revenue and none of them belong in this numerator. A restaurant where off-premise has become a third of the business needs a second measure, not a stretched version of this one.

It cannot tell you why a cell moved. The grid will show you that Thursday at nine has been falling for six weeks. Whether that is roadworks, a new competitor, a chef who left, or a run of bad weather is not in the data, and acting on a guess is the expensive habit. If demand is what you want to anticipate rather than explain afterwards, that is a different discipline with its own error measurement — and what to automate around it more broadly is covered in restaurant automation, while which numbers an owner actually looks at deals with getting them in front of the right person.

And it cannot make the decision. It narrows the question from "why is the room not earning" to "Tuesday and Wednesday between five and seven have been below your own median for a month, occupancy is the leg that fell, the check is fine". That is the whole promise, and it is a large one.

Aura is the management layer over numbers like this one — where the hourly grid gets assembled from your own point-of-sale rather than from a spreadsheet somebody maintains by hand. Our dashboards and analytics build the grid and hold the denominator still, AI reports say which cell moved and which of the two factors moved it, forecast and what-if work on the hours that have not happened yet, external signals supply the weather and the calendar the grid cannot see on its own, booking is where the empty seat-hours actually get filled, and decision engine and tasks turn a sagging hour block into something a named person is doing on Thursday. The repetitive chores that stay on the staff while all that happens are taken off them by AI automation.

Frequently asked questions

What is RevPASH in a restaurant?

RevPASH is revenue per available seat hour: the dining room's revenue for a period divided by the number of seats multiplied by the hours those seats were available for sale. It is measured in currency per seat-hour. The measure comes from Sheryl Kimes at the Cornell Center for Hospitality Research and exists because a restaurant sells a seat for a length of time — a seat that stood empty between seven and eight cannot be sold twice tomorrow.

How do you calculate RevPASH?

Divide net dining-room revenue for the period by seats multiplied by trading hours. A 48-seat room open six hours has 288 available seat-hours; 7 440 PLN across that evening gives 25.83 PLN per seat-hour. Exclude delivery and takeaway from the numerator, because they have no seats and nothing in the denominator corresponds to them. Keep the denominator identical across every period you intend to compare.

Why is there no universal good RevPASH, and how do I set a threshold from my own history?

Because RevPASH is not a percentage. It carries your currency, your price level, your seat count and your trading hours, so two restaurants on the same street can differ severalfold without either being managed worse. It is also not collected: none of the forty-eight indicators in Eurostat’s sbs_ovw_act dataset for the food and beverage service sector (NACE I56) is a seat, a seat-hour or an occupancy rate, and the figures circulating in the trade come from vendors quoting one another. Build the grid instead: median of each weekday-and-hour cell across comparable dates, on a written-down denominator, and read every later figure as a deviation from your own cell.

Why is average check not enough on its own?

Because the check is one of two factors and can be raised by pushing the other down. A room can lift its check by encouraging guests to linger and lose money doing it, since the seat those guests hold is the thing being sold. In Cornell's phrasing, RevPASH "captures the trade-off between average check and facility use" — if occupancy rises while the check falls, the restaurant can reach exactly the same RevPASH. Neither half answers the question alone.

How do I count available seats when part of the room is closed?

The closed seats stay in the denominator. Removing them raises the figure and destroys comparability, because you have changed the bottom of the fraction to flatter the top. A closed section is not a smaller room, it is an emptier one, and it should show up as lost seat occupancy. The same applies to rain on an open terrace inside the season. Out of season, when the chairs are in storage and nothing there is for sale, the terrace leaves the denominator — which is why it needs its own series.

Should the bar be measured separately from the dining room?

Yes, and for a reason stronger than tidiness: the bar has a different definition of an available seat. Bar stools are seats, standing guests are not, so a bar with heavy standing trade earns revenue against no denominator and its RevPASH inflates without limit. Measure each zone on its own seat count and open hours. For one site-wide figure, sum all the revenue and sum all the seat-hours and divide once — never average the zones' results, which would weight a twelve-stool bar like a hundred-seat room.

How is RevPASH different from revenue per square metre?

Revenue per square metre is a property measure with floor area in the denominator, and floor area is identical at every hour of every day. That makes it the right tool for a rent negotiation and useless for a shift decision, because a denominator that does not vary with time cannot see time. RevPASH puts hours into the denominator on purpose. The two answer different questions and neither substitutes for the other.

Does RevPASH include delivery and takeaway revenue?

No. Off-premise orders occupy no seat, so there is nothing in a seat-hour denominator for them to correspond to. Including them inflates the figure exactly when the room is emptiest — the wet evening when everyone orders in is the evening your seat-hour productivity is at its worst and your till looks fine. Measure the off-premise channel on its own terms and keep the dining room's numerator clean.

Take one ordinary evening, write down the seats, the trading hours and the revenue for each hour, and divide. The hour where the number sags will surprise you less than the reason it sags — and the decomposition tells you which of the two factors to reach for. The restaurant section of this site unpacks the neighbouring measures in turn.