Coverage & readiness
Capacity readiness
Which venues have team-confirmed capacity and scheduled hours ready for comparison, which are entered-but-unconfirmed, and which are missing a piece. It says whether capacity information is ready to compare with — not whether any capacity is right.
What it is
Capacity readiness is a coverage check across your venues' capacity setup — not a measurement of any night. For each owned venue it reads that venue's own settings and reports one of five states: capacity is ready (team-confirmed, still matching the entered number, with scheduled hours set), changed since confirm (the entered number no longer matches what was confirmed), entered but unconfirmed, confirmed but missing hours, or missing a piece entirely.
It answers one owner question: which venues have trustworthy capacity information ready to compare with. Because it describes setup state rather than a night, there is no time window and no arithmetic — it is a roll-call of where each venue stands, so a missing or unconfirmed number is a named state you can act on, never a silent gap under a metric that assumed it was there.
How to use it at your venue
Operators often treat capacity readiness as a pre-flight check rather than a nag: before pulling up week-over-week trends or side-by-side venue comparisons, they confirm each room's capacity with whoever owns that number — a GM, fire-code compliance, or ownership — and re-confirm it whenever the space, layout, or permit changes. The data-quality literature is the grounding here: completeness and accuracy are treated as prerequisite properties data must have before it is fit for use by a decision-maker, not qualities you hope for after the fact.[1]
A grounded use is to keep scheduled hours current alongside the capacity number, so "capacity" is never silently applied to hours a venue isn't open. This mirrors a standard industry convention in hospitality: USALI treats "available rooms" as a governed denominator behind occupancy and RevPAR rather than a guess,[2] and STR's benchmarking guidelines require a property's full room-night availability be reported and flag data gaps before that property's numbers enter a comparison set.[3] Reading down the not-ready rows first is the same discipline applied to your own venues.
How to read it
Read it as a count of venues per state, not a score. A row in ready means that venue's capacity is fit to compare with; the four other states each name a specific missing piece and link straight to the venue's setup page to fix it. The states are facts about your settings, so there is nothing to rank — a venue in missing is not worse-run, it is simply not yet set up. The value of the card is that it makes the gap visible before another metric leans on it.
What it doesn't mean
⚠ What it can't tell you
It says whether capacity information is ready to compare with — not whether any capacity number is right, and nothing here measures how full or how profitable a venue is. "Confirmed by your team" means exactly that: a member of your team confirmed the number. It is not an external verification and never a legal-capacity claim.
Capacities are never added into a group total — a group-wide capacity figure would blend confirmed and unconfirmed numbers into an authoritative-looking figure nothing has verified. There is also no time-based staleness rule: a confirmation is flagged only when the entered capacity has changed since it was confirmed, which is a fact, not a threshold. An unconfirmed or missing venue is a named state, never dropped from the list.
How it's calculated
Computed entirely on your device from data already loaded with your venue list — no extra data is fetched, no door scans, no POS. For each owned venue it reads that venue's own capacity setting, its confirmation record, and its scheduled hours, then derives a single state. It does no arithmetic and produces no totals; the only numbers are counts of venues per state.
The exact method
Computed by rcCapReadiness(v) — a pure client function with zero reads. Inputs are venue settings only: v.capacity, v.capacityConfirmation{status, value, confirmedAtMs}, and v.hours. The state→copy map is CAP_READY_COPY, with connected-venue variants in CAP_READY_LINKED and the renderer at renderCapReady. Each row names the venue, its exact state, and its confirmation date where one exists, and opens that venue's Setup › Venue profile. No floor and no readiness gate apply — the card exists to show readiness, so it renders in every state; it collapses only when the Capacity module is not part of your plan.
The research behind it
You can't trust a comparison built on a number nobody confirmed. Before RollCall lets a venue's capacity feed into benchmarking, trend lines, or cross-venue comparisons, it checks three things: has staff actually confirmed the capacity number, does it still match reality, and are scheduled hours set. This is the same discipline hotels use with "available rooms" (the official denominator behind occupancy and RevPAR) and that STR enforces before a hotel's data is allowed into a benchmarking compset — garbage-in, garbage-out doesn't just apply to spreadsheets, it applies to the number everything else is measured against.
-
Beyond Accuracy: What Data Quality Means to Data Consumers ✓ verified
Read the source ↗ -
Uniform System of Accounts for the Lodging Industry (USALI), 11th Revised Edition (2014) / 12th Revised Edition (effective Jan 1, 2026) ✓ verified
Read the source ↗ -
Historical Benchmarking Data Reporting Guidelines ✓ verified
Read the source ↗
Confidence & caveats
The level here is directly observed: the states come from your own entered settings and confirmation records, so counts of venues per state are facts, not judgments. There is no floor and no minimum sample — every owned venue renders whatever its state, and "no reading yet" is shown as its own named state rather than collapsed to a zero.
The one caveat to hold onto: "confirmed by your team" is an internal confirmation, not an external or legal-capacity certification, and readiness means a number is ready to compare with, not that it is correct.