數位禮券不是一張優惠券：餐飲連鎖如何把發行、核銷與退款做成可稽核流程

餐飲品牌推出數位禮券、會員錢包或儲值活動時，常先討論折扣、贈品與檔期，卻把真正需要長期處理的事情留到後面：這筆交易究竟是什麼？誰發行、在哪個門市核銷、如何讓顧客查詢、遇到退款或客服爭議時，資料是否找得回來？

這些問題不只是行銷部門的待辦事項，也不是靠換一套系統就會自然解決。更務實的起點是先釐清券種與款項性質，再把發行、核銷、退款與會員互動拆成可追溯的資料事件。如此一來，門市、客服、會員經營與財務窗口才能在同一份紀錄上協作，而不是各自拿著不同版本的答案。

數位禮券為何需要流程治理

官方查核已提醒餐飲業者：禮券上的出售日、履約保障、退款與使用限制，會反覆成為被檢視的項目。行政院消費者保護會在 2025 年 5 月公布的第一次查核中，針對 23 家餐飲業者檢視契約內容；其中 4 家全部查核項目符合，19 家有部分契約條款不符合。2026 年 3 月公布的第二次查核，則針對 20 家受查業者，其中 5 家全部符合、15 家有部分契約條款不符合。

這兩次都是受查樣本，不是全台餐飲業普查，也不能被解讀為所有品牌都有相同問題。不過，官方列出的缺失類型，包括出售日、履約保障、退款費用、特殊日或套組限制等，正好說明一件事：當票券只被當成一組促銷碼，資料與流程就容易在發行後斷開。

對連鎖餐飲而言，治理的目標不是把每一張券設計得更複雜，而是讓每個人都能在需要時確認同一件事：這是什麼券、目前狀態為何、可在哪裡使用、是否已核銷，以及遇到例外時該由誰處理。

先分清券種與款項性質

開始設計資料表或活動規則前，先不要把所有數位優惠都叫做「禮券」。經濟部的商品（服務）禮券規範，對有償、有面額的商品（服務）禮券有明確定義；同時也排除無償發行的抵用券、折扣（價）券與電子票證。名稱相似，不代表適用同一套規則。

電子支付帳戶、儲值卡與商品（服務）禮券也不能直接混為一談。金管會的電子支付機構管理條例對電子支付帳戶、儲值卡、收受儲值款項及多用途支付使用有各自定義；其中，僅能向發行人指定者請求商品或服務的商品（服務）禮券，被排除在多用途支付使用之外。對品牌內部的會員儲值安排，仍應依是否為多用途支付、是否經電子支付機構處理、以及實際可兌換對象等交易條件確認分類。

以下不是法律判斷，而是系統與營運團隊在建檔前可先問清楚的分類問題：

把應查資料變成欄位，而不是事後找證明

若屬商品（服務）禮券，規範要求揭露的資訊，本身就是很好的資料治理清單：發行人、面額、發售編號及出售日、使用方式、消費申訴或客服專線、履約保障機制。當這些資訊只存在活動文案、門市話術或不同供應商的後台，退款或顧客詢問一來，現場往往得重新拼湊。

較可行的做法，是讓每張券或每一筆具識別性的票券交易，能回到同一份主檔與事件紀錄。建議把下列欄位視為流程盤點的起點，而非所有品牌都必須照抄的系統規格：

• 券種與角色：券種標籤、發行人、實際服務提供者、銷售或服務通路。
• 發行資訊：面額、發售編號或可追溯識別、出售日、取得方式與對應活動。
• 狀態事件：發行、付款或款項處理、轉贈、查詢、門市核銷、退款申請、退款完成與失敗或例外紀錄。
• 服務脈絡：使用門市、通路、處理時間、客服案件編號，以及需要回到哪一個部門確認的註記。
• 揭露與查詢：讓顧客能找到使用方式、客服入口與可查交易明細的位置；電子方式發行而畫面空間有限時，更應思考如何合理揭露。

這裡談的是資料可追溯性，不是在本文中界定發票、折讓、收入認列或預收款的會計處理。那些議題需要另外依財政、會計或專業意見確認，不能從一張票券的畫面直接推論。

串起發行、核銷與退款的生命週期

只看「已售」和「已核銷」兩種狀態，通常不足以支援門市服務與帳務查核。較完整的流程，會把每一次狀態變化留下時間、來源與處理角色。下面的順序可作為內部工作坊的討論框架，不是法定流程或系統功能清單。

1. 發行前：確認券種、發行與服務角色、適用範圍、需要揭露的資訊，以及客服與門市要看到的內容。
2. 售出或取得時：留下可追溯識別、出售日或發放來源、通路與對應會員或訂單關聯；若屬商品（服務）禮券，出售日會牽動履約保障期間與退券資料。
3. 轉贈與查詢時：保留持有人變動、查詢入口與交易明細，避免門市只看到條碼、卻看不到狀態。
4. 門市核銷時：記錄門市、時間、核銷結果、使用通路與例外原因，並讓 POS、會員或票券系統的狀態能回寫至同一筆資料。
5. 退款或核退時：保留申請、處理、返還金額、是否收取手續費及例外原因。若屬商品（服務）禮券，規範對退還程序、返還金額、手續費上限與不可歸責於消費者情形設有要求；個案仍須先核對券種與條款。
6. 結案與回顧時：把重複失敗、人工覆核、門市拒收、客服轉單或資料不一致等事件整理成例外清單，而不是只看發行量。

