AI in Singapore F&B: Beverage refill prompting

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 floor evidence from RAS 2026 and one experienced operator's read. Treat it as a working thesis, due a proper pass once someone commits to building it.

The problem this solves

No one should ever have to sit with an empty glass wondering whether to flag someone down. It's a small moment, and it happens constantly: a glass runs low mid-conversation, the table's attention is elsewhere, and by the time a server notices or the guest decides to ask, several minutes of drinking time and a round of revenue have quietly gone. Beverages are the margin engine of the whole meal, poured at near-zero incremental prep cost once the bottle is open, so every refill that doesn't happen because nobody was watching is close to pure margin left on the table.

An experienced operator put it plainly: the number of times a guest has sat waiting for another drink, at roughly SGD 22 a drink, adds up across a service, a night, a year. The gap isn't pricing or menu design, it's attention. A server working several tables simply can't watch every glass all the time.

What it costs to ignore

No quantified Singapore study exists for this exact pattern. The arithmetic is easy to run for your own floor: at roughly SGD 22 a drink, even one missed round a table per service, across a full night's covers, is a material number of drinks a week that a prompted server would likely have sold. Treat this as illustrative, not a sourced estimate; it's the kind of number worth actually measuring on your own floor before committing budget to it.

What good looks like

Nobody waits: a server gets a nudge before a guest has to ask, so the next round lands as attentive service rather than a sales pitch.
Captures near-zero-cost margin: the drink itself costs almost nothing extra to pour; the only cost was the attention to offer it.
Cheap to start: a first version needs no camera at all, just POS timing, which keeps both the build cost and the privacy question small.
Worth knowing: a camera-based version (watching glasses directly rather than inferring from POS timing) raises real PDPA and guest-privacy questions that this catalogue's UC25 tab-anomaly page already treats seriously; the same care applies here before pointing any camera at a table.

How it works

Start from what the POS already knows; add a camera only if the heuristic proves out.

Mechanism (v1, no camera): a heuristic runs off POS timing alone, a glass of wine or a bottle poured N minutes ago crosses a threshold, and the system prompts the assigned server to check that table. No new hardware, no vision model, no image of a guest anywhere.
Mechanism (v2, camera-assisted): a camera on the pass or floor estimates fill level directly rather than inferring it from elapsed time, which is more accurate for drinks with irregular pour and drink rates, at the cost of pointing a camera at guests.
Data it draws on: POS pour timestamps and item type for v1; image data from a floor or pass camera for v2.
How it decides: a threshold prompt to a person, never an automated upsell message to the guest. A server still makes the offer and reads the table; the system's job is only to make sure attention doesn't lapse.

Vendor landscape

Singapore-native gap. No vendor observed at RAS 2026 addresses this pattern, in Singapore or globally. Bar and beverage tools in this catalogue's UC23 (keg and cellar management) and UC26 (pour-cost variance) research track what's poured against stock, which is an inventory question; nothing found prompts a server in the moment to offer the next round.

Buy or build?

Build, and start with the cheap version. The POS-timing heuristic needs no new hardware and no camera, which sidesteps the privacy question entirely for a first version; validate whether prompted servers actually convert more rounds before spending anything on the camera-assisted version, which is a materially bigger build and a materially bigger privacy conversation.

Singapore-specific considerations

PDPA: the POS-timing version (v1) carries no guest personal data beyond what the POS already holds. A camera version (v2) is a different question entirely, footage of guests at their table, and should follow the same PDPA and guest-consent reasoning this catalogue's UC25 page sets out for camera and video-based monitoring, before it goes anywhere near a pilot.
Liquor licensing: a prompt to offer another round is service, not a promotion, so it shouldn't intersect with Liquor Control promotion rules the way a discount or free-drink offer would; keep it that way by design.

Related in this catalogue: UC24, fixture and event demand triggers and UC07, menu engineering and pricing are the other places in this catalogue reasoning about margin capture from data already sitting in the POS. UC25, tab anomaly detection is the page to read first on the PDPA and guest-privacy reasoning that would apply to any camera-based version of this.

Sources

RAS 2026 show-floor observation, Singapore, informal vendor survey, not exhaustive; first-hand; July 2026.
An experienced operator's estimate of missed rounds at roughly SGD 22 a drink; verbal, anonymised; July 2026.
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].