maokiddo 折價券系統

01 · Background

專案起點

我加入這個專案時，maokiddo 的會員誘因機制只有點數系統（消費累積、點數折抵），完全沒有折價券或折扣碼的能力。這對一個電商平台來說是很基礎但實際缺失的功能：行銷想跟寵物 KOL 異業合作發折扣碼、辦 LINE 好友招募活動，平台上沒有任何工具可以執行，只能靠人工調價或額外贈品這類不精準的方式變通。

我的任務是從 0 到 1 規劃並設計一整套折價券系統——後台怎麼發、前台怎麼查、怎麼用，全部都要從無到有定義出來。

02 · Problem

問題與機會

問題拆成三層：

• 功能面：作為電商平台，缺少折扣促銷這個最基本的行銷工具，任何需要「打折」驅動的活動完全無法執行，只能靠人工調價變通。
• 體驗面：這套系統要從 0 開始定義，會員端也還沒有「我的折價券」入口，序號輸入是否有效、有沒有過期、能不能在結帳套用，都要一併設計出明確的即時回饋。
• 驗證面：即便系統做出來、券發出去了，也需要一套機制回答「這些券最後有沒有變成訂單」，否則行銷成效還是黑盒子。

03 · Process

從需求到解法

時效壓力：暑期旺季卡關

專案啟動時正好是七月，寵物電商的暑期旺季，行銷端已經在談多組 KOL 異業合作與 LINE 好友招募活動，但因為平台完全沒有折扣工具，這些活動全部卡住動不了。這個時間壓力直接影響了我怎麼拆分開發範疇——不是把整套系統想清楚再一次做完，而是先讓行銷能動起來，再補齊風控與數據能力。

兩個 Sprint 的範疇拆分

當時一個 Sprint 兩週，整套系統一個月內完成。我把功能拆成「折扣碼」（會員自行輸入）與「系統發送」（後台主動指派給特定會員）兩種型態，依急迫程度分兩個 Sprint 交付：

風險意識的設計決策：系統發送多做了「收回」機制

系統發送是後台主動把券發給會員，一旦設定錯了（金額打錯、發錯對象、發錯數量），人工很難即時補救，可能造成實際的財務損失。所以我在系統發送的規則裡額外設計了「收回」功能，讓已發放但尚未使用的券可以被撤回止損。折扣碼則不同——因為需要會員自己主動輸入才會生效，設定有誤時，使用端本身就多了一層自然的確認關卡，風險本來就低很多，所以沒有做對應的收回機制，避免過度工程增加開發成本。

收回機制 — 系統發送的券在尚未使用前可撤回止損，折扣碼型態則不做此設計

後台管理系統（規則引擎 + 監控）

• 兩種發放型態（折扣碼／系統發送）延伸出固定金額／百分比折扣兩種計算方式
• 每組券可設定活動期間、使用上限、狀態機（未啟用／已啟用／已暫停／已結束）
• 針對「折扣碼 × 系統發送」與「四種狀態」的組合，逐一設計「再次編輯」畫面，確保每種情境下可調整與不可調整的欄位都清楚區分（例如已啟用的券不能再改折扣金額，但可以調整到期日）
• 加上折價券發送記錄、到期前通知記錄，讓營運同事能主動掌握即將到期、尚未使用的券，而不是被動等會員反應

前台會員體驗（Web + Mobile 一致但不強行複製）

• 「我的折價券頁」以分頁呈現（可使用／已使用／已失效），並可用「即將到期」勾選篩選，會員一眼就能分清楚手上券的狀態，也能主動篩出快過期、該優先使用的券
• 序號輸入設計了即時驗證回饋：有效／無效兩種狀態各自有明確的視覺與文字提示，降低會員「不知道有沒有成功」的猶豫
• 針對「還沒有任何券」設計了空狀態，針對資料讀取設計了 loading 狀態，避免會員誤以為頁面壞掉
• 結帳頁銜接：券可直接在結帳頁套用；沒有可用券時不是留白消失，而是給出「無折價券可用」的明確狀態；也設計了「送出結帳後付款失敗（重新付款）」的情境，避免會員以為折價券被重複扣用
• Mobile 版不是把 Web 版直接縮小：使用說明用 Popup（Web）在手機版改為 Bottom Sheet，符合手勢操作習慣

04 · User Flow

會員與管理端流程

05 · Design

設計關鍵決策

