行銷部想在檔期前把免運門檻從一千二調到九百九,測試看看轉換率。這個「調一個數字」的需求,旅程是這樣的:寫需求單、等工程師排程、改完部署、驗證——兩週過去,檔期只剩三天。
運費規則是行銷工具,但在很多系統裡,它被做成了工程參數。
問題出在當初的設計把數字寫死在程式裡。本島運費多少、外島加多少、滿多少免運——這些值散在程式碼各處,每改一次都是一次開發。於是「試試看不同門檻」這種本該一天內完成的行銷實驗,變成了跨部門專案。
金葡萄蛋黃酥的做法是把運費規則整包搬進後台:本島與外島、訂單金額分幾級、免運門檻多少,全部是後台自己能改的欄位;改完購物車當場就照新規則算給客人看。中秋檔期的特殊規則、公休日、時段人數上限,也都是同一個邏輯——營運策略要動,不必經過工程師。
判斷一套電商系統好不好,有個簡單的測試:問老闆「你想改免運門檻,要花多久?」答案是「幾分鐘」還是「開需求單」,差的是整個旺季的靈活度。
哪些設定該開放給後台、哪些該鎖住,這條線怎麼畫,寫在金葡萄蛋黃酥的案例。