MANSEKI · TENMA ROBATAYAKI PROOF-OF-CONCEPT CASE

先在天滿爐端燒跑出真數字,
再拿著案例去談下一家店

這不是一份功能清單,是一份實證計畫:以天滿為唯一試跑店,先量基線、再分期上線,用未到場率、候補救回空席、滿席率、工時與熟客回流五個數字,證明新訂位系統「滿席 MANSEKI」到底有沒有效。案例成立,才往外談。

01 · 實證計畫

先量基線,再分期上線 — 每期分開看成效

最常見的錯誤是系統一上線就宣稱有效。這份計畫反過來做:第一期什麼都不改、只記錄,先把天滿現在的真實數字量出來;之後每一期只加一組功能,成效各自歸因,不混在一起算。

第一步

PHASE 0

基線期

現行方式照常營運 · 只記錄,不改變

  • 訂位照舊:電話與現行方式不動,不導入新功能
  • 逐日記錄五個核心量測的現況值(見下一節)
  • 記錄每輪出席、取消、未到場與空席情形
  • 記錄店員處理電話訂位的實際工時

這一期看什麼:天滿「現在」的基準線。沒有基線,後面任何改善都只是感覺。

PHASE 1

試跑一期

線上訂位 + 選位 + 提醒 + 候補活水

  • 客人於店家自有 LINE 完成訂位,直接在圓角 L 軌道上點選實際座位
  • 訂位確認與到店前提醒自動送出
  • 滿席時段開放候補登記;有人取消,系統依序遞補通知
  • 訂位資料(人數、座位、過敏忌口)直接帶入既有點餐系統

這一期看什麼:未到場率、候補救回空席、滿席率、電話工時的變化 — 先證明「位子不空著」。

PHASE 2

試跑二期

再加 · 訂金政策引擎

  • 在一期基礎上啟用訂金機制,金額與適用時段由店家決定
  • 階梯退費規則由店家設定,系統照規則自動執行
  • 候補遞補成功時,前一組訂金的處理依店家規則自動結算
  • 不可抗力(如颱風)情境的退費與改期依店家預設規則處理

這一期看什麼:與一期分開比較 — 訂金上線後,未到場率與空席是否再進一步下降。

分期原則:三期的數字分開呈現、分開比較。試跑期長度與每一期的起訖日期,由天滿與團隊共同排定後填入,不在本頁預設。
02 · 核心量測

五個數字,決定案例成不成立

每個量測都先寫清楚定義與計算方式,基線期量到的值才填得進來。本頁不預填任何數字 — 目前所有欄位都是待量測狀態,這正是基線期存在的理由。

METRIC 01

未到場率

訂了位、人沒出現、也沒有事先取消的比例。這是爐端燒板前最貴的損失:14 席的小店,空一席就是少一席的整晚營收。

計算方式:未到場組數 ÷ 已確認訂位總組數(同期、同輪次口徑一致)

基線期

待量測

試跑一期

待量測

試跑二期

待量測

METRIC 02

候補遞補救回空席

取消發生後,候補活水把位子重新賣出去的成效。這個數字直接換算成營業額,也是整套系統最核心的獨有能力。

計算方式:遞補成功席數 ÷ 取消釋出席數;同時記錄救回席數與比例

基線期

無此機制

試跑一期

待量測

試跑二期

待量測

METRIC 03

滿席率與座位利用率

每一輪實際坐滿的程度。滿席率看輪次,利用率看席位,兩個一起看才知道空的是「整輪沒人」還是「零星空席」。

計算方式:滿席率=滿席輪次 ÷ 總輪次;座位利用率=實際入座席次 ÷ 可售席次(14 席,加座時以實際席數計)

基線期

待量測

試跑一期

待量測

試跑二期

待量測

METRIC 04

電話訂位工時

店員花在接訂位電話、回撥確認、改期協調上的時間。線上訂位與自動提醒上線後,這段工時應該回到備料與接待客人身上。

計算方式:基線期以人工計時記錄每日電話訂位處理分鐘數,試跑期以同口徑續記比較

基線期

待量測

試跑一期

待量測

