The Operating System for a 10-Room Hotel

At a glance

• What: an LLM-run operations layer for a 10-room mini hotel — a system that owns the paperwork, not just a collection of scripts.
• Why: Vietnamese law requires every guest's ID to be registered with the local authorities. Done by hand, that's hundreds of ID cards typed in one at a time.
• My role: solo builder — this runs my own operation, a 10-room mini hotel in Nha Trang, Vietnam.
• Stack: n8n · Airtable · Python · on-device Apple Vision OCR · an LLM (Gemini via the agy CLI).
• What's live: automated guest registration, an AI content pipeline, and monitoring — all running on real data today.
• Result: 407 guests in the CRM, 100% with an ID image attached, 84% read with no human touch, 68% processed on-device; 263 bookings inferred and 11 returning guests surfaced — from one double-click.

The problem

Under Vietnamese law, every guest who checks into a hotel has to be registered with the local police — khai báo tạm trú. It isn't optional paperwork; it's a legal requirement enforced at the front desk. For a 10-room mini hotel running near capacity, that means reading a national ID card or a passport for every guest, on every stay: name, document number, date of birth, nationality, dates. Multiply that across a full year of turnover and it adds up to hundreds of cards, typed in by hand, between check-ins.

It's also a chore that concentrates risk in exactly the wrong place. Every one of those cards is government ID — full legal identity, a document number, sometimes a passport. Handling that on a phone at the desk, then again in whatever spreadsheet or notebook ends up as the real record, multiplies how many places that data touches and how many chances it has to be typed wrong, saved wrong, or seen by someone who shouldn't see it. Any automation that touches this problem has to solve the paperwork and behave responsibly with the data behind it, or it isn't worth building.

Registration was also only ever the front half of the job. Once a guest's stay is on record, the natural next questions are operational ones: who has stayed before, how many nights has the property actually sold this month, is a booking sitting in three different notebooks instead of one. Doing the legal paperwork by hand left no time or attention for any of that — the desk work consumed the hours that should have gone into running the hotel as a business.

The system

The system replaces the manual keyboard work with an LLM orchestrated by n8n flows, with Airtable as the single source of truth. A folder of ID photos goes in; a matched, deduplicated guest record — with its booking history attached — comes out, without anyone re-typing a document number by hand.

n8n owns the schedule and the triggers: when to run, what to run next, when to hand off to the content pipeline or the monitoring layer. Airtable owns the data: every guest record, every inferred booking, and every piece of published content lives in one place that the automation and I can both see and edit by hand if needed. The LLM sits in the middle as a narrow specialist, not a manager — it's called in for two specific jobs (cleaning up an ID the on-device pass couldn't read, and drafting marketing copy), not for deciding what the hotel does.

That division of labor is the reason the phrase "operating system" fits better than "script" or "bot". A script runs once and stops; this system is a standing layer that the hotel now runs on — one that a second automated pillar (the content pipeline) and a third (monitoring) already plug into the same Airtable base, with room for more to plug in later.

What's live today

Guest registration

Every export starts the same way: one double-click. That single click kicks off an export from macOS Photos, then a three-tier, on-device-first extraction pass — on-device Apple Vision OCR first, an LLM fallback for the images the on-device pass can't read cleanly, and a needs-review flag for the small remainder neither pass is confident about. Whatever comes out the other end gets pushed into the Airtable CRM with the guest's ID image attached, and the system looks across the dates to infer which stay each ID belongs to.

Run on the real data from the hotel: 407 unique guests now live in the CRM, every one of them — 100% — with an ID image on file. 84% were read automatically, with no human touch at all; 68% of all documents were handled entirely on-device, without ever reaching the LLM. From that same pass, the system inferred 263 historical bookings and surfaced 11 returning guests — repeat visitors nobody had gone looking for, found automatically once the records were linked. The whole pass is idempotent and incremental: safe to run again on the same export without creating duplicates, and it only does new work on records it hasn't seen before.

AI content pipeline

The second live piece handles marketing content. Adding an idea as a row in Airtable is the only manual step: from there, an LLM drafts a bilingual Vietnamese/English caption using a brand-voice guide, generates an on-brand image to go with it, and puts the draft back in Airtable for a quick approve. Once approved, the post publishes to the hotel's Facebook Page on schedule, with no further manual steps. This isn't a demo: one real post has gone out through this pipeline end-to-end, idea to publish, with no manual writing at the final step.

