多品牌餐飲集團設計會員等級時，最容易被看見的是折扣、生日禮或升等門檻；真正容易卡住的，卻是顧客、客服、App 與門市看到的規則不同。會員剛完成一筆消費，為什麼沒有升等？同一張券為什麼只能在特定品牌使用？退款後點數與等級進度怎麼處理？這些問題不是靠多寫一張活動頁就能回答，而是需要一套能被查詢、被解釋、被覆核的權益資料流程。

以 iEAT 饗愛吃的公開 FAQ 為例，一個多品牌會員制度同時處理等級門檻、效期、消費金額與次數、跨品牌生日權益、券別限制，以及交易取消後的點數扣回。這是具名品牌案例，不代表所有餐飲品牌都該照搬；但它很適合用來看見一件事：會員等級不是一張靜態表，而是一連串有條件、有時點、有狀態的事件。

一、會員等級的難題，不在門檻而在規則治理

會員制度一旦跨過單一品牌，規則就不只是在後台設定「滿額升級」。它還會涉及哪個通路的交易可計入、是否需要累積次數、升等何時生效、續等或降等後是否重算、不同券別能在哪一家門市使用，以及第一線怎麼確認會員是否符合資格。

行政院消保處在 115 年 5 月公布的統計中指出，114 年全國受理消費申訴及調解案件為 83,442 件，年增 7.96%；同一新聞稿所列的 114 年第 1 次申訴案件中，食品與運輸均在前五大類別。這不是餐飲會員等級的直接統計，但可作為服務與交易資訊需要清楚揭露的背景。對餐飲集團而言，規則透明不是讓疑問不再發生，而是讓同一筆權益在不同接觸點有可核對的答案。

二、金額、次數與既有會級，為何要分欄管理

有些制度只看消費金額，有些同時看金額、次數與目前會級。若後台只保存一個「累積值」，升等時很難說明到底是哪一個條件尚未滿足。iEAT 的公開規則就是一個可參考的具名案例：

表格的重點不是複製門檻，而是看到條件的組成。對多品牌餐飲集團來說，會級、累積金額、累積次數、起算日、到期日與規則版本應被視為不同欄位；不能把它們濃縮成一個「目前等級」標籤。否則當顧客詢問升等進度或後續退款影響時，總部很難回看計算過程。

三、升等、續等、降等：每一次重算都是會員事件

會員升降級最需要被講清楚的，不是「會不會變」，而是「何時變、變完哪些欄位會重算」。iEAT 的案例中，若會員在效期到期日當日以前滿足下一等級條件，隔天自動升等，新的會員效期重新起算一年。升等時，超出門檻的累積消費金額在扣除升等條件金額後可延續到下一個會級期間，但消費次數歸零。

同一套制度在續等與降等則採取不同結算：原等級達標時隔天續等；未達原等級條件時，依年度累積金額與消費次數判斷對應等級後隔天降等。兩種情況下，累積金額與次數都歸零並重新累積。這些做法只屬 iEAT 規則，但提醒營運團隊：升等、續等與降等不能只用同一個「重置」按鈕處理。

從已驗證案例可整理出保守的管理建議：每一次會級異動至少要留下規則版本、判斷時點、判斷前後等級、金額與次數前後值、效期變化及觸發交易。如此一來，會員中心顯示的結果、客服查詢的紀錄與門市看到的資格，才有機會對應到同一筆事件。

四、跨品牌權益不是一張共用券

跨品牌設計常被簡化成「全集團可用」，但實際上不同權益可以有不同通路、品牌、本人與券別條件。以 iEAT 的生日當月點數兩倍為例，該權益適用於全集團任一品牌消費，但限壽星本人於結帳時出示 App 會員條碼登錄，且相關權利不得合併或轉移。這並不代表所有生日禮都必須如此，而是說明跨品牌權益需要把適用對象與核銷方式一併寫進規則。

同樣地，iEAT 的指定品牌生日 96 折優惠券並非任一品牌通用；它依券別對應指定品牌，須以原價內用消費，且不可與其他優惠合併。部分生日權益使用時還要求出示身分證件，未出示時門市可婉拒使用。品牌集點卡兌換的限定優惠券則必須回到原集點品牌，並在匯入日起 90 日內使用。這些都是個案細節，但也讓「可用品牌」「可否併用」「是否需核驗」「是否可轉贈」「券別效期」成為不可少的資料欄位。