• 序號驗證的即時反饋，而非等結帳才知道結果：有效／無效狀態各自有獨立畫面設計，讓會員在輸入當下就知道券能不能用，而不是走到付款那一步才被打回票。
• 結帳頁「無折價券可用」做成明確狀態，而非讓區塊消失：消失會讓會員以為系統壞了；明確告知「目前無可用券」，是刻意的信任感設計。
• Web 用 Popup、Mobile 改 Bottom Sheet：使用說明彈窗在兩個平台用了不同的互動模式，是考慮到手機單手操作與觸控手勢後的差異化決策，不是單純的 RWD 縮放。
• 後台「再次編輯」依狀態拆成多個獨立畫面：已啟用、已暫停、已結束的券，可調整的欄位都不同，用不同畫面而非同一表單動態隱藏欄位，降低了營運同事誤改已生效規則的風險。
• 系統發送才做「收回」機制，折扣碼不做：這是刻意的取捨，不是漏做。系統發送是後台主動推券給會員，設定錯誤時人工難以補救、有實際財務風險，所以需要收回止損；折扣碼要會員主動輸入才生效，本身就有一層使用端確認，風險低很多，不需要為此增加開發成本。

06 · Results

上線後帶來了什麼？

• 開發面：在暑期旺季的時效壓力下，以 2 個 Sprint（1 個月）從零建立前後台一致的折價券系統，Sprint 1 先交付前台折價頁面＋折扣碼功能解決行銷燃眉之急，Sprint 2 補齊系統發送（含收回止損機制）與分析報表；整個過程在不拖累行銷活動時程的前提下如期交付。
• 牽引力：系統穩定支撐了 45 組不同折扣方案，涵蓋 KOL 異業合作、LINE 好友獲客、大額無門檻券等多種行銷情境。
• 商業面：整體兌換率僅 0.12%，數字本身不理想，但主因並非折價券系統本身的設計問題——同一時期平台 1.0 版本的會員註冊流程存在較多 bug，導致用戶留存率偏低；加上行銷造勢的時間來不及銜接系統上線的節奏，難以快速集客，兩者疊加壓縮了折價券能發揮效果的用戶基數。轉換率低不代表這個功能沒價值，而是要先拆解問題到底出在券本身，還是出在券之外的整體體驗。
• 數據觀察：平均折扣金額（$625）高於平均訂單金額（$264），排除留存因素之外，這點在制定折扣門檻與力度時仍是值得檢討的設計基準。

下一階段追蹤指標建議：從「取得折扣碼」到「我的折價券頁查詢」到「結帳套用」三段的流失率、依受眾分眾後的兌換率對比、券別 ROI（帶動營業額 ÷ 折扣支出），並搭配同期註冊/留存數據交叉比對，才能公平評估折價券本身的成效。

07 · Reflection

成長與反思

系統上線後我做的不只是「把前後台功能生出來」，而是回頭用報表數據檢視整個發券策略是否真的有效。這裡最想放進作品集的，是誠實面對一個不算漂亮的數字時的判斷過程：轉換率低，第一反應不是急著替系統辯護、也不是照單全收把責任攬在自己設計上，而是先拆解問題——是平台當時 1.0 版本註冊流程的 bug 拖累了留存、行銷時程沒能跟上系統上線速度，還是折價券本身的規則設計就有問題。這三者要分開看，才不會誤判，也才知道下一步該推的是留存體驗還是券的規則。

如果重來一次

• 我會在專案初期就標記出「這個功能的成效高度依賴平台整體的註冊與留存體驗」，並在報表上加註這個前提，避免單看轉換率就誤判這個功能本身的成敗。
• 我會追蹤「取得折扣碼→進入我的折價券頁→結帳套用」這條路徑的流失率，現在只看到最終使用率 0.07%，但看不出會員是根本沒看到券、看到了不會用、還是用了但沒結成單。
• 我會在發券前就先定義「合理折扣區間」，避免出現折扣金額大於訂單金額的狀況。
• 我會把「兌換率」「使用率」當成發券審核的必要條件，而不是等券發完才回頭做報表。
• 我會替不同發放情境（KOL 導流 vs. 大量無門檻券）分別建立轉換基準，而不是用同一套指標評斷所有券的成效。
• 前台體驗上，我會考慮在會員登入後的首頁增加更明顯的「有可用折價券」提示入口，而不是只讓會員被動地在我的折價券頁才看得到。