The brand-voice guide is what keeps the drafts usable instead of generic — the LLM is told how this hotel actually talks, in both languages, rather than left to guess at a tone. The approval step in Airtable stays in place deliberately: nothing goes out to a public page without a human looking at it first, even though the drafting itself is automatic.

Monitoring

The third piece is the least visible and, for daily operations, one of the most important: if any workflow fails, an error-alert email goes out immediately, and a separate heartbeat ping runs on a schedule so a silent outage — a workflow that stops running entirely rather than failing loudly — gets noticed instead of going unnoticed for days.

The engineering decision that mattered

The first version of the guest-import pipeline put the actual database writes inside n8n itself, using Code nodes and a maze of branching logic to handle base64 image decoding, attachment uploads, and linking each ID to the right existing guest record. It worked, until an edge case didn't fit the branch that was written for it — and then it failed in ways that were hard to diagnose inside a visual workflow tool built for orchestration, not data engineering.

The fix was a deliberate pivot: pull every actual write out of n8n and into a small Python "data access" layer that owns exactly that job — decoding attachments, uploading images, matching and linking guest records — while n8n goes back to what it's good at: triggering the job, running it on a schedule, and reporting whether it succeeded. The result is a pusher that's idempotent and incremental: safe to run on every scan, whether that scan finds ten new IDs or none, because the Python layer is the only thing that decides what gets written, and it always checks before it writes.

It's a small architectural rule with an outsized payoff for a one-person operation: n8n stays the orchestrator it's good at being, Python stays the one place data integrity lives, and nobody has to remember which of a dozen branch nodes handled a particular edge case six months from now.

Privacy by design

The extraction pipeline is deliberately on-device-first. On-device Apple Vision OCR — running locally on the machine, not on a server — handles about 68% of every ID document that comes through, at zero token cost and with no ID data ever leaving the machine. Only the harder remainder, the documents the on-device pass can't read confidently, goes to the LLM for a second pass, and even then it's a narrow OCR-cleanup call, not a hand-off of the whole document.

This case study follows the same discipline: every number here is an aggregate, and every screenshot in it is masked or cropped before publishing. No real guest name, document number, phone number, date of birth, or face appears anywhere in this write-up.

Privacy-by-design also isn't framed here as a compliance checkbox; it's a practical result of the same architecture choice that makes the pipeline cheap to run. Handling most documents on-device means most of the workload never touches a network call or a per-token bill at all — the LLM is reserved for the harder remainder, which keeps both the privacy exposure and the running cost small at the same time.

The roadmap

Everything above is live, running on the same real hotel today. The next slices are designed on the same Airtable-and-n8n backbone but are not yet built — they're on the roadmap, not current capability: direct booking management (creating and tracking a booking without a third-party channel), multi-channel guest communication (a guest message on any channel landing in the same place the guest record already lives), and revenue analytics (turning the booking history the system already infers into a view of occupancy and revenue over time). None of these three exist yet; they're the reason the platform framing matters — the guest-registration and content pieces above are the first slice of something bigger, not the whole plan.

The reason these three are next, rather than first, is sequencing: a single source of truth for guest data had to exist before booking management, guest comms, or analytics could be built on top of it responsibly. Each of them is described here as a direction, not a promise with a date attached.

See it running

Here is the system actually running. Below: the guest-import workflow in n8n, a log of recent runs completing unattended on schedule, and the Airtable content calendar that drives the Facebook pipeline. Every screenshot has had any guest-identifying data cropped or masked out.

What I'd tell other businesses

1. Automate the boring, mandatory paperwork first. Guest registration wasn't optional and wasn't exciting, but it was the highest-friction, highest-risk task at the desk every single day — putting it on autopilot paid off faster than any feature a guest would ever notice.
2. Keep sensitive data on-device wherever you can. Running OCR on-device instead of sending every ID straight to a cloud model cut cost and risk at the same time — 68% of documents never left the machine at all.
3. Let one layer own the writes. Moving every database write out of the workflow tool and into a single Python layer is what made the pipeline safe to re-run on every scan, instead of something to run once and worry about.