Restaurant Operations: Private AI for Reservations, Inventory, and Staff Coordination

The group operates three restaurants in Bangkok: a flagship Thai fine dining room, a casual izakaya, and a brunch cafe. Each location had its own reservation book, its own inventory spreadsheets, its own Line group for shift swaps, and its own way of tracking supplier orders. The general manager spent most mornings pulling numbers from five different apps to understand what happened yesterday.

Reservations came in through Google, Line OA, phone calls, and walk-ins. Double bookings happened weekly because the systems did not talk to each other. When a large party reserved at the flagship through Google and a walk-in group took the same table because the host checked the paper book, the problem was always discovered at the worst possible moment.

Inventory tracking was manual. The head chef at each location kept a mental model of what was in the walk-in, updated a spreadsheet when they remembered, and called suppliers when something ran low. Ordering happened by Line message to individual suppliers, with no central record.

Staff scheduling lived in a Google Sheet. Shift swap requests arrived by Line message. No one had a clear view of labor costs by location or overtime exposure. Review monitoring meant the general manager opening fifteen browser tabs across five platforms and three locations.

The system runs on a server in the flagship restaurant's back office. It connects to existing tools rather than replacing them: Google Business for reservations from search, Line OA for direct messaging, supplier Line contacts for ordering, the POS system's daily sales export, and the scheduling sheet.

Reservation management was the first layer. The system pulls availability from a shared calendar, accepts bookings through Line OA and a web form, and holds a unified view of all three locations. When a reservation comes in through any channel, it checks capacity, confirms with the guest through the same channel, and updates the central calendar.

Inventory tracking runs on daily counts plus POS data. Each kitchen enters a count at close. The system compares actual stock against expected stock based on what was sold and flags discrepancies. When an ingredient crosses a reorder threshold, the system drafts a supplier order with quantities calculated from forecasted demand for the next three days. The chef reviews, approves, and the order goes to the supplier through Line.

Staff scheduling uses constraint-based logic. The system knows each employee's role, location certification, contract hours, and time-off requests. It generates a weekly draft that covers projected demand, respects labor law rest requirements, and minimizes overtime. Managers adjust and publish.

Review monitoring polls all five platforms hourly. New reviews are summarized and delivered to a management Line group, categorized by location, sentiment, and topic. Reviews mentioning specific complaints are flagged for response. OpenClaw orchestrates the full system: each operational domain is a plugin, cron jobs handle recurring work, and the management team interacts through Line.

The general manager's morning starts with a Line message: last night's covers by location, revenue against forecast, inventory flags, today's reservation count and large party alerts, and a summary of overnight reviews.

The flagship's head chef checks suggested supplier orders before the lunch rush. The system has already calculated that tonight's tasting menu reservations will require more sea bass than current stock supports, factoring in portions sold at lunch and a six-top booked for dinner. The chef adjusts the quantity, approves, and the message goes to the supplier.

An operations manager asks through Line for labor cost per cover at the izakaya this month. The system pulls POS revenue, scheduled hours, and actual clock-in data and returns a comparison against the previous month.

A negative review appears on Google for the brunch cafe mentioning a 40-minute wait. The system flags it in the management group within the hour. When a server at the izakaya calls in sick on a Friday evening, the shift swap goes through the system, which checks qualifications, availability, and hour limits before suggesting replacements.

Reservation conflicts dropped because every channel writes to the same calendar. The flagship went from two or three double-bookings per week to effectively zero. Guest confirmations go out automatically through the channel the guest used to book.

Perishable waste decreased because ordering is driven by forecasted demand rather than the chef's estimate on a busy morning. The system's three-day forecast, based on reservations and historical sales patterns, turned ordering from reactive into predictive. The group started measuring waste for the first time because the data existed to do so.

Labor scheduling became defensible. The weekly schedule is backed by projected covers, historical staffing ratios, and overtime calculations. Disputes about shift fairness decreased because the logic is transparent and consistent across locations.

Review response time improved from days to hours. The weekly summary gave the ownership group a view of guest sentiment they had never had: comprehensive across every platform and location. The system runs on the group's own server with no per-seat fees and no customer data flowing to a third party.

The core is a Node.js backend backed by SQLite. Reservations, inventory counts, supplier orders, staff schedules, and review data all live in one database. The backend exposes CLI subcommands that return structured JSON, and the agent calls these through OpenClaw's plugin system.

Data flows through five paths: Google Business API and Line OA webhook for reservations, nightly CSV export from the POS, a tablet-based web form for kitchen inventory counts, Line messaging for supplier orders, and hourly polling for reviews across all platforms.

The demand forecasting model is a weighted average of same-day-of-week sales over the past eight weeks, adjusted by current reservation count relative to historical ratios. It is simple, transparent, and accurate enough for ordering decisions that a chef can override. The system never places an order autonomously.

Review categorization uses the language model for sentiment and topic extraction. Reservation math, inventory arithmetic, and scheduling constraints are deterministic code. OpenClaw provides the orchestration layer: plugin registration for each domain, cron scheduling for automated reports and polling, and Line messaging so the management team interacts with one system through one channel.