網店與市集
低於成本的價格，不要讓它上線
一個促銷價輸入錯了，一張試算表拖多了一行，或者幣值當成了另一種，於是一個低過「成本加平台抽成」的價錢就這樣上線。要等到收到結算，才有人發現。網店本身不會幫你攔：價錢只是一個普通欄位，而平台的抽成是事後從交易紀錄才知道的數字。所以那條底線要由你自己計算、存放在商品旁邊，再拿去同真正在線上的價錢比對。
- 觸發
- 兩個
- 執行頻率
- 每晚一次
- 工具
- 4 件
- 需要 durable execution
- 不需要
流程
上面那條在有人提出新價錢那一刻計出底線，下面那條讀取真正在線上的價錢再比對。兩個觸發，因為錯價有兩條路來：一條是輸入出來的，一條是活動結束後留低的。
有人提出新價錢
Sheets · Airtable
取成本，並推算抽成
n8n · Make
存起這條底線
Sheets · Airtable
每晚一次
n8n 排程
讀取線上價錢
Shopify Admin API
是否跌穿底線？
n8n IF
通知負責定價的人
Slack · WhatsApp
維持原價
—
逐步拆解
- 01
有人提出新價錢
Sheets · Airtable有人在定價表寫入一個新價。在這裡截到，成本低過在線上截到；但單靠它並不足夠——價錢亦會經活動同批次修改而改變，那些改動從來不會經過這張表。
- 02
取成本，並推算抽成
n8n · Make由商品資料取到岸成本，再按平台公開的收費表推算它的抽成：佣金級距、支付手續費、活動抽成。這裡是推算而不是實測，因為真正的數字要有成交之後才存在。
- 03
存起這條底線
Sheets · Airtable把計出來的底線寫在商品旁邊，連同得出它的成本同費率假設。半年之後，有用的一欄不是底線本身，而是那組假設——它才分得出這次跌穿是定價出錯，還是成本數字太舊。
- 04
每晚一次
n8n 排程檢查由計時器帶動，因為網店沒有提供任何鈎子，讓你在價錢公開之前站在它前面。每晚一次是誠實的頻率：它截到錯價的時間是一日之後，而不是一次結算之後。
- 05
讀取線上價錢
Shopify Admin API讀客戶實際見到的價錢，而不是試算表相信的價錢。折扣價同活動價都要包括在內——表上價過到底線、活動價卻跌穿了，是常見情況，不是罕見情況。
- 06
是否跌穿底線？
n8n IF拿線上數字同存起的底線比較。容差要定得講得出道理：清倉貨品差幾仙是進位造成的，同樣的差距落在主力貨品身上，就應該是有人刻意做過的決定。
- 07
通知負責定價的人
Slack · WhatsApp寫明貨號、線上價、底線，以及底線背後那組假設。不要預設自動改回原價——蝕本引流是一種真實策略，一個會靜靜地把它撤回的流程，破壞力大過那個錯價本身。
平台不容許的事
其中兩項解釋了底線為什麼要自己計、不能直接讀；另外兩項決定了跌穿之後，你可以修得幾快。
成本存放在 inventory item 上，而且讀取它是一項權限，不是理所當然：Shopify 寫明「the user must have 'View product costs' permission granted in order to access this field once product granular permissions are enabled」。沒有這個權限的整合，會計出一條等於零的底線，然後全部放行。
Shopify Admin GraphQL API — InventoryItem平台真正的抽成是成交之後才出現在交易紀錄上，而 Shopify 對該欄位的說明是：手續費「Only present for Shopify Payments transactions」。所以上線前那條底線，只能由公開的收費表建立，不能由平台實際收過你多少建立。
Shopify Admin GraphQL API — OrderTransactionproductVariantsBulkUpdate 的說明是「Updates multiple product variants for a single product in one operation」——一次呼叫涵蓋一件商品，不是整個目錄。如果跌穿的是一整個系列，修正就是每件商品一次呼叫，修得幾快由此決定。
Shopify Admin GraphQL API — productVariantsBulkUpdate每晚的讀取同之後的修正，計的都是查詢成本而不是請求次數：標準方案每秒 100 點、Advanced 200 點、Plus 1,000 點，而且「A single query may not exceed a cost of 1,000 points, regardless of plan limits.」一次過拉走全部變體的查詢，會先因為成本而失敗，不是因為數量。
Shopify — API rate limits
什麼情況不值得做
以下三種情況，維護成本會高於偶爾出一次錯價的代價。
你的毛利足夠闊，任何合理的手誤都跌不穿成本。這個流程是為那條窄帶而設——折扣同抽成加起來剛好越線；沒有那條窄帶，它只是一個每晚都答「否」的排程。
你不知道每個貨號的到岸成本。用估出來的成本計底線，比沒有底線更差：它會產生一個大家會信的數字，而第一次它錯在寬鬆那一邊之後，就再沒有人看那些提示。
定價由一個人決定，而毛利也是同一個人負責。這個檢查等於為一個已經有人判斷過的決定再加一次判斷，提示最後亦只是回到它出發的那張枱。