Night Venue Scheduling: Why the Roster Never Matches the Room

Almost every night venue schedules the same way: someone posts a week in a group chat, people reply, the manager keeps the real version in their head, and Friday is fixed by phone at four in the afternoon.

It works, in the sense that the shifts get covered. What it cannot do is tell you anything. There is no record of who was asked and said no, no record of the request that came in and was never granted, and no way to know whether Thursday is thin because demand moved or because three people quietly stopped picking up shifts.

The schedule is the largest lever in the business and in most rooms it is the least instrumented. Here is what to measure and what each number decides.

The four objects

Scheduling gets confusing because four different things get called "the schedule":

Object	What it is
Availability	when someone says they can work
Roster	who is assigned to a shift
Roll call	who actually showed
Demand	what the room needed

Almost every scheduling problem is a gap between two of these, and naming which gap you are looking at is most of the diagnosis.

Fill rate: roster against demand

Fill rate = shifts covered ÷ shifts needed
Gap hours = Σ (hours needed − hours covered), by hour of night

What it decides: recruitment, and specifically when. Fill rate quoted as a weekly average is nearly useless, because shortages are never spread evenly. Broken out by hour and weekday, it usually shows that the problem is two specific windows rather than a general shortage — and two windows is a scheduling fix, which is far cheaper than hiring.

The most common finding: a room that believes it is understaffed is frequently over-rostered early and under-rostered at peak, with the same total hours. Redistributing costs nothing.

Show rate: roll call against roster

Show rate      = staff who showed ÷ staff rostered
Late rate      = staff who checked in after start ÷ staff who showed
Coverage shrink = rostered hours − actual hours worked

What show rate decides: how much to over-roster, and by how much. Most rooms either do not over-roster and run short on the nights it matters, or over-roster on instinct and pay for hours they did not need.

Coverage shrink is the number to actually watch. It moves before anything else does. A widening gap between rostered and worked hours is the earliest available signal that your roster is drifting — people arriving late, cutting out early, or quietly stepping back — and it shows up weeks before it shows up in the revenue.

Track shrink per person, not just in total

The aggregate hides the pattern. Shrink concentrated in two or three names is a conversation. Shrink spread thinly across everyone is a scheduling or pay-structure problem, and treating the second as if it were the first is how rooms lose people they meant to keep.

Request-to-grant: the record nobody keeps

Staff submit availability. Managers build the roster. Almost nobody records what was requested and not granted.

Grant rate      = requested shifts granted ÷ requested shifts
Unmet requests  = requested shifts not granted, by person

What it decides: who leaves next. Someone who asks for four shifts and gets two is telling you their earnings are being capped by you rather than by the market, and they will find a room where they are not. This is the single most predictive retention signal available in a night venue, and almost no one records it, because the request usually arrives as a chat message that scrolls away.

Recording availability in a form rather than a chat is the entire fix. It costs nothing and it creates the dataset.

Retention, shift-weighted

Shift-weighted retention = staff working ≥ N shifts this period
                           who also worked last period
                           ÷ staff who worked last period

Why shift-weighted: a headcount figure counts someone who worked twice the same as someone who worked twenty times, which is exactly backwards for understanding whether you are keeping the people who carry the floor.

What it decides: hiring, a full cycle before you would otherwise notice. It leads revenue, because a thinning roster shows up in what you can sell before it shows up in what you sold — and rebuilding a roster is much slower than losing one.

Demand: the half that is usually guessed

Everything above compares the roster to a demand figure, and most rooms have no demand figure. They have last week's roster, which is a record of a previous guess.

A usable demand curve, cheaply:

For each weekday and hour, over the trailing 8 weeks:
  median guests present, median bookings, median revenue

Three numbers per cell. Eight weeks of history you already have in the POS and booking log. This one table changes more scheduling decisions than any software, because it converts "Thursdays feel quiet" into a shape with hours attached.

Then schedule against the curve rather than against last week. Scheduling against last week propagates every mistake forward indefinitely, which is why rosters in this industry ossify.

What a scheduling system has to do to be worth having

Four things. Most products in this space do the first and skip the rest.

1. Take availability as structured data, not as chat messages. This is what creates the request-to-grant record.
2. Record roll call, not just the roster — the actual check-in, from the staff member's own phone, so the record exists without a manager transcribing it.
3. Hold the demand curve so the roster can be built against demand rather than against the previous week.
4. Compute shrink and retention from its own data, so the warning arrives without anyone running a report.

The system we built

tasteck is a booking and analytics system for night venues, and scheduling is one of the parts we built because we were running it, not because a roadmap said to.

What it does: staff submit availability from their own phones in structured form; the roster is built and published from it; staff check in and out themselves so roll call is real rather than transcribed; and schedules, shifts and settlement sit in the same system as the bookings, so the demand side and the supply side are not two separate spreadsheets.

For rooms running outcall there is dispatch and live driver status on the same surface, and for rooms taking bookings by phone the reservation screen is wired to inbound calls, so a call becomes a booking record without retyping.

And then the part that has nothing to do with scheduling

Your roster is sized to your demand. Demand is bought. So the question one layer up from the schedule is what you can afford to pay for demand — and that is where tasteck does something no other product in this category does:

It outputs the maximum you can spend on each marketing channel next month, in your currency.

Guest records that persist across visits, first-touch source attribution, revenue by source through to lifetime value, and then a ceiling per source as an amount. Not a chart. A figure you take into the renewal call.

Built by operators

tasteck was built by people who ran venues in this industry for sixteen years and grew from ¥200 million to ¥1.2 billion a year — six-fold, by attacking it with systems rather than by selling harder. Every competitor here is a software company's model of the business. The reason availability, roll call, dispatch and settlement are on one surface is that this is what it took to run the nights.

Ask it from ChatGPT

tasteck connects to ChatGPT over MCP: ask the roster a question and get the answer in the chat — who is short this week, whose shift hours are shrinking, what Thursday's demand curve looks like.

Measured against every vendor listed on Japan's principal nightlife-industry directory, this is the first implementation of it in the category. The same interface is callable from anywhere rather than being tied to one assistant.

Multi-language is built in — the operating surface itself, with your language set put in place during onboarding.

From $34 a month for up to two venues. Thirty days free on every plan, cancel any time. → Pricing

Start here

1. Move availability out of the group chat into a form. One change, and it creates the request-to-grant record that predicts who leaves.
2. Record actual check-in and check-out. Coverage shrink is uncomputable without it and is your earliest warning.
3. Build the demand curve — weekday × hour, trailing eight weeks, from data you already have.
4. Roster against the curve, not against last week.
5. Put shift-weighted retention on the board and watch it ahead of the revenue line.

Items 1 to 4 need a decision and a spreadsheet. If you want the ceiling calculation for the demand side, it is open on our site with nothing to sign up for: Ad budget calculator. Nothing is transmitted anywhere.

---

On benchmarks. No target ranges for fill rate, show rate, grant rate or retention appear here. We do not have a dataset broad enough to publish them, and they vary widely by format, city and pay structure. Build your bands from your own trailing weeks — that is the only benchmark that describes your room.