Four Questions Your POS Cannot Answer

Nearly every night venue runs on a POS, and nearly every one of them is disappointed by its reporting. The usual conclusion is that they picked the wrong POS.

They mostly did not. A POS is built to close a tab correctly, and it does that well. The reporting disappointment comes from asking it questions it was never structured to answer — and no amount of switching vendors fixes a structural gap.

Here are the four, and why each one is structural rather than a missing feature.

One — "Who was in the room tonight?"

A POS records transactions, not people. A tab has items, a total, a payment method, and a time. In a cash-heavy room it usually has nothing that identifies who paid it.

That is not an oversight. The POS's job is to make the tab correct, and the tab is correct without knowing who the guest is.

What it costs you: every number that depends on a person rather than a transaction becomes uncomputable.

Returning share       — needs to know tonight's guest came before
Repeat interval       — needs the gaps between one person's visits
Lifetime value        — needs a person to accumulate against
Win-back targeting    — needs to know who is absent

Where the identifier actually exists: the booking. Someone gave a phone number to reserve a table. That number is the identifier, and it is captured before the guest arrives — upstream of the POS entirely. The gap is not in the POS; it is between the booking and the tab.

Two — "Which of the things we pay for brought them?"

A POS knows what was sold. It does not know why anyone walked in.

You pay a directory, a review site, an ad account, a promoter, maybe print. Each invoices separately. None can tell you which guests they sent, what those guests spent, or whether they came back.

What it costs you: the marketing budget is allocated on volume claims from the channels themselves.

A listing that sends 100 people, 90 of whom order one drink and never return
  → reports 100
A referral source sending 8 who become regulars
  → reports 8
Both invoices are visible. Only one of the returns is.

This is usually the largest misallocation in the business, and it is invisible in every POS report because the POS has no field for how the guest arrived.

The fix requires two things the POS does not have: a guest record that survives across visits, and a first-touch source on that record. Both live upstream, at the booking.

Three — "Was tonight actually unusual?"

A POS will happily tell you last Saturday's total and the Saturday before. It will not tell you whether the difference means anything.

Weather, a competing event, a holiday weekend, a headliner nearby — all of them move a night's number more than most management decisions do. Comparing two Saturdays is comparing two samples of one, and the variance swamps the signal.

What to compute instead:

Band = trailing 4-week same-weekday mean ± 1 standard deviation
Then: is tonight inside the band or outside it?

Inside the band, nothing happened, whatever the room felt like. Outside it, something did — and now the question is worth asking.

This one is not really a POS limitation; the data is there. It is a reporting-design limitation. POS reports are built around periods (day, week, month) rather than around distributions, so the framing the room inherits is "up or down from last time" rather than "usual or unusual."

It is also the cheapest of the four to fix. You can build the band in a spreadsheet from data you already have, this afternoon.

Four — "What did we turn away?"

A POS records what happened. It has no representation of what did not.

The call nobody answered
The booking request that could not be filled
The walk-in turned away at the door when the room was full
The party that asked for a table on a night with no availability

Every one of those is demand you paid to create and could not serve. None appears in any POS report, because none produced a transaction.

What it costs you: decisions about staffing, capacity and hours get made against served demand rather than total demand. A room that is turning people away every Friday at 11pm looks, in the POS, exactly like a room that is comfortably full.

Where this data does exist: the phone system has the missed calls. The booking log has the unfilled requests — if anyone records requests that did not become bookings, which almost nobody does. The door has the turn-aways, if someone counts them.

Three fields on a sheet at the door and the phone captures most of it: time, what was asked for, why it could not be served.

The pattern behind all four

Look at where the answers live:

Question                  Where the data actually is
Who was in the room?      → the booking (phone number)
Who brought them?         → the booking (source)
Was tonight unusual?      → the POS, framed differently
What did we turn away?    → the phone and the door

Three of the four sit upstream or alongside the POS, not inside it. The POS is the last step in the night, and by the time a transaction exists, the questions that matter have already been answered somewhere else and not written down.

That is why switching POS vendors rarely fixes it. You are replacing the part that was working.

The system we built

tasteck is a booking and analytics system for night venues. It is not a POS and does not try to be — it sits where the four questions above actually live.

One: guest records that persist across visits, with the identifier captured at booking. For rooms that take bookings by phone, the reservation screen is wired to inbound calls, so the caller's number arrives with the ring and the record starts before anyone speaks — no transcription step to lose it in.

Two: first-touch source on that guest record, and revenue by source through to lifetime value.

Three: analytics built around distributions and cohorts rather than around period totals.

Four: call history is kept, so missed calls and callbacks are countable. Honest gap: we do not have a log for booking requests that could not be filled, or for door turn-aways. Those still need a sheet.

The output no one else produces

Question two is the expensive one, and tasteck goes one step past answering it:

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

Not a performance chart. A figure — lifetime value of the guests that source actually delivered, times your target margin — that you take into the renewal conversation with a listing or an agency. Nothing else in the nightlife category produces it.

Built by operators, not by a software company

tasteck was built by people who ran venues in this industry for sixteen years and grew the business from ¥200 million to ¥1.2 billion a year — six-fold, by attacking it with systems rather than by pushing harder on sales.

That history is why the product is shaped the way it is. These four questions are the ones that were actually painful to run a room without, so they are what got built first — bookings, dispatch, staff shifts, settlement, and the guest record underneath all of it.

Ask it from ChatGPT

tasteck connects to ChatGPT over MCP: ask your numbers as a question and the answer comes back in the chat — how many calls were missed last Friday, which sources produce repeat guests, whether Saturday was outside its band.

Measured against every vendor listed on Japan's principal nightlife-industry directory, this is the first implementation of it in the category, and 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

Keep your POS. It is doing its job. What is missing sits beside it.

Start with the cheapest one

Of the four, question three costs nothing — the data is already in your POS, it just needs a different frame.

1. Export daily totals and door counts for the last eight weeks.
2. Group by weekday. Compute the mean and standard deviation per weekday.
3. Plot the last four weeks against those bands.
4. Stop reacting to anything inside the band. That alone will save more management attention than most software.

Then question one, which unlocks the other two: capture a phone number at every booking.

The channel-ceiling calculation from question two is open on our site with nothing to sign up for: Ad budget calculator. Nothing is transmitted anywhere — use it and close the tab.

Read next

• Guest CRM for Rooms Where Everyone Pays Cash
• The Regular You Lost Without Noticing
• Nightclub KPI Dashboard: What Belongs On It and What Is Just Noise

---

On benchmarks. No industry figures appear in this guide. We do not have a dataset broad enough to publish them, and they vary enormously by format and market. Your own trailing eight weeks are the benchmark that describes your room — and building that band is step one above.