線上排隊與叫號系統怎麼規劃：現場取號、線上取號與過號處理

週末中午門口站滿人，櫃台一邊結帳一邊被問「前面還有幾組？」，有些客人等不下去就走了——這是許多店家開始評估線上排隊與叫號系統的時刻。不論是餐廳、診所、門市維修站還是政府機關的服務櫃台，問題的本質都一樣：等候本身難以避免，但客人不知道要等多久、也不能離開，才是體驗變差的主因。

排隊叫號系統要解決的，就是讓等候變得可預期、可離開、不會漏號。

以下說明系統的基本運作、現場與線上取號怎麼並存、通知方式、過號規則、它和預約系統的差別，以及尖峰時段的準備。

排隊叫號系統的基本組成

一套完整的排隊叫號系統，通常包含下面幾個部分：

• 取號端：現場取號機、櫃台人員代取，或客人用手機線上取號。
• 叫號端：櫃台人員按下「下一號」的操作介面，可能是平板、電腦或實體按鍵。
• 顯示端：店內的叫號螢幕、語音廣播。
• 通知端：快輪到時用簡訊、LINE 或網頁推播提醒客人。
• 管理後台：設定服務項目、櫃台、營業時段，查看等候與服務紀錄。

小規模的店家不一定每個部分都需要。只有一個櫃台、客人都在店內等，可能只需要取號與叫號螢幕；客人常需要離開現場等候，線上取號與通知就變成核心。

現場號碼與線上取號怎麼並存

線上取號最大的設計難題，是它和現場取號共用同一個隊伍。處理不好，現場客人會覺得被插隊，線上客人會覺得到了還要等。

常見的並存方式有三種：

1. 單一隊伍、統一編號：不論從哪裡取號，都依取號先後排入同一個隊伍。最直覺、也最公平，但線上客人可能在遠處取號，到店時已經過號。
2. 分流隊伍、交錯叫號：現場與線上各自編號，叫號時依設定比例交錯。適合線上取號量大、想控制兩邊公平感的情境，但規則較難向客人解釋。
3. 線上取號限距離或時段：只在營業中、或只有現場等候超過一定長度時才開放線上取號，避免線上一次湧入佔滿隊伍。

不論選哪種，都要在取號畫面上清楚顯示「前面還有幾組」「預估等候時間」，並說明規則。客人能接受等，但不能接受看不懂。

另一個要事先決定的是線上取號是否需要到店報到。若需要，客人到店後要在現場掃碼或告知櫃台，系統才把他標記為「已到店、可叫號」；若不需要，叫到號時客人可能根本還沒到。多數情境建議設計報到機制，配合下面的過號規則一起運作。

通知方式：什麼時候提醒、用什麼管道

通知是線上排隊的價值所在，但也最容易做得太吵或太晚。

通知時點建議至少有兩個：

• 快輪到時：例如前面剩下少數幾組時提醒，讓客人有時間走回來。提前多少組，要依店家的平均服務時間與客人通常離開的距離來調整。
• 叫到號時：正式叫號的當下再提醒一次。

通知管道各有取捨：

• 網頁即時更新：客人保持頁面開著即可看到進度，不用加好友或留電話，但手機鎖屏後就看不到。
• LINE 推播：多數客人習慣使用，到達率穩定；前提是客人已加入官方帳號好友，做法可參考LINE 聊天機器人開發指南。
• 簡訊：不依賴任何 App，到達率高，適合長輩或不想加好友的客人，但每則都有發送成本。

實務上常見的組合是：網頁即時更新為主，LINE 或簡訊為輔，讓客人在取號時自己選擇提醒方式。留電話或加好友時，要說明資料用途，並只用在本次排隊通知。

過號規則：系統要先想好的例外

過號是排隊系統最常引發現場爭執的地方。規則要事先定好、寫在取號畫面上、系統照規則執行，而不是讓櫃台人員臨場判斷。

可以參考下面這份過號規則決策表，依店家性質選擇：

情況	可選做法	適合情境
叫號時未到	保留數號後自動失效	服務時間短、隊伍流動快
叫號時未到	移到目前隊伍末端	等候較長、希望保留客人
過號後回來	櫃台手動插回下一號	人力充足、客人量不大
線上取號未報到	叫號時自動跳過，報到後再排入	線上取號量大
同一人重複取號	限制同一手機號碼同時只能持有一號	有人惡意佔號的疑慮

