inline 候位 vs Oddle Queue：別只是管理排隊，把排隊變回頭客

週五晚上，店裡滿座，門口排了一條線。店員忙著叫號、安撫等位的客人、把空出來的桌子接上下一組。那條線是好事——代表大家想吃你家。但當最後一組客人離開、線散掉之後，你手上還剩下什麼？

通常什麼都不剩。排過隊的人走了，沒等到位就離開的人更是連影子都沒有。你今晚最集中、最熱的一批需求，叫完號就蒸發了。

這就是 inline 候位 跟 Oddle Queue 真正的分水嶺。兩套系統都能把排隊管好——數位候位、叫號、通知，這些誰都會做。但「把線排好」從來不是最難的問題。難的是：排完之後，這些客人有沒有變成你能再找回來的人？

這篇會誠實地比較兩套系統：各自擅長什麼、收費邏輯怎麼不同、什麼餐廳適合哪一個。先說清楚，這不是要攻擊 inline——inline 是台灣餐廳最熟悉的候位工具，它的線上候位是這個市場的起點。文中所有 inline 相關的費用與機制，都是依公開資料整理，並非官方報價，實際情況仍以 inline 業務提供的方案為準。

但比完功能之後，真正的問題只有一個：你要的是一條管理良好的線，還是一份排完隊還能用的客戶名單？

先講清楚：候位系統到底在解決什麼問題？

候位系統的基本工作，其實大家都同意。

客人到店、現場客滿，店員不再用紙本登記、不再扯著嗓子喊「王先生兩位」。系統給客人一個排隊號碼，客人用手機就能看到自己排第幾位、大概還要等多久，輪到的時候收到通知再進來。線上候位讓客人甚至不必待在門口，先去逛一下，時間快到再回來。

對餐廳來說，這解決了現場的混亂：店員不必一直應付「還要等多久」的詢問，翻桌節奏更順，客人的等待體驗也比乾站著好很多。

問題是，大多數候位系統到這裡就停了。它們把排隊當成一個「把人排好、依序叫進來」的現場營運問題。號叫完、桌接上、客人入座，這個流程就算完成了。

但你有沒有想過，每天晚上排在你門口的那條線，其實是你整週收集到最密集的一批需求訊號？這些人不是隨便路過——他們願意等。願意等的人，是你最該留住、最該再找回來的客人。把這批人「排好、叫進來」就丟掉，是一件很可惜的事。

inline 候位：台灣餐廳熟悉的那條線

公平地說，inline 的候位做得很扎實。

inline 是台灣餐廳訂位與候位的市場老大，而線上候位正是它起家的產品。客人能線上加入候位、用 LINE 收到叫號通知、看到自己的順位；店員端的叫號、現場管理流程也都成熟好用。重點是，它跟 inline 消費者端的市集（inline.app）連動——客人可能在 inline.app 上發現你的店、直接加入候位走進來。對品牌還在建立期、需要曝光帶客的餐廳，這個市集是真實的價值。

台灣的餐廳老闆熟悉它，店員也熟悉它。這是它最大的優勢之一：導入幾乎沒有學習門檻。

但有兩件事，值得在續約之前想清楚。

第一是收費。inline 的候位通常以「每家門市」為單位訂閱，再加上 LINE、簡訊等通知的用量費。inline 官方沒有公開定價頁，所以實際數字要跟業務談。

對單店、排隊量穩定的餐廳，這筆錢可控；但門市一多，每家店一份訂閱、一份通知量，固定支出就會明顯往上疊。

第二是客資的歸屬。inline 的候位本質上是一套現場營運工具——它的設計是「把線管好」。客人留下的聯絡方式、排隊紀錄、用餐偏好，主要存在 inline 的系統裡，你要拿來自己做行銷、自己經營會員的時候，能動用的空間是有限的。你付錢買到的是一條被管理得很好的線，但線散掉之後，那批客人多半不會留在你自己的口袋。

這不是 inline 做得不好，而是它的產品定位本來就是現場排隊管理。要超出這個範圍，得用不同的思路來設計。

Oddle Queue：把排隊名單變成客戶名單

Oddle Queue 是一套數位候位名單，目前在台灣與新加坡 Beta 階段先行推出。

基本流程跟你預期的一樣好用。客人可以掃門口的 QR Code、或開啟候位連結，透過 Oddle Pass 自助加入排隊；也可以由店員從後台的「今天」頁面手動代加。加入後，系統依人數分配一個排隊號碼，客人在手機上就能看到自己的順位和預估等待時間。在台灣，加入與叫號的通知都透過 LINE 發送；如果需要，還可以選配自動語音電話，在桌位準備好時打給客人——這項服務依用量另外計費，需要開通通話訂閱。

候位的管理就在 Host App 裡，跟你的訂位放在同一個地方。換句話說，跑訂位的那套後台，也是你管排隊的地方，不必兩套系統切來切去。

到這裡，它聽起來跟一套好用的候位系統沒兩樣。真正不一樣的是下面這句：

