AI in Singapore F&B: Floor vision, table-state alerts

Last updated: 2026-07 FX reference: 1 USD = SGD 1.28, retrieved 2026-07

Stub research page. Lighter than most of the catalogue: no formal market study yet, just reasoning from the camera-based work already mapped elsewhere in this catalogue (UC25, UC30) plus general computer-vision cost curves. Treat it as a working thesis, due a proper pass once someone commits to building it.

The problem this solves

A floor manager's job during service is partly a scanning job: which tables are finishing a course and going quiet, which ones have empty glasses, which ones have a stack of plates waiting to be cleared. A busy floor makes that scan intermittent at best. The table that goes unnoticed for ten minutes after the last plate is cleared is a table that could have turned faster; the glass that sits empty is a round that never gets offered.

A camera pointed at the floor can hold that scan continuously, in a way a person covering six or eight tables at once cannot. The idea already exists in narrower form elsewhere in this catalogue: UC30 covers a camera watching for empty glasses specifically, and UC25 covers camera-assisted anomaly detection at the till. This use case is the broader version, table state generally, not just drinks: ready to clear, next course due, or running low.

What it costs to ignore

No Singapore-specific figure exists for this. The shape of the loss is the same one this catalogue's UC30 page sets out for a missed round: a few extra minutes per table where nobody is watching adds up across a service into slower turns and a few missed rounds. Treat any specific number as illustrative until measured on your own floor.

What good looks like

Prompts a person, never acts alone: the system tells a server a table looks ready to clear or a glass looks low; a person still walks over, reads the table and decides. Nothing happens automatically because of what the camera saw.
Faster table turns: a table sitting finished and uncleared is spotted in the moment it happens, not on the next lap of the room.
Captures the same margin as UC30, more broadly: a low glass prompts a round; this just adds the other floor signals (plates, course pacing) to the same alerting idea.
Worth knowing: this is the sensitive end of the catalogue. A camera pointed at a dining room is pointed at guests, and that is a different privacy conversation to a camera pointed at a keg room or a till. Treat the posture below as non-negotiable, not a detail to revisit later.

How it works

Start from the posture, not the model: prompt the server, never record the guest.

Mechanism: a vision model watches the floor for a small set of physical states, empty plates stacked, a course sitting finished, a glass or bottle running low, and raises a prompt to the assigned server's device when a state crosses a threshold. Nothing is auto-actioned toward the guest; the alert goes to a person.
Design goal, not an afterthought: on-device processing, where the model runs at the camera or on local hardware and only a state (glass low, table clear-ready) leaves the device, not an image or a video stream. No footage of a guest should need to leave the venue's own network for this to work.
Data it draws on: live video of the floor, processed locally; ideally no stored recording of guests at all, only the derived state and a short buffer for model accuracy.
How it decides: simple physical-state thresholds (plates stacked and untouched for N minutes, glass below a fill line), not guest identification, mood reading or anything that requires recognising who is at the table.

Vendor landscape

Singapore-native gap. No vendor observed offers general table-state floor vision for restaurants, in Singapore or globally. The closest adjacent work is generic retail and QSR computer-vision analytics (queue length, footfall), which is a different problem: those tools count people, they don't read table state. Nothing found does the specific combination of clearing, course-pacing and drink-level detection this use case describes.

Buy or build?

Build, and start smaller than the full idea. Rather than a venue-wide rollout, the sensible first step is a small proof of concept in one venue, on one or two cameras, testing whether the alerts are accurate enough and useful enough to earn a server's attention before it goes anywhere near a wider rollout. If servers start ignoring the prompts within a week because the false-alarm rate is too high, that is the answer, cheaply learned.

Singapore-specific considerations

PDPA: a floor camera pointed at guests is personal data by default. On-device processing that discards the image immediately after deriving a state, and never stores or transmits guest video, is the design goal that keeps this workable; anything that stores footage of guests needs its own consent and retention conversation, and should follow the same reasoning this catalogue's UC25 page sets out for camera-based monitoring.
Signage and disclosure: a venue running any camera on the floor, for this or any other reason, should disclose it the way CCTV is normally disclosed, regardless of what the camera is technically looking for.
Grants: untested. No vendor is pre-approved for this pattern, so budget it as a cash-funded build.

Related in this catalogue: UC30, beverage refill prompting is the narrower version of this idea already in the catalogue; its camera-assisted v2 effectively lives inside this broader use case. UC25, tab anomaly detection is the page to read first on the PDPA and camera-monitoring reasoning that applies here with even more force, since this camera watches the dining room itself rather than the till.

Sources

This catalogue, UC30 beverage refill prompting research (the narrower, drink-specific version of this idea); internal; 2026-07.
This catalogue, UC25 tab anomaly detection research (PDPA and camera-monitoring reasoning); internal; 2026-07.

This is part of a series on AI use cases for Singapore F&B operators, refreshed every two months. If you'd like to discuss applying any of this to your restaurant, get in touch at [email protected].