ybuild / 場景

如何打造一套掌控出餐線的餐廳管理系統

餐廳的利潤率是各行各業裡最薄的之一：食材是最大的可控成本，而大多數經營者的存亡，就取決於它能不能落在健康的 28-35% 區間裡。然而真正決定利潤的那些數字——一道菜的成本是多少、冷藏庫裡還壓著多少貨、冷櫃是不是整晚都穩在 41°F——卻散落在一張張夾板紙、主廚的記憶、和員工群組裡。一套餐廳管理系統，把菜單、配方、庫存和法規記錄匯集到一處、讓你能在出餐線上直接運轉，託管在 ybuild 上、透過你自己的網域對外提供服務。

痛點

食材成本在無聲中失控：庫存靠紙筆盤點（或者根本不盤），於是等到月底損益表結帳，你才發現這個月一直跑在 38%——早已錯過在當期把它修正回來的時機。
備料單和溫度記錄都躺在夾板紙上，被咖啡漬浸花、被弄丟，直到衛生稽查員開口要看最近 90 天的記錄那一刻。
沽清單（86 清單）、當日特餐、以及過敏原細節都裝在主廚腦子裡和一個群組裡，於是服務生會信心滿滿地給客人一個錯誤答案。
每一張供應商發票都是格式各異的 PDF，沒有人把當初談好的整箱價和實際結算的金額核對一遍——這正是無人盯防的利潤漏洞。

你能打造什麼

菜單與配方成本核算

每一道菜品都關聯到一份配方，配方裡的每種食材都帶著真實的包裝規格和整箱價。雞肉的進價只需改一次，所有用到它的菜品的單盤成本和食材成本率就即時重算——於是你能在那些定價過低、分量過大的菜品悄悄吃掉你利潤之前就把它們揪出來。

庫存盤點與訂貨

一塊適配手機的每週盤點介面，按儲存區域組織——冷藏庫、乾貨區、冷凍庫。系統把你盤到的數量和常備量（par）逐一對比，交給你一份按供應商分組的缺口清單，直接變成你的採購單，而不是訂貨本上隨手一劃的猜數。

出餐線與法規記錄

備料單、報廢與招待記錄，以及冷藏庫、熱保溫、兩段式冷卻的時間溫度記錄——每一條記錄都帶著員工簽名縮寫、時間戳記，以及讀數超標時強制填寫的糾正措施，全部留存並可隨時調出供稽查。

數據模型

menu_items

id, name, category, price, station, allergens, is_86, recipe_id, is_active

ingredients

id, name, purchase_unit, pack_size, case_cost, recipe_unit, unit_conversion, par_level, on_hand_qty, supplier_id

recipe_lines

id, menu_item_id, ingredient_id, qty, unit

inventory_counts

id, count_date, storage_area, ingredient_id, counted_qty, counted_by

temp_logs

id, log_type, equipment, reading_f, recorded_at, staff_id, corrective_action

系統裡的一天

開店：經理調出備料單——recipe_lines 加上昨天的銷量，精確告訴出餐線要備多少 mise（備料），這樣沒人會去多備那道一天只賣六碗的湯。
收貨：收貨介面把每一箱貨和供應商約定的 case_cost 逐一核對，標記出少送或多送，並為這批貨裡的每種食材增加 on_hand_qty。
冷櫃檢查：每四小時一位廚師點開 temp_logs 介面，記錄冷藏庫讀數；如果高於 41°F，應用會鎖住儲存，直到填入一條糾正措施。
服務中：服務生把鮭魚標記為沽清——menu_items.is_86 翻轉，這道菜在每個檔口的螢幕和面向客人的特餐牌上同時變灰。
冷卻：燉菜離火之後，廚師啟動一個冷卻計時器；系統會在兩小時時提示做 135->70°F 的檢查，並在此後四小時提示做 70->41°F 的檢查。
打烊：報廢、招待、以及 POS 銷售總額被登記，明天的備料量對照更新後的在手庫存重新計算。
每週盤點：經理拿著手機逐個儲存區域清點；應用把 counted_qty 和 par_level 對比，按供應商生成一張採購單。
月底：食材成本率按每道菜和整體彙總，在會計打開帳本之前，就把哪些菜品定價過低或分量過大浮現出來。

AI 容易出錯的地方

單位是頭號陷阱。你按箱買雞肉，按盎司分份，按個盤點冷藏庫。粗糙的做法只存一個「數量」欄位，你的食材成本核算就會悄無聲息地算錯——每種食材都需要一個採購單位、一個配方單位，以及兩者之間的換算。
溫度記錄不只是一個數字。大多數州採納的 FDA 食品法典（FDA Food Code）要求記錄讀數、時間戳記、由誰量測、以及讀數超標時的糾正措施——並且要求大約最近 90 天的記錄可隨時調出。絕不要讓一條超標讀數在沒有後續處理的情況下就儲存下來。
冷卻是兩段式的，不是一個勾選框：2 小時內從 135°F 降到 70°F，再用 4 小時從 70°F 降到 41°F。單一的「涼了沒」開關過不了稽查——把兩個檢查點都建模，各有各的計時和各自的合格/不合格判定。
過敏原不能是一段自由文字備註。芝麻在 2022 版食品法典中成為第九大主要過敏原；把過敏原作為每道菜上標好標籤的欄位來儲存，好讓服務生能即時篩選並作答，而不是一句話——那句話總有人忘了更新。
絕不要硬刪除一道菜品或一種食材。刪掉上個月的「本週魚特餐」，它的銷售和食材成本歷史就會從你的報表裡消失。用 is_active 做軟刪除，讓 recipe_lines 和過往盤點保持完整，數字才誠實。

✓ 先做這些

帶配方成本核算和即時食材成本率的菜品——這個單一數字會改變你的定價和分量決策。
針對你成本最高、走貨最快的前 30 種食材的「每週盤點->常備量->供應商訂貨」閉環，而不是整個倉庫。
帶強制糾正措施的時間溫度和報廢記錄，留存 90 天以上，衛生稽查時能在幾秒內調出。

— 先別做

刷卡處理和桌邊支付——保留你現有的 POS，只匯入它的每日總額；v1 不要重建支付。
薪資、小費拆帳、以及勞動法排班計算——先從一張簡單的班表做起，把薪資交給你的服務商。
線上點餐和外送平台菜單同步——先把內部營運做扎實，再去對接 DoorDash 和 Uber Eats。

常見問題

這會取代我的 POS 嗎？

不會——繼續用你的 POS 在桌邊收款。這套系統與它並行：你把每日銷售總額錄進來（手動或簡單匯入），好讓食材成本和庫存能對照實際賣出的數據核對上。在 v1 裡重建刷卡處理，是一場不值得打的仗。

它怎麼計算食材成本率？

每道菜品關聯到 recipe_lines，每一行指向一種帶整箱價和包裝規格的食材。應用換算到配方單位，累加出單盤成本，再除以菜單售價。改一個整箱價，所有用到那種食材的菜品都會重算。大多數全服務餐廳的目標大約在 28-35%。

這些溫度記錄真的能讓衛生稽查員滿意嗎？

這些記錄會擷取讀數、設備、時間戳記、員工簽名縮寫，以及超標數值的必填糾正措施，並保持至少 90 天可調出——這正是採納 FDA 食品法典的轄區所看重的。務必和你當地衛生主管機關確認它想要的確切格式，因為各州會對這套示範法典做在地化調整。

我能用它經營不止一家分店嗎？

可以。庫存盤點、常備量和溫度記錄都是按分店隔離的，而菜單和配方是共享的，所以一次改價就會同時鋪到所有分店。先從一家分店做起，把閉環跑通，再複製它。

不培訓也能在出餐線上用嗎？

盤點和溫度介面就是為一隻濕手拿著的手機而造的——大按鈕、一次一個讀數、沒有要翻找的選單。因為整套系統託管在 ybuild 上、跑在你自己的網域下，員工只需在任意手機上打開一個收藏的網址；沒有任何東西要安裝或更新。

參考來源

FDA 食品法典（FDA Food Code） — 美國大多數州採納的聯邦示範法典，涵蓋時間溫度控制、冷卻、過敏原和食品安全記錄留存。
美國餐飲協會：FDA 更新其食品安全指南 — 行業協會對 2022 版食品法典更新的總結，包括把芝麻列為主要過敏原以及修訂後的溫度規定。
NetSuite：控制餐廳食材成本的 21 條策略 — 關於常備量、先進先出（FIFO）輪換和定期庫存盤點以把食材成本控制在區間內的實用指導。

為你的生意打造這套系統

描述它，一次上線到你自己的網域——託管、全端、免伺服器。免費開始。

免費開始打造 →