每一個加入排隊的人——不管最後有沒有入座，連沒等到位就走的未到者——都會成為你客戶資料庫裡的一筆檔案，可以用來做行銷、做自動再行銷。 那群當晚最想吃你家、卻連桌都沒坐到的人，第一次不再是白白流失。

這就是定位的差別。inline 把排隊號碼當成叫號工具，叫完就結束。Oddle Queue 把排隊號碼當成一張入會表。客人為了吃你家而願意排隊的那個動作，本身就是最強的意願訊號，Oddle Queue 把它留下來，接進 Customer Intelligence 和 Marketing，變成你之後可以再觸發的客人。

要提醒的是，Oddle Queue 還在 Beta，功能會持續演進。但它要解決的問題，從一開始就跟一般候位系統不在同一個層次。

兩套系統，差在哪？逐項比較

把功能攤開來看，差異就清楚了。

表格列了八項，但真正會影響你決策的，其實是其中兩列：客資歸屬和收費邏輯。

其他項目兩邊都做得到——叫號、通知、跟訂位整合，這些是候位系統的基本盤。但「排隊資料最後存在誰手上」決定了你能不能把這批客人再行銷；「按門市計費還是按品牌計費」決定了你多開一家店時，這筆成本是線性疊加還是被一個方案涵蓋。這兩件事，才是真正把兩套系統分開的地方。

接下來兩段，就把這兩件事分別講透。

按門市計費，還是按品牌計費？算給你看

先講成本結構，因為這是多數老闆最直接有感的地方。

inline 的候位通常以「每家門市」為單位訂閱，再加上通知用量費。這代表什麼？你開三家店，就是三份候位訂閱、三份通知量。每多開一家分店，這筆固定支出就再加一份。對連鎖、多門市的品牌，這種 per-outlet 的結構會隨著展店線性往上疊。

Oddle Queue 的邏輯不一樣。它隨 Oddle 的 All Access 方案、依「品牌」計費——旗下的門市一起管理，不是每開一家店就多扛一份候位訂閱。一個品牌方案涵蓋你的三家店，而不是三份分開的帳單。

而且還有一個關鍵差別：Oddle Queue 的成本「忙才有意義地產生」。候位通知是在真的有人排隊、需要叫號的時候才發生的；離峰、沒人排隊的時段，幾乎不產生對應成本。你不是為了「有一套候位系統待命」付固定的月費，而是在真的把它用起來、真的在接住現場需求的時候，它才產生意義上的成本。

這裡講清楚：Oddle Queue 的候位收費是公開的——它包含在 All Access 方案裡，每月內含 300 筆候位，超出每筆 NT$5，並依品牌計費。所以這段比的是「結構」，不只是單一數字。而且對單一家忙碌的店來說，per-outlet 跟 per-brand 的差距其實沒那麼大——這個模型差異咬得最深的，是多門市的品牌。店越多，「三家店各一份訂閱」跟「一個品牌方案涵蓋三家店」之間的距離就越遠。

如果你想看 inline 收費邏輯更完整的拆解——年費、超額、通知、加值服務怎麼疊起來——我們在 inline 費用完整分析裡用 NT$ 做了一家具體餐廳的試算，可以對照著看。

離峰沒人的那晚，你的排隊資料在哪？

成本只是其中一半。另一半，是你尖峰時收集到的那批需求，後來去了哪裡。

想一下週五晚上的那條線。排隊的人、留了電話的人、甚至沒等到位就走的未到者——這是你一整週最集中的「想吃你家」訊號。這些人不是冷掉的名單，他們是當天晚上人就站在你門口、願意等的熱客。

這裡要先講一個業界的常態：絕大多數候位系統，在線散掉的那一刻就把這批資料放掉了。這不是 inline 一家的問題，而是整類「現場排隊管理」工具的設計預設——它們的任務是把線排好，不是把人留下來。號叫完、桌接上、客人走了，系統的任務就結束，資料留在系統那一端，你拿不太回來。

更可惜的是沒等到位就走的那群人。他們是當晚意願最強、卻連桌都沒坐到的客人，偏偏在多數系統裡，他們連一筆紀錄都不會留下。

用 Oddle Queue，這批人每一個都變成你資料庫裡的一筆檔案——包含那些沒等到位就走的未到者。於是離峰的週二晚上——店裡冷清、你正煩惱怎麼把人帶進來的時候——你可以做一件以前做不到的事：對「上週五排隊、但沒等到位就走」的那群人，發一則訊息，把他們找回來。

這個動作在 Oddle 是同一套系統裡完成的。Queue 把人收進客戶資料庫，Customer Intelligence 幫你把這群人圈出來（例如「上週排隊未入座」），Marketing 把訊息發出去。排隊 → 客資 → 再行銷，一條線走完，不必中間再接別的工具。

這就是那句話的意思：排隊從來不是成就，是你看不見的需求，和你沒留住的客人。 一條長長的線看起來很風光，但如果它每晚都蒸發，那條線只是熱鬧，不是資產。