試跑二期

待量測

METRIC 05

熟客回流率與店家自有 LINE 好友成長

訂位長在天滿自己的 LINE 官方帳號上,累積的是店家自己的名單,不是平台的。熟客回流看「來過的人有沒有再來」,好友成長看名單本身長得多快 — 這兩個數字證明客人資產歸店家不是口號。

計算方式:回流率=期間內再次訂位入座的既有客人 ÷ 既有客人總數;好友成長=天滿自有 LINE 官方帳號好友數的期初與期末差值(帳號資料由店家提供)

基線期

待量測

試跑一期

待量測

試跑二期

待量測

03 · 訂位 × 點餐連動

一個座位的生命週期:從訂位那一刻,一路走到下次訂位

訂位與點餐不是兩套系統輪流用,而是同一筆資料走完整段路。店家從頭到尾只看一張圓角 L 軌道圖,不在兩個系統之間切換、不用轉錄任何一欄。

STAGE 1 · 訂位

訂位選位,資料一次填好

客人在圓角 L 軌道上點選實際座位,訂位時填的過敏、忌口與備註直接掛在這筆訂位上,跟著座位走。

STAGE 2 · 開單

忌口自動帶入,不用重填

這筆訂位轉成點餐開單時,過敏忌口與備註自動帶入,出餐端直接看得到,不靠店員重打或口頭傳話。

STAGE 3 · 到店

報到即轉開單 · 亮座 · 綁 QR

客人到店報到,訂位直接轉為開單,觸發入座亮座儀式;同時產生一次性 QR,綁定這一組訂位與這個座位,入座後掃碼點餐。

STAGE 4 · 用餐中

同一張軌道看板,兩種狀態一起看

同一個圓角 L 軌道看板同時顯示訂位狀態與點餐進度:炭烤、熱廚、吧台三站出菜進度在座位上看得到,任一站標記售完即時連動,客人端同步不會再點到。

STAGE 5 · 結帳

訂金自動折抵

結帳時,已收的訂金(試跑二期啟用後)自動折抵帳單,餘額以現金或刷卡結清,付款方式記錄在同一筆訂單裡。

STAGE 6 · 關單後

消費與喜好回寫客人紀錄

關單後,這次的消費內容、座位與忌口喜好回寫到客人紀錄;下次訂位時直接叫出,不用再問一次、再填一次。

候補客走同一條路:候補遞補成功、到店入座後,一樣直接轉開單、亮座、綁一次性 QR — 不因為是候補就走另一套流程,軌道圖上也看不出差別。
連動的前提是兩邊都開:本節的生命週期只在訂位與點餐兩個模組都啟用時成立。只需要其中一邊的店家,由總後台逐店關掉另一邊,剩下的那一邊獨立運作 — 設定方式見下一節。
現況說明:訂位示範與點餐示範目前是兩個分開的頁面;本節的連動是本案的定版規格 — 正式版兩邊共用同一份座位圖與同一份客人資料,上述生命週期在同一個系統裡完成。
04 · 總後台模組開關

店家只需要其中一邊,就只開其中一邊

訂位與點餐是兩個獨立模組,不綁在一起賣。總後台逐店設定開關:天滿兩種都開,走上一節的一條龍連動;只需要訂位的店就只開訂位,只需要點餐的店就只開點餐。下面就是總後台裡的設定方式 — 撥撥看開關,三種組合的差異即時看得見。

總後台 · 店家模組設定天滿爐端燒

訂位模組

線上訂位、軌道選位、候補活水、到店提醒、客人紀錄

點餐模組

座位圖點餐、三站出餐看板、售完連動、結帳

快速套用:

總後台先設一個全域預設,每家店再各自覆寫 — 改天滿的設定,不影響其他任何一家店。

目前組合

訂位 + 點餐 · 連動全開

客人端

店家後台

連動狀態

關掉的模組,徹底不出現

客人端入口與店家後台選單同步移除,不留空欄、也不留按不到的灰色按鈕 — 店員不會誤觸用不到的功能,客人也不會走進不存在的流程。

資料保留,重開即恢復

