我花了一個下午幫 91APP-iCHEF debug
更新5/12:
我為了這個案例做了一個商業洞察：http://case.4force.com.tw
有興趣嗎？我還在噴錢。什麼叫AOV suppression case？這個就是。謝謝。
2026年5月10日，我的一個UBER核心顧客。在我們店消費18筆。在 Uber Eats 留下了一則五星評論：
「因為肉片是用勾選的，沒辦法加到2份以上，希望能改進」
五星。她還是給了五星。然後我去查系統。
問題很簡單
我們是火鍋外送品牌，使用 iCHEF POS 串接 Uber Eats 與 foodpanda。火鍋的核心加購邏輯是：客人可以重複點同一種肉片，例如豬肉片×2、牛肉片×1。這在餐飲業叫做 Quantity in Modifiers，不是什麼新功能。
現況：
- foodpanda：正常
- Uber Eats：同一品項只能選一份（單選方塊）
我花了一個下午自己 reproduce：
- 進 Uber Eats 後台手動開啟複數選取 → 前台正常
- 在 iCHEF 後台執行同步（publish）→ Uber Eats 被強制覆蓋回單選
一刀未剪的操作影片我都錄下來了。
這不是什麼大Bug，這是大低級Bug
崩潰、閃退叫工程事故。這個叫產品認知事故。
Uber Eats 後台原生支援這個功能，API 接口是開的。這代表只有三種可能：
- BD 沒談到：商務對接能力有問題
- RD 沒接：產品優先級長期錯置
- Support沒管：有問題先解決客戶腦袋認知問題，不看問題本質。
而且 foodpanda 能跑，代表邏輯層已經存在。Uber 端沒接上，不是技術問題。
客服 SOP 是這部機器的縮影
我今天跟 iCHEF 客服周旋了將近兩個小時。她一直在解釋「設定單選就會同步單選」這是對的，但不是我問的問題。
我問的是：我設定複選，為什麼同步過去變單選。
這兩句話不是同一句話。
客服 SOP 訓練她「解釋規格」，不是「聽懂客戶問題並轉客服層級」。這代表這家公司的服務設計，核心是保護自己不出錯，不是幫店家解決問題。
我最後自己整理了一份完整的 incident report 喂給她，她才後送工程。
然後我去看了 91APP 的 IR 頁面
「以 AI 技術與洞察分析作為底層能力，提供線上與線下的全通路解決方案」
一個火鍋店加肉片的 quantity modifier，要靠客人寫評論才被發現。
91APP 收購 iCHEF 之後，市場期待的是整合升級。目前看到的是：大公司的 priority 錯置，包裝在漂亮的 IR 文字裡。
iCHEF 客戶規模以萬家計，受影響業態只要是需要「同種品項加購複數份」的店。火鍋、燒肉、手搖飲。影響有幾千家？我不知道，但我知道一定有人AOV掉了。但我有我自己的數字，還有那張五星熟客好心截圖。
「這是 91APP 過去兩年的股價走勢。」
這是實測影片
https://www.youtube.com/watch?v=hqcIungClbg
如果 iCHEF 的訂閱費扣款功能壞了 72 小時，你覺得他們會「輕輕放下」嗎？絕對是全公司燈火通明修到好。
但店家的營收功能壞了，他們卻可以讓客服在那邊陪你繞圈圈。
建議攻城獅：
系統發送payload給uber後，為什麼沒做一個監控層去比對發送出去的值與ichef後台設定的值是否一致做diff check？
監控訂單特徵很難嗎？加購註記複數的訂單佔比變成0%，你們alert不會自動噴給PM嗎？
這不是技術問題，這是你們覺得誰的錢比較重要的問題。
萬事皆宜，天作之合 Wesley 萬合天宜有限公司 4Force Lab
歡迎造訪 4force lab 官網，了解我們是誰。