從營運成本的角度看，這件事更明顯。現場走進來的散客，獲客成本是零——他們自己上門。但如果你沒有一個機制把他們留下來，他們的資料也是零。一條排隊的線，是少數能把「零成本的散客」轉成「有資料、能再行銷的客人」的時刻。Oddle Queue 要做的，就是不要浪費這個時刻。

什麼餐廳適合繼續用 inline？什麼餐廳該評估 Oddle Queue？

不是每家店都該換系統。誠實的判斷是這樣。

繼續用 inline 較合理的情況

• 你的客源有相當比例來自 inline.app 消費者端市集，品牌仍在建立期、需要它帶曝光。
• 你是單店，現場排隊管理是唯一需求，目前沒有打算自己經營客資。
• 你已經深度整合 inline 的候位＋訂位＋點餐，轉換成本高。
• 排隊量穩定、門市數少，per-outlet 的訂閱負擔在可控範圍內。

如果你的情況落在這一組，繼續用 inline 沒什麼問題——它成熟、市場熟悉，現場流程順。

該評估 Oddle Queue 的情況

• 你是多門市品牌，per-outlet 的候位訂閱已經變成一筆隨展店線性上升的固定壓力。
• 你想擁有完整客資、自己經營行銷與再行銷，不想客人資料卡在別人系統裡。
• 你的離峰時段需要被救——而尖峰累積的排隊需求，正是把人找回來的素材。
• 你已經（或打算）用 Oddle 跑訂位、CRM、行銷，想讓候位也接進同一套系統，少一個切換。

這裡也要誠實一句：Oddle Queue 還在 Beta。如果你現在最需要的是一套已經驗證很多年、流程零意外的成熟候位系統，這一點要納入考量。Beta 代表它要解決的問題很對，但成熟度還在累積。

常見問題

Q：inline 候位和 Oddle Queue 最大的差別是什麼？

一句話：inline 管理現場排隊，Oddle Queue 把每位排隊客變成可再行銷的客檔。前者把線排好、叫進來就結束；後者把排隊的人留進你的客戶資料庫，離峰時還能再找回來。

Q：Oddle Queue 在台灣用 LINE 還是 WhatsApp 通知？

台灣用 LINE。加入排隊和桌位準備好的叫號通知都透過 LINE 發送。另外可以選配自動語音電話，在桌位準備好時打給客人，這項依用量另外計費、需要開通通話訂閱。

Q：Oddle Queue 怎麼收費？比 inline 便宜嗎？

Oddle Queue 隨 All Access 方案、依品牌計費，不是按門市計費，而且忙才有意義地產生成本。候位每月內含 300 筆，超出每筆 NT$5（公開定價），依你品牌的排隊量計算。框架上，對多門市品牌通常更省；對單一家店，跟 inline 的 per-outlet 訂閱差距會比較小。

Q：沒等到位就走的人，Oddle Queue 也會留下資料嗎？

會。每一筆排隊紀錄，包含未到者，都會進入你的客戶資料庫，可以用來做行銷和自動再行銷。這正是它跟一般候位系統最大的不同。

Q：Oddle Queue 可以和訂位一起管理嗎？

可以。候位與訂位都在同一個 Host App 裡管理，不需要兩套後台切換。

Q：Oddle Queue 已經正式上線了嗎？

目前是 Beta 階段，台灣與新加坡先行推出。功能持續演進中。

Q：我已經在用 inline，要怎麼開始評估 Oddle Queue？

先把你目前每家門市的候位訂閱費、加上 LINE／簡訊 通知用量加總起來，得到一個真實的年度數字。再用按品牌計費的模型對照試算。如果你是多門市，這個對照通常最有感。

結論：排隊不是終點，是回訪的起點

候位系統不該只是把線排好。

把人排好、依序叫進來，是基本盤——inline 和 Oddle Queue 都做得到。真正的問題是排完之後，你還剩下什麼。inline 給你一條管理良好的線；Oddle Queue 給你一份排完隊還能用的客戶名單。

換個方式說：Oddle Reserve 接住會提前訂位的需求，Oddle Queue 接住現場才出現的需求。兩者都把客人留進你自己的資料庫，讓尖峰的熱度，變成離峰也能動用的資產。

如果你正在續約 inline 的候位，或正在評估第一套候位系統，先問自己一個問題：我門口那條線，每晚散掉之後，到底留下了什麼？想清楚這件事，答案會自己浮出來。

想知道 Oddle Queue 怎麼套進你的店、怎麼把排隊變成回頭客？它目前在台灣 Beta 推出中，預約一場無壓力的諮詢，我們會用你自己的排隊與營運情況一起看。

相關閱讀

• inline 費用完整分析：收費方式、月費、抽成全解析 — inline 收費邏輯、NT$ 試算，以及「曝光 vs 客資」的取捨。
• 從 inline 換到 Oddle Reserve 的真實案例 — 多家餐廳分享換系統的試算與遷移經驗。
• 台灣餐廳訂位系統比較：6 大差異一次看 — 跨平台條件評估、挑系統的決策框架。