TabPFN + Gemma: Building a No-Show Assistant for Small Motels

The thing small motels fear most isn't a lack of bookings — it's guests who book a room and then silently never show up. If no deposit was collected in advance, that night's revenue is gone for good. To address this, one developer built No-Show Desk: every morning it surfaces the arriving guests most likely to cancel, explains why in plain language, and drafts a short "are you still coming?" confirmation email that the owner decides whether to send.

What's notable is the technical stack: predictions use TabPFN (a pretrained model designed specifically for small tabular datasets), writing uses Gemma 4 (Google's open-source model, running locally right in the browser), and fact-checking is handled by plain code. The author built the entire system around a single principle: code does the computing, the model does the phrasing.

Why small motels need no-show prediction

Every time a guest fails to show without notice, the motel loses a night's room rate. Yet in many cases, a quick check-in question prompts the guest to explain a change of plans, and the room can still be resold to someone else. No-Show Desk's goal is to let the owner spend one minute each morning knowing who to ask, thereby freeing up potentially vacant rooms in advance.

The author had originally been pitching motels on a "voice assistant that answers the phone when no one's at the desk," but this week's Hacktoberfest theme called for building something "a small business would actually pay for." So he pivoted to a smaller wedge: one list and one email per day, simple enough that a few owners would be willing to try it. The pricing logic is equally clear — on demo day, 4 of the 7 flagged guests actually canceled, representing $776.60 in bookings, while local nightly rates range from $67 to $107. Rescue just one night per month and the tool pays for itself.

Data and prediction: TabPFN's edge on small samples

No public motel dataset exists, so the author used the Hotel booking demand dataset (Antonio, Almeida & Nunes, 2019): 119,390 real bookings from two Portuguese hotels spanning 2015 to 2017. All 1,207 no-shows were labeled as cancellations, so the model predicts both outcomes. Every test ran on a "motel-sized" slice of the data: about 3,000 historical bookings, with 20 arriving guests each morning.

One critical pitfall in data cleaning: some fields are only filled in after the guest arrives, which directly leaks the answer. For example, bookings that recorded a parking space had a cancellation rate of 0.0%, because parking is only logged once the car shows up. The author removed six such fields, and all tests learned only from bookings before a given date and scored bookings after it, fully simulating real-world usage. Additionally, the model only scores bookings without a deposit, since cancellations after prepayment cost the owner nothing (in this data, non-refundable bookings had a "cancellation" rate as high as 99.4%).

TabPFN wins across the board at motel scale

A 20-room motel has at most a few thousand historical bookings. TabPFN is pretrained on massive synthetic tables and learns a new table in a single step, with no training runs needed from the author. The author had TabPFN, gradient boosting (the standard tool for tabular data), and plain logistic regression each learn from 300, 1,000, and 3,000 historical bookings — three copies of each history size — then scored them all on the same 5,000 bookings from 2017, measured by ROC-AUC.

TabPFN ranked first in all 9 runs: 0.721 with 300 histories, 0.766 with 1,000, and 0.778 with 3,000; gradient boosting scored 0.682, 0.702, and 0.747 respectively. Logistic regression came closer than expected (0.699, 0.741, 0.749), so the honest summary is: TabPFN wins at every scale, but only leads the regression model by 0.02 to 0.03.

Validating the threshold on an unseen year

The author's initial version set the risk line at 50%. The result: on the first demo morning, only 1 of 20 guests was flagged — and that guest didn't cancel — while all 4 guests who actually canceled were missed, because only about 30% of guests cancel, so very few scores ever exceed 50%. So the author set the threshold at 30% across 30 mornings in 2017, then — because "choosing a threshold and reporting on the same data is peeking" — validated it on a separate 30 mornings in 2016 that played no part in the selection.

On the 2016 data, the 30% line still caught more cancellations than the "top 5 riskiest" rule or the 50% line, and the 50% line flagged no one at all on two mornings. A 25% line caught even more, but a lower share of flagged guests actually canceled.

ROC-AUC is a common metric for evaluating a binary classifier's ranking ability, short for "area under the receiver operating characteristic curve." It measures the probability that, given one randomly drawn positive sample and one negative sample, the model assigns the positive a higher score. A value of 0.5 is equivalent to random guessing, and 1.0 is perfect ranking. In this article's setting, positives are bookings that ultimately canceled and negatives are bookings where the guest arrived normally. AUC cares only about relative ranking, not absolute probabilities, making it especially suited to ranking tasks like "pick the N guests most likely to cancel each day." An AUC of 0.72 to 0.78 means the model has decent discriminative power but isn't perfect — which explains why the 30% threshold still misses some cancellations.

Gradient Boosting is a family of ensemble methods based on decision trees that improve prediction accuracy by progressively fitting the residuals of the previous round; XGBoost and LightGBM are its representative implementations. It has long been the "default strongest" baseline on medium-sized tabular data, but it needs sufficient sample size and tuning to shine. In this article it scored only 0.682 AUC with 300 histories, clearly trailing TabPFN's 0.721, showing the value of pretrained priors on small samples.

Can rules replace the model?