電子支付機構管理條例也列示，電子支付機構的附隨及衍生業務可包含商品（服務）禮券或票券價金保管，以及協助發行、販售、核銷相關服務。這是制度邊界的背景，不代表每家電子支付機構都提供相同服務，也不代表所有餐飲儲值方案都屬電子支付。合作前仍應回到實際角色、契約與主管機關資訊確認。

讓門市服務看得到正確狀態

數位票券最容易卡住的地方，往往不是在活動上線當天，而是在顧客站在櫃台前的那幾分鐘。店員需要知道這張券是否能核銷、是否已被使用、要往哪一個客服或後台處理；顧客則需要知道如何查詢、退還或追蹤案件。這些問題若只靠群組訊息，很難累積成下一次可改善的資料。

具名案例可以提供流程觀察，但不能替品牌下結論。iEAT 饗愛吃的 FAQ 顯示，該會員服務把電子票券、點數、退貨、退款進度查詢、電子發票與會員帳戶資料放在同一服務情境中；漢來飯店事業群的退款申請頁與票券狀態查詢頁，則可看到電子券/實體券、退款申請、文件與查詢入口等安排。這些是各自公開頁面所呈現的做法，不是所有餐飲品牌都應複製的標準，也不構成任何條款的合法性判斷。

對門市而言，更值得優先統一的是服務畫面與交接規則：可查的券種與狀態、不可由門市直接處理時的升級路徑、需要保留的佐證，以及顧客可使用的正式查詢入口。讓現場不用猜，也能避免同一位顧客在不同門市得到不同答案。

建立例外檢核與跨部門回顧

禮券與儲值資料的管理，不宜只在大檔期結束後才檢討。建議由會員、營運、門市服務與財務相關窗口建立固定回顧節奏，先確認資料是否完整，再討論需不需要調整流程。這不是成效保證，而是讓風險與例外更早被看見的管理方法。

• 欄位完整性：出售日、券種、發行與服務角色、核銷與退款狀態是否有缺漏。
• 跨系統一致性：票券、POS、會員與客服紀錄是否對得到同一筆交易或同一個處理階段。
• 門市例外：哪些門市或通路經常需要人工處理？是操作、資料、活動設定，還是顧客溝通出了落差？
• 條款與畫面：電子畫面、活動頁、客服說明與門市話術是否仍指向同一版的規則與查詢入口。
• 合作角色：若涉及第三方發行、款項保管或電子支付機構，是否仍能清楚辨識責任、服務範圍與最新公開資訊。

若要查詢電子支付相關機構的基本資料，應以銀行局等主管機關的最新公開查詢頁為準，而不是沿用 2018 年官方新聞稿曾列出的機構名單。至於特定業者能否承作某一方案，仍需依實際許可、契約與交易結構判斷。

來源與引用界線

• 行政院消費者保護會 2025 年第一次餐飲業禮券查核與2026 年第二次查核：本文僅引用受查樣本、日期與官方列出的缺失類型；不外推為全台餐飲業違規率或趨勢。
• 商品（服務）禮券定型化契約應記載及不得記載事項：本文只用於說明商品（服務）禮券的定義、資料揭露、履約保障與退還規則的制度邊界，非個案法律意見。
• 電子支付機構管理條例與銀行局金融機構基本資料查詢：僅用來提醒電子支付、儲值與商品（服務）禮券存在不同分類與主管機關資訊；不判斷個別方案是否適用或合規。
• 綠界 ECTicket 技術文件、iEAT 饗愛吃 FAQ與漢來退款申請頁：僅作具名供應商/品牌的資料狀態或服務流程示例，不當作法規、產業標準、會計處理或成效證據。

常見問題

數位禮券一定不能設定期限嗎？

不能一概而論。若屬經濟部規範所稱商品（服務）禮券，規範列有不得記載使用期限；無償抵用券、折價券及電子票證則有不同分類邊界。實際方案仍要先確認券種與交易結構。

退券是不是都可以收 3% 手續費？

不是。就商品（服務）禮券而言，規範對手續費設有不得超過返還金額 3% 的上限，且不可歸責於消費者的退還不得收取手續費。這不等同於所有券種或所有品牌都可直接套用 3%，個案仍需核對條款與適用範圍。

會員儲值金可直接當作商品（服務）禮券管理嗎？

不宜直接假定。電子支付帳戶、儲值卡、商品（服務）禮券與品牌內部儲值安排的分類可能不同，應依是否為多用途支付、是否經電子支付機構處理，以及是否只能向指定人兌換商品或服務等條件確認。

結語：讓會員工具回到可管理的交易流程

數位禮券與會員儲值的治理，不是把規則寫得愈長愈好，而是讓券種、角色、狀態與例外都有可回查的紀錄。先分類，再建立欄位與生命週期，最後讓門市、客服與總部用同一份資料處理問題，才能把活動工具轉化為較穩定的會員服務與帳務風險管理流程。

Metabiz 可協助餐飲品牌盤點會員、POS、票券、點餐與客服資料之間的欄位與交接流程，整理發行、核銷、退款與例外案件的可追溯資料視圖。從先釐清資料定義開始，讓門市服務、會員經營與後台管理不必各自猜測。