系統面要支援的操作至少有：跳過、保留、重新叫號、取消、手動插隊並記錄原因。手動插隊一定要留紀錄，否則事後有客訴時無從查證。

另外要考慮「叫號後服務很快結束」與「叫號後客人有多件事要辦」的差異。若服務時間落差大，預估等候時間會很不準，可以讓櫃台在叫號時選擇服務類型，系統依類型估算，或乾脆分成不同隊伍。

排隊系統和預約系統的差別

這兩者常被混在一起，但解決的是不同問題：

• 排隊系統處理的是「已經想來、現在就要服務」的客人，核心是現場順序與即時進度。
• 預約系統處理的是「事先約好時段」的客人，核心是時段容量、改期與爽約。

判斷該做哪一種，可以看客人的行為：如果多數客人是臨時起意、路過就進來，排隊系統比較貼近；如果服務時間長、需要事先準備人力或材料，預約系統比較合適。預約系統的時段設計、爽約處理與提醒機制，在預約系統開發指南有完整說明。

很多店家最後兩者都需要：預約客人有保留時段，臨時客人現場排隊。這時的關鍵是報到時把預約客人插入叫號順序的規則，例如預約客人在預約時間前後一段時間內報到可優先叫號，超過則改排一般隊伍。這條規則要對兩邊客人都說得通。

尖峰負載：最需要系統的時候最不能當機

排隊系統的使用量高度集中。平日可能很安靜，節慶、活動或開賣當天卻會在短時間內湧入大量取號與查詢。偏偏這正是系統最不能出問題的時候。

尖峰前應該先確認：

• 取號是否有並發保護：多人同時取號時，不能出現兩個人拿到同一個號碼，或號碼跳號。
• 進度查詢不要每次都打資料庫：大量客人反覆刷新頁面時，進度資訊應有快取或改用推送更新。
• 通知要能排隊發送：大量提醒同時觸發時，發送失敗要能重試，而不是直接遺失。
• 現場有備援：網路或系統中斷時，櫃台要有紙本號碼或離線模式可以接手，並能在恢復後補登。
• 事先做壓力測試：用接近真實的情境模擬尖峰流量，找出瓶頸。做法可參考流量高峰與壓力測試指南。

如果店家有多個門市，還要確認一間門市的尖峰不會拖垮其他門市的服務。

規劃時要先整理的需求清單

和開發方討論前，可以先把下面這些問題寫下來，答案越具體，規格越不容易漏：

• 有哪些服務項目？是否需要分不同隊伍？
• 有幾個櫃台或服務人員？會不會臨時增減？
• 線上取號要開放嗎？開放的條件與時段是什麼？
• 線上取號是否需要到店報到？
• 過號規則是什麼？要寫在畫面上的文字是什麼？
• 通知用哪些管道？提前多少組提醒？
• 有沒有預約客人要併入叫號？
• 是否有多門市？後台要能跨門市查看嗎？
• 需要哪些報表？例如各時段等候長度、過號比例、各櫃台服務量。

需求文件的整理方式，可以參考軟體需求怎麼寫。

常見錯誤

• 只做取號，沒做通知：客人一樣被綁在現場，線上取號的價值就少了一大半。
• 過號規則讓櫃台自由判斷：每個人處理方式不同，客人看到別人被插回去，自己卻被要求重抽，爭執就來了。
• 預估等候時間寫死：服務時間會隨時段與人力改變，寫死的數字很快就不準，客人不再相信。
• 沒有離線備援：系統一斷，現場就亂成一團。
• 只在平日測試：平日跑得順不代表尖峰撐得住。

排隊叫號系統做得好，客人感受到的是「我知道還要多久、可以先去做別的事」；做不好，則是多了一道等待之外的麻煩。

如果你正在評估線上取號要怎麼和現場隊伍並存、過號規則怎麼寫進系統，或是要和 LINE、預約系統一起規劃，歡迎跟 NETVANA 說說你的現場狀況。我們的軟體服務一律採詢問報價制，會先釐清隊伍規則與尖峰情境，再提出系統範圍與分期建議；服務內容可參考軟體服務介紹。

延伸閱讀：需要事先保留時段的服務，先看預約系統開發指南；想用 LINE 做取號與提醒，看LINE 聊天機器人開發指南；尖峰時段怎麼事先測試，看流量高峰與壓力測試指南；櫃台要同時處理結帳，可以參考POS 零售系統開發指南；規格怎麼整理才不會漏，看軟體需求怎麼寫。