All 7 guests flagged on demo day had booked through the same travel agency (data ID #9) — couldn't the owner just write a rule? The author compared each rule using the same number of daily emails as the model:

Same daily email count	Cancellations caught out of 172
TabPFN, 30% line	111
Logistic regression, fit on each day's history	106
Online travel agency first, then booking lead time	99
Agency #9 first, then booking lead time	94
Booking lead time first	81

The best rule the author could devise caught 99; TabPFN caught 111 by weighing all factors together.

Readable explanations and "code computes, model phrases"

TabPFN only outputs probabilities, not reasons, so explanations come from simple counting: if the group a guest belongs to (booking lead time, travel agency, channel, meal plan) has a cancellation rate at least 5 percentage points above all non-deposit bookings, and that group has at least 30 records, it gets called out by name. The explanation describes the group; the ranking still comes from TabPFN.

The writing step best embodies the author's core philosophy. He gave Gemma the same 50 bookings with two drafts each: one with the raw record ("arrival 2017-08-23, 2 weekend nights, 5 weekday nights, avg rate 160.2"), and one with facts computed by code ("arrives Wednesday, August 23; departs Wednesday, August 30; 7 nights; $1,121.40"). The result: when Gemma worked out dates and amounts itself, 13 of 100 drafts got the date, night count, or total wrong; when code supplied the facts, the error count was 0.

Starting from the raw record, Gemma once wrote to a guest named Grace: "Your reservation is confirmed from August 23 to August 25, 2017, for 2 nights, totaling $320.40." The actual booking was 7 nights at $1,121.40. Another draft even said "free cancellation until April 0." And every one of these drafts read fluently and warmly.

A pure-Python validator compares the dates, night counts, and amounts in each draft. The author also shared three issues found through human reading: the validator initially raised 25 false positives, of which 13 were actually correct answers in formats it couldn't recognize; the system once supplied a free-cancellation date that had already passed; and his instruction to Gemma — "mention the date if there is one" — led the model to write an "[Insert Date Here]" placeholder, with every number correct, which the validator let through at the time. The fix followed the same principle: code decides whether the sentence exists, and the validator now catches placeholders too.

Running Gemma locally in the browser

On an 8GB Mac, running Gemma through Ollama takes about 30 seconds per draft. Google also released a 2GB version of the same small Gemma 4 model that can run in a web page via WebGPU using the computer's GPU. The author had the browser version process the same 100 drafts with the same validator: zero factual errors, with a median time of 3.25 seconds versus 31.4 seconds for Ollama.

Human reading, however, surfaced issues the validator couldn't cover: a few drafts omitted facts — for example, failing to state the night count for a one-night stay — 6 in the browser version and 5 in the Ollama version, but none stated incorrect information. Real devices also forced two page changes: after downloading the full model, Safari reloaded the page on an iPhone 15 Pro (very likely out of memory), so the mobile version switched to showing pre-written messages; and the 8GB Mac briefly froze once after Gemma loaded.

WebGPU is a modern standard interface that exposes the underlying GPU to the browser, replacing the earlier WebGL compute path and letting JavaScript directly schedule the GPU for parallel matrix operations. This lets small language models with a few billion parameters run inference inside a browser tab without a backend server. Combined with local model runtimes like Ollama (one command to pull and host a model, called via a local HTTP interface), developers can choose between "fully local" and "local in the browser." The former relies on the machine's CPU/memory, while the latter can leverage GPU acceleration — which is exactly where this article's 3.25-second versus 31.4-second gap comes from; but browser execution is constrained by per-tab memory limits, and the Safari reload on iPhone due to out-of-memory is a typical manifestation.

Why open source and localization matter

A no-show message contains the guest's name, dates, and amount. Gemma drafts it on the owner's own computer, so this information never leaves the local disk. There's also no per-message billing — the test day flagged about 7 guests per day on average, so a paid writing API would rack up costs daily; here the model is just a file on the owner's disk. For a small business with only a few thousand rows of data, TabPFN needs no training and no data scientist, matching the real data volume of a motel.

The author is also candid about one part not yet localized: TabPFN scoring currently runs through Prior Labs' API, so booking details (no names — this dataset has none anyway) leave the computer once each morning. However, TabPFN v2's weights can run locally, and its license permits commercial use with attribution. The author measured it: about 23 seconds each morning on an 8GB Mac, v2 caught the same 111 of 172 cancellations across 30 test mornings, flagging 205 guests instead of 210 (ROC-AUC 0.787 vs. 0.792 for the API). That's a viable path to the paid version.

TabPFN's core idea is "Prior-Data Fitted Network": pretrain a Transformer on massive synthetically generated tabular tasks so it learns to "given a training set, directly output the predictive distribution for test samples." At inference time there's no gradient training — just feed the training set in as context and a single forward pass completes the prediction, making it extremely friendly to small tables. Its v2 weights can be downloaded and run locally, and the license permits commercial use with attribution. In this article, local v2 scores in about 23 seconds each morning on an 8GB Mac, with AUC 0.787 essentially on par with the API's 0.792 — showing "localization doesn't sacrifice accuracy," it just requires a one-time deployment cost.

What's real and what's unverified

The author draws clear boundaries: the booking data, TabPFN scores, explanations, Gemma drafts, and every validation are real; but "whether sending a message gets the guest to reply, and whether the room actually gets resold" was not measured — only a real motel can verify that. His first potential user was a motel owner he'd previously pitched the voice assistant to, who said he'd use it if there were more cancellations and considered it more convenient, cheaper, and easier to deploy than the voice assistant — but cancellations are currently too few, so he hasn't tried it yet. A second owner is in talks, and the author says the first question he'll ask is: has a reply ever arrived early enough to resell the room?

The project is open-sourced on GitHub (MIT license) with an online demo, including 61 logic tests, and all measurements are generated and archived by scripts. For developers who want to build AI tools for small businesses, this project offers a paradigm worth borrowing: use a pretrained model built for small samples to predict, a small local model to phrase, and deterministic code to guard the factual floor.