關閉只收起功能,不刪資料。先前的設定與歷史紀錄原樣保留,日後重新打開全部回來;已成立的訂位與訂單照當時狀態顯示,不受切換影響。

只開一邊,也要完整運作

只開訂位:訂位、候補、客人紀錄獨立運作,報到只標記入座,不觸發開單。只開點餐:座位圖點餐獨立運作,訂位照店家原有管道走,系統不插手。

營業中切換也安全

切換當下已成立的訂位與已開的單,照原組合走完;新進的訂位與新開的單,才套用新設定。不必等打烊才能改。

天滿的設定:兩種全開。天滿本來就有板前軌道點餐,本案加上訂位模組並啟用連動 — 五個實證數字量的,就是這個全開組合的成效。之後拿案例去談其他店家時,對方只需要其中一邊,就照上面的方式只開一邊,不必為了用不到的功能改變店裡行之有年的流程。
05 · 可操作示範

現在就點點看:選日期、選位、候補、遞補通知

以下為操作示範,座位占用狀態為示範資料,不是天滿的即時空位。輪次的實際時間待天滿提供,示範中以「輪次一/二/三」表示;其中輪次三設定為滿席,用來示範候補流程。

1 · 日期與輪次 2 · 在軌道上選位 3 · 資料與過敏忌口 4 · 完成訂位

用餐日期

輪次(實際時間待天滿提供)

人數

在圓角 L 軌道上點選座位

爐端 · 廚師工作區 (此視角為廚師面對客人方向)
可選座位 已訂(示範) 你選的座位 4 號 · 圓弧轉角席

短邊(1–3 號)與長邊(5–14 號)本身都是直線,只有 4 號轉角是圓弧 · 另可加座 2 席至 16 席,加座位置待店家確認

訂位人資料

過敏與忌口(會直接帶入點餐系統,守護出餐)

06 · 成功門檻與案例產出

門檻先講清楚,達標才算案例成立

每一項量測的成功門檻,由天滿與團隊在基線量測完成後共同訂定並填入下表 — 基線還沒量到之前,不先喊數字。案例成立後,產出一頁案例單與店家證言,才拿去談下一家店。

量測成功門檻判定時間狀態
未到場率門檻值待基線量測完成後,與天滿共同訂定後填入試跑一期、二期各判定一次待訂定
候補救回空席救回席數與比例門檻,待一期候補量累積後共同訂定試跑一期結束待訂定
滿席率/座位利用率門檻值待基線量測完成後共同訂定後填入每期結束待訂定
電話訂位工時下降幅度門檻待基線工時量測完成後共同訂定試跑一期結束待訂定
熟客回流/LINE 好友成長門檻值待基線量測完成後共同訂定後填入試跑二期結束待訂定

CASE SHEET · 一頁案例單(樣式預覽 · 數字待實證後填入)

天滿爐端燒 × 滿席 MANSEKI 實證結果

店家天滿爐端燒(Tenma Robatayaki)· 板前 14 席
營業時段/輪次待天滿提供
實證期間待排定(基線期/試跑一期/試跑二期)
未到場率基線 待量測 → 一期 待量測 → 二期 待量測
候補救回空席待量測(救回席數與比例)
滿席率/座位利用率待量測
電話訂位工時待量測
熟客回流/LINE 好友成長待量測
店家證言待取得(見右欄)

本案例單所有數字皆為實證期間實際量測值,不使用推估數字。

店家證言
「 待取得 」
試跑完成、數字達標後,邀請天滿提供實際使用證言,取得後原文刊登於此。

證言人姓名:待取得

職稱:待取得

未取得證言前,本欄不填寫任何引言,不以模擬或代筆內容替代。

拿去談下一家店之前,案例包要齊的東西

  • 一頁案例單(五個量測的前後對照,全部實測值)
  • 三期分開的成效紀錄(基線/一期/二期不混算)
  • 候補活水實際運作紀錄(遞補通知與成功保留的流程)
  • 店家證言(取得後附上,未取得不對外宣稱)
  • 訂位接點餐一條龍的操作流程紀錄
  • 成功門檻對照表(逐項標示達標與否)