AI in Singapore F&B: Bottle-keep by photo
Last updated: 2026-07 FX reference: 1 USD = SGD 1.28, retrieved 2026-07-28.
This is a new idea, still at prototype stage — it has not yet been tested against real handwritten logs, and that test needs to happen before it is promised to anyone.
The problem this solves
You want to offer bottle keep — guests ask for it, you can see the demand — but you have no idea how to organise one. That is the gap this idea targets, and it sits upstream of our fuller bottle-keep management use case, which assumes a working registry already exists (bottle, fill level, expiry, reminders). Most operators never get that far, because what you actually have today is a paper log or a spreadsheet at the till, and moving off it looks like a data-entry project nobody has time to start.
The real barrier is onboarding, not day-to-day running. However good a bottle-keep system might be, someone still has to type in every bottle already sitting on your shelf — guest name, bottle, date, fill level — off a stack of paper tags or a flip-book, possibly running to hundreds of entries. That single task is where good intentions to "get this organised" usually die.
The idea, raised directly by an operator in conversation: photograph your end-of-day paper log as it already exists, and let the system read it. No new process for your floor staff — just a photo.
What it costs to ignore
There is no credible Singapore-specific figure for this, and we would not invent one. The real cost is an adoption barrier rather than a hard loss: operators who would want a bottle-keep programme, and can see the guest demand for it, never start one, because the first step — digitising what is already on paper — looks like an open-ended manual project. Every month that barrier stays in place is a month without the return-visit reminders a working bottle-keep registry could be generating.
What good looks like
- Almost no change to how your floor works — the ask is a photo of a log you are already keeping, not new software for staff to learn.
- A faster route into a proper system. Instead of a slow manual backfill before a bottle-keep programme is worth switching on, your existing paper history could seed it from day one.
- One less reason to keep putting it off — for an operator who has never organised bottle keep, this removes the biggest reason it never gets past "we should really do that".
- Honestly, accuracy is the open question. Real bar logs are handwritten under service pressure, in different hands, sometimes smudged or abbreviated. Whether this reads reliably enough to trust without checking is unproven, and we are not going to claim otherwise until it has been tested on real logs, not clean synthetic ones.
How it works
- Mechanism: a photo of the log page goes to a vision/OCR step that proposes structured entries — guest name, bottle, date, fill level — from the handwriting.
- Data it draws on: the photo itself, and, once seeded, the registry it feeds. No POS or booking system integration is needed for this part.
- How it decides: it does not decide anything on its own. Every batch of extracted entries goes to a person to check against the photo and correct before anything is saved — deliberately, given how honestly uncertain the handwriting accuracy still is.
Typically built as a simple photo-in, human-checked capture step sitting in front of a bottle-keep registry — most naturally the fuller registry-and-reminders system this feeds into, where it becomes the way you get started rather than a manual backfill.
Vendor landscape
As expected for something this specific, nothing purpose-built exists for photographing a bar's bottle-keep log. The realistic building blocks are general-purpose document-OCR and vision APIs from the major cloud providers, plus vision-capable AI models such as Claude or GPT-4-class tools — none of which does the full job out of the box, and all of which need a human check-and-confirm step layered on top. One consumer handwriting-OCR specialist tested well in a 2026 independent comparison and is worth knowing about even though it has no Singapore presence or F&B focus.
| Vendor | Origin | SGD/month | Suited to |
|---|---|---|---|
| Google Cloud Vision | US | Roughly SGD 1.90 per 1,000 pages beyond a free monthly allowance — likely under SGD 5/month at single-venue volumes | A build team wanting the cheapest general-purpose OCR call |
| AWS Textract | US | Roughly SGD 1.90 per 1,000 pages, with a limited free tier | A team already using AWS |
| Azure AI Document Intelligence | US | Roughly SGD 1.90 per 1,000 pages | A team already using Azure |
| Claude / GPT-4-class vision models | US | Token-based; low single-digit SGD/month at bar-log volumes | The most realistic build path — reads the image and returns structured entries in one step |
Independent testing in 2026 found handwriting recognition sitting well behind printed text across the board — clean printed text under 1% character error versus roughly 3-5% for handwriting industry-wide, with far wider swings between individual tools. The same research flagged that handwriting errors cluster in the fields that matter most (names, dates, quantities), so a good headline accuracy number can still mean a wrong entry on the exact row a guest disputes. None of this has been tested against a real venue's own handwriting yet — that is the next step, not a vendor choice.
Buy or build?
This is a build: a thin photo-capture-and-confirm layer over a general-purpose OCR or vision API, because nothing purpose-built exists to buy. Its own value is small on its own — the value is in what it feeds, a proper bottle-keep registry. Before any build work, a short accuracy test against a handful of your own real handwritten logs matters more than picking a vendor, because the whole point (no new floor process) only holds if the extraction is good enough that checking it is quick corrections, not a full re-transcription.
Singapore-specific considerations
- PDPA: a photographed log contains guest names, so the resulting entries are personal data from the moment of capture. The photos themselves should not be kept longer than needed to extract and check the entries.
- Liquor Control (Supply and Consumption) Act: not directly engaged by the photo-capture step, but any reminder messaging this eventually feeds should respect licensed trading hours.
- Grants: no tool this narrow is likely to qualify on its own; it would only be grant-relevant as a small part of a larger co-funded membership or registry build.
Sources
- OCR with Google AI — https://cloud.google.com/use-cases/ocr — vendor — accessed 2026-07-28
- Amazon Textract pricing — https://aws.amazon.com/textract/pricing/ — vendor — accessed 2026-07-28
- Azure AI Document Intelligence pricing — https://azure.microsoft.com/en-us/pricing/details/document-intelligence/ — vendor — accessed 2026-07-28
- HandwritingOCR.com — https://www.handwritingocr.com/ — vendor — accessed 2026-07-28
- imagetotable.ai — OCR Handwriting Accuracy: Why 90% CER Still Means Wrong Totals — https://imagetotable.ai/blog/ocr-handwriting-accuracy-reality — independent/industry blog — accessed 2026-07-28
- AIMultiple — Handwriting Recognition Benchmark: LLMs vs OCRs — https://aimultiple.com/handwriting-recognition — independent/industry benchmark — accessed 2026-07-28
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].