對多品牌集團來說，較務實的做法是把每張券當成一個具有屬性的權益物件，而非只在會員帳號上加一個優惠名稱。當券別屬性清楚，POS 才能在核銷前提示適用品牌與限制；客服也能說明該券是因生日、升等、集點或其他活動而產生。

五、通路與退款異動，必須回到同一套規則

會員等級與跨品牌權益不只在門市結帳時運作。iEAT 對點數累積的公開說明，將可累點通路界定為集團旗下全品牌官方通路，包括門市、EATOGO 外帶／外送與 EAT@HOME 線上商城，不含其他合作餐飲平台。這是 iEAT 的通路設計，不是外送或合作平台的一般規則；但它顯示通路來源本身應成為計算條件，而不是交易進來後才由人工判斷。

交易異動同樣不能只影響付款紀錄。iEAT 對交易取消、退貨退款的處理，會讓當次消費轉換的點數無法累積並須扣回；點數兌換優惠券後則立即扣點，且無法取消、返還或變更兌換優惠券。這些都是具名品牌規則，但對資料流程的啟發很直接：退款、取消、兌券與核銷應各自留下狀態，並由相同的會員規則決定是否回算點數、等級進度或券別可用性。

六、建立可追溯的會員等級與券別資料模型

資料治理不是把所有規則塞入門市手冊，而是讓總部、CRM、POS、App 與客服都能讀到同一套狀態。以下欄位是依已驗證案例整理的編輯建議，可作為盤點既有會員系統時的起點：

不一定要一次重建所有系統。先從最常被問的三種情境著手，例如「升等何時生效」「跨品牌券能不能用」「退款後進度怎麼算」，再回推這些答案需要哪些欄位與事件紀錄。這樣的順序比較能讓系統整合貼近現場，而不是把規則留在只有總部看得懂的文件裡。

七、讓 App、客服與門市看見同一個答案

規則一致不等於每一位同仁背下所有條款，而是讓不同角色取得適合的資訊。會員端需要看得到目前等級、累積金額、累積次數、點數與消費歷程；iEAT 的 App 就提供累積金額、累積次數、消費歷程、總點數、即將到期點數與近期點數細項的查詢入口。這是品牌的功能個案，但可作為「讓會員能自己查」的設計方向。

門市端則需要更短、更明確的判斷提示：券是否適用該品牌、是否可併用、是否要請會員出示條碼或身分證件、是否已過期、是否仍可核銷。客服與總部則需要看到完整事件歷程，包含規則版本與交易異動。三個介面不必長得一樣，但應回到同一份規則資料。

消保處對外送平台會員權益與費用揭露所提出的提醒，也可作為背景：規則、價格與申訴動線要讓顧客找得到。餐飲自有會員制度不等同於外送平台情境，但在多通路經營時，清楚區分哪些通路可累點、哪些券可用、遇到疑義可從哪裡查詢，能減少現場只能靠口頭解釋的情況。

八、FAQ、結論與下一步

常見問題

Q：會員等級只看消費金額，系統是不是比較簡單？
規則是否只看金額，取決於品牌設計。iEAT 的公開案例同時使用金額、次數與既有會級條件，說明多個條件並存時必須分欄保存。系統的重點不是條件越多越好，而是每個條件都能被查詢與說明。

Q：跨品牌券是否應該全部通用？
不一定。iEAT 的生日權益、指定品牌券與品牌集點卡兌換券各自有不同適用範圍。對其他餐飲集團來說，應先定義券別屬性與可用範圍，而不是把不同目的的權益放進同一個通用規則。

Q：資料整合應該從哪裡開始？
先挑一個最常出現的例外情境，例如退款後的點數扣回或門市核銷跨品牌券，再把相關會員、交易、券別、規則版本與處理紀錄串起來。這能讓團隊用真實流程檢查資料是否一致。

結論

會員等級升降與跨品牌權益的價值，不在於制度看起來多複雜，而在於每個人都能回答同一個問題：這位會員現在擁有什麼權益、它來自哪一筆交易、適用到哪裡，以及下一次異動會如何處理。把門檻、效期、通路、券別與交易異動做成可追溯事件，才能讓會員制度從活動設定走向可執行的營運規則。

行動呼籲

Metabiz 可協助餐飲集團盤點 POS、會員、CRM、票券與客服資料之間的規則落差，先把會員等級、跨品牌券與交易異動整理成可共用的資料欄位與流程。從一個實際門市情境開始校對，能幫助團隊找出最需要優先整合的環節。