點數、優惠券與會員等級串接時，最容易出錯的 7 個流程

會員制度規則看起來通常很簡單：消費累積點數、達到門檻升等、生日發優惠券。
但系統開始串接 POS、電商與 CRM 後，問題通常出現在交易狀態、權益異動與例外處理。這篇不討論會員制度該設幾級，而是拆解實際串接時最容易出錯的 7 個流程。

門市退貨後點數沒有扣回、電商取消訂單卻已計入升等、優惠券 POS 已核銷但會員中心還能使用。這些狀況多半不是規則本身有問題，而是交易狀態與會員權益之間沒有定義清楚。

1. 訂單成立就入點

「訂單建立」不一定代表交易完成。

電商可能有未付款、取消、退貨，門市也可能發生退刷。如果收到訂單就立即發點，後續就必須處理大量點數沖銷。

導入前應先定義：什麼訂單狀態才算有效消費？

點數也不建議只保存餘額，最好留下每次入點、扣點與來源訂單紀錄，未來退貨與客服查詢才有依據。

2. 退貨了，點數卻沒有扣回

會員消費 10,000 元取得 100 點，之後退貨 5,000 元，到底扣 50 點還是全部扣回？

如果會員已經把點數用掉，又該如何處理？

點數制度串接交易系統時，必須先定義整筆退貨、部分退貨、取消訂單與點數不足的處理方式。

實務上建議保留原始入點紀錄，再新增一筆負向異動，而不是直接修改原紀錄，後續才查得到完整歷程。

3. 同一張優惠券被發了兩次

生日禮、入會禮與升等禮很容易遇到重複發放。

例如系統其實已成功發券，但 API 回應逾時，外部系統重新送出相同事件，如果沒有防止重複執行，同一會員就可能拿到兩張券。

因此系統需要定義唯一發放條件，例如：

會員 + 活動 + 發放年度

而不是單純收到事件就再次發券。

4. POS 已核銷，CRM 卻顯示還能使用

優惠券真正麻煩的通常不是產生券，而是核銷狀態。

如果 POS 已套用折扣，但呼叫 CRM 核銷 API 時中斷，就可能發生：

POS：已使用
CRM：可使用

反過來，CRM 已核銷但 POS 結帳失敗也可能發生。

因此必須先確認哪套系統負責優惠券最終狀態，以及結帳取消、API 失敗時要如何回復。

5. 升等了，卻沒有定義退貨後怎麼辦

例如年度消費滿 30,000 元升 Gold。

會員今天剛好達標並完成升等，隔天其中一筆訂單退貨，低於升等門檻，要不要立即降回原等級？

如果升等時已經發送升等券，優惠券又要不要收回？

會員等級制度除了升等門檻，也要定義生效時間、計算期間、退貨處理、續等與降等規則。

6. 會員重新升等，升等禮又發一次

會員從 Silver 升到 Gold，取得一張升等禮。

後來因資料修正降回 Silver，幾天後重新計算又變成 Gold，系統要不要再發一次？

這沒有唯一答案。

有些品牌設定「每年只能領一次」，有些則是「每次符合正式升等都能取得」。

因此會員等級與「已取得的會員權益」最好分開管理，否則很難處理這類例外情況。

7. POS、電商同時同步，產生重複點數

OMO 情境下，同一會員可能同時從門市與電商產生交易。

如果 API timeout、Webhook 重送或排程重跑，同一張訂單就可能被處理兩次。

系統至少需要處理：

• 唯一交易識別
• 重複事件判斷
• API 錯誤重送
• 資料同步狀態
• 異動紀錄與 audit log

並不是所有資料都需要即時同步，但像點數入帳與優惠券核銷，就要先確認品牌能接受多少時間差。

Loyalty 串接前，先把交易流程畫清楚

很多品牌一開始會先討論「100 元幾點」、「會員分幾級」、「要發哪些優惠券」。

這些是制度規則，但系統真正需要確認的是：

訂單 → 付款 → 入點 → 升等 → 發券 → 核銷 → 取消／退貨

每一個狀態改變時，哪些資料要同步？由哪一套系統決定？失敗後如何補償？

把這條流程先定義清楚，再開始串接 POS、電商與 CRM，可以減少後續人工調帳、重複發券與會員權益錯誤。

如果 POS、電商與 CRM 之間連同一位會員都還無法正確對應，建議先確認會員主 ID 與身份對應方式，再處理點數、優惠券與會員等級的跨系統同步。