精品咖啡訂閱電商的生日點數事故：查了才發現四成會員沒被祝福

有家做精品咖啡豆訂閱的電商，做了一個很基本的會員福利：生日發點數。邏輯簡單到不行，排程每天跑一次，撈出當天生日的會員，發點數，寄通知。上線半年多，沒人懷疑過這件事有問題，因為系統從來沒報錯。直到有天客服隨口問了一句：欸，我表哥上個月生日，怎麼沒收到咖啡豆折抵點數啊？

查帳查到自己心虛

我們回去比對正式會員資料庫才發現，原本發送名單的來源，只抓「填過完整生日資料的會員」，就是那些在下單流程裡順手填了生日、留給系統做行銷用的人。結果一查，全站有效會員裡，將近四成的人根本沒有這筆完整資料，可能是用會員快速註冊沒填全，也可能是買了不需要額外填資料的商品。這四成人不是不想收，是系統壓根不知道他們生日是哪天，也就永遠不會被排進名單。

系統邏輯正確不代表資料覆蓋率正確，這是兩件完全不同的事。

資料來源要有備援，不是隻有一條路

解法不是重寫整套邏輯，是把資料來源拆成兩條線：原本那條「填過完整生日資料」的照舊不動，另外新增一條抓「會員註冊時基本資料裡的生日欄位」，兩邊查出來的名單去重合併。這條新來源預設開啟，但留了一個開關，一旦哪天發現有誤判可以隨時關掉退回原邏輯，不用重新部署。上線前先跑過一次全量比對，抓出真正被漏掉的名單數字，才知道問題規模有多大，不是拍腦袋猜的。

手動補發也要讓系統看得懂

另一個容易被忽略的地方是，客服如果用「手動調點數」的方式幫忙補發生日禮，系統會把這筆記成一般調整，不會標記成生日發放。隔年排程再跑一次判斷邏輯的時候，系統完全不知道這位會員去年已經收過生日禮，很可能會重複發放，或者反過來誤判成已經處理過而跳過。我們後來加了一個獨立的判斷欄位，讓補發用同一套邏輯記錄，年份加會員編號組成唯一識別，這樣不管是排程自動發還是客服手動補，系統都認得，不會打架。

• 定期抽查「應該被服務到但沒被服務到」的名單，不要只看系統有沒有報錯
• 任何依賴單一欄位判斷的自動化邏輯，都該問一句：資料填不全的人怎麼辦
• 人工補救的動作要讓系統記得住，否則下一輪自動化還是會出包

系統跑得順，不代表所有該被照顧到的人都被照顧到了。