Cowork 每朝 9am 拉 Shopify 訂單：庫存 / 送貨 / 退款三個提示一頁睇晒

情境

你開 Shopify 小店，每朝坐低第一件事——撳開 admin，順序 check 三樣嘢：

• 噚晚有冇隔夜訂單？同前一日 / 上星期同一日比，多咗定少咗？
• 邊啲 SKU 跌穿補貨線？順豐單寄出之後啲存貨夠唔夠頂到下個禮拜？
• 有冇送貨延誤（順豐卡咗喺中轉站）、有冇退款要求未處理？

熟手都要 15–20 分鐘——而且呢 20 分鐘係每朝重覆嘅嘢，唔做又會走漏眼（特別係退款拖過 48 小時就會收差評）。

Cowork 啱啱好做呢類工作：每朝 9am 自動拉 Shopify Admin API、跑三條 query、出一封一頁紙嘅 email（或者 Slack 訊息），9:00–9:15 你飲住咖啡掃一次，有問題先撳入 admin 跟，冇問題就過下一單。

利益申報：Cowork 仲係 research preview，要 Pro/Max plan。Shopify API 連住你嘅銷售數據——用唯讀權限（read_orders、read_products、read_inventory、read_fulfillments），唔好畀佢寫入權限。

跟住做

1. Shopify private app + 唯讀 token

Shopify admin → Settings → Apps and sales channels → Develop apps → Create an app（叫「Daily Ops Reader」就得）。

Admin API 權限只揀：

• read_orders
• read_products
• read_inventory
• read_fulfillments
• read_customers（退款要配對返客戶）

Install 完攞個 Admin API access token，貼入本機 ~/Documents/shopify-ops/.env（唔好 commit 落 git）：

SHOPIFY_STORE=your-store.myshopify.com
SHOPIFY_TOKEN=shpat_xxxxxxxxxxxx

2. 核心 prompt — 設定一次、每朝 9am 跑

我開一間香港 Shopify 小店（賣家品），用 SF Express 寄貨，付款方式有 Stripe / FPS / COD。每朝香港時間 9:00am 自動跑以下流程，用 ~/Documents/shopify-ops/.env 入面嘅 token 連 Shopify Admin API（唯讀）：第一段 — 隔夜訂單（過去 24 小時）
總單數、總銷售額（HKD）
付款方式拆分（Stripe / FPS / COD 各幾單）
同前一日比 +/- %，同上星期同一日比 +/- %
標示任何單一訂單 > $2,000（高價單要人手確認落單真確）
第二段 — 庫存提示
讀 ~/Documents/shopify-ops/reorder-thresholds.csv（我自己維護，列 SKU + reorder_point + supplier_lead_days）
列出所有 inventory_quantity ≤ reorder_point 嘅 SKU
排序：剩餘日數最少（用過去 14 日嘅銷售速度估）排最頂
已經叫咗供應商嘅唔好出（我會喺 CSV 加 on_order=Y 欄）
第三段 — 送貨延誤 + 退款
已出貨但順豐 tracking 停咗 ≥ 48 小時冇更新：列 order #、客名、tracking、停咗幾耐
過去 7 日仲係 pending 嘅退款要求：列 order #、退款原因、金額、客等咗幾耐
輸出格式 — 一頁 email：
Subject：[Shopify Daily] YYYY-MM-DD — X 單 / $XXXX / Y SKU 低庫存 / Z 個退款待處理
內文分三段（用上面三個標題），每段控制喺 5 行內
結尾加一句「需要即時跟進嘅事項」清單（最多 3 項，由 AI 自己判斷）
寄去 boss@mystore.hk。限制：
絕對唔好改 Shopify 任何嘢（唯讀）
唔好自動回客 / 自動退款
數據對唔上（例如 API timeout）→ email 寫「數據不完整」，唔好估
用 HKT 時區、HKD 銀碼
定好之後同我核對，再排程每朝 9:00am HKT 跑。第一次預演唔好真寄 email，出結果畀我睇。

3. 調校你嘅提示門檻

第一個禮拜出嘅 email 通常會「太嘈」——例如低庫存名單列咗 20 個 SKU，但其實一半你已經叫咗貨。呢度就係 reorder-thresholds.csv 嘅作用：

sku,reorder_point,supplier_lead_days,on_order
HKD-CANDLE-01,15,7,N
HKD-DIFFUSER-02,8,14,Y
HKD-SOAP-03,30,5,N

調門檻嘅原則：reorder_point = (每日平均銷量 × supplier_lead_days) × 1.5。1.5 倍緩衝係畀順豐偶爾延誤 + 你忘記落單嘅寬限期。

退款嘅 48 小時門檻可以調——如果你係食品 / 易壞貨，改 24 小時；如果係接單先做、慢慢整嘅，可以調去 72 小時。

4. 每朝 9:00–9:15 嘅檢視習慣

Cowork 出嘅 email 9:00 入到信箱。你嘅 15 分鐘咁用：

• 9:00–9:05 掃隔夜訂單：總數 OK 就跳過；異常高（疑似刷單 / 跌穿 50%）先撳入 admin。
• 9:05–9:10 庫存：揀「剩餘日數 ≤ supplier_lead_days」嘅即時 WhatsApp 供應商。叫完貨入返 CSV on_order=Y，下日佢就唔再煩你。
• 9:10–9:15 送貨 + 退款：順豐卡咗超 72 小時嘅，主動 WhatsApp 客戶報平安；退款全部當朝清，唔好過夜。

呢個習慣幾關鍵——AI 出提示嘅價值唔係「幫你做晒」，而係逼你每朝 15 分鐘埋一次數。冇提示你會懶得做，有提示喺面前你就會做。

變化例子

變化 1：多間舖一齊睇嘅總覽 dashboard

我有兩間 Shopify 舖（旗艦店 + 特賣店），用唔同 .env 檔：
~/Documents/shopify-ops/store-main.env
~/Documents/shopify-ops/store-outlet.env
請改造流程：
兩間舖各自跑一次同樣 query
Email 出一封，subject 列「Main: X 單 / Outlet: Y 單」
內文分兩個 section，每間舖三段（訂單 / 庫存 / 送貨+退款）
喺最頂加一個全店層面嘅總結：總銷售、邊間舖跑贏邊間（同上星期比）
庫存門檻 CSV 兩間舖各自獨立維護
如果有個 SKU 兩間舖都缺貨，喺總結度標示「跨店缺貨」。

變化 2：加埋 Meta / Google Ads ROI

除咗 Shopify，請連埋 Meta Ads + Google Ads（用 ~/Documents/shopify-ops/ads-tokens.env 嘅 token）。加第四段 — 廣告成效（過去 24 小時）：
Meta：花費 (HKD)、曝光、購買 (pixel)、ROAS
Google Ads：花費、點擊、轉換、ROAS
合併 ROAS = Shopify 收入 ÷ (Meta + Google 花費)
標示任何單一 campaign ROAS < 1.5（蝕緊錢）
標示花費 > 預算 120%（呢個門檻喺 ads-budget.csv 入面維護）
留意：Shopify 嘅收入同 Meta pixel 嘅歸因通常有 10–20% 落差，唔使逐蚊對，睇趨勢就得。

變化 3：Sale 期間密集監測

12 月 1 日到 12 月 5 日（年尾大減價期）：
改成每 2 小時跑一次（9am / 11am / 1pm / 3pm / 5pm / 7pm / 9pm）
簡化輸出：淨係出訂單 + 庫存兩段（退款一日總結一次就夠）
庫存提示改用更嚴門檻：剩餘日數 ≤ 3 日就標示
加一個「賣貨速度」指標：呢 2 小時嘅單數 / 平日同時段平均
任何 SKU 喺呢 2 小時跑出超過 20 單 → email subject 加 [HOT]，要即刻決定加唔加價 / 收檔
減價完之後（12 月 6 日）自動還原做一日一次 9am 跑。

拆解：點解會 work，同點解會爆

跟到上面就已經用得。下面呢段係畀**想由「跑一次 demo OK」做到「跑足一年都信得過」**嘅人——初學者可以跳過，唔影響你跟住做。

自動化最唔老實嘅地方係：第一次出嘅 email 靚仔，唔代表第 365 次嘅數字仲係準確。 呢個 Shopify ops dashboard，實際會喺呢幾個位爆，你要預咗：

1. 順豐 tracking「停咗」其實係 Shopify 睇唔到 Shopify fulfillment 嘅 tracking 狀態係靠快遞公司推送更新——順豐唔係所有環節都有即時 webhook 推返 Shopify，有時明明已派到，Shopify 嗰邊仲係舊狀態，Claude 就標成「卡咗 ≥ 48 小時」。

• 會爆成點：你收到提示、搵客、客話「噚日已收到喎」——白費時間，又令提示失去公信力。
• 點救：用呢個 prompt 係做早期發現，唔係最終裁決。加落去 prompt：「標示前先核對 Shopify fulfillment page 係咪真係無更新，而唔係 tracking number 打錯或快遞商未回報。」疑似誤報嘅規律多起嚟就聯絡順豐申請 API 直接接入。

2. 庫存數字係「帳面數」，唔係「倉庫真實數」 Shopify 嘅 inventory_quantity 只反映系統入面嘅數，如果你有線下市集銷售手動扣貨、供應商送貨未入系統、或者貨喺途中仲未到，帳面數同實際存貨差距可以好大。

• 會爆成點：明明有存貨，AI 叫你補貨；或者反過來，帳面夠但倉庫係空嘅——後者更危險，因為你唔會即時知。
• 點救：入貨落倉當日要即時更新 Shopify inventory（唔係隔日），線下銷售用 Shopify POS 或者手動扣貨；定期（每個月）做實地點倉同 Shopify 對數，差額即時調番。

3. API call 被截斷但 Claude 唔知 Shopify Admin REST API 有 call rate limit（每個 app 每秒有上限）。如果你跑兩三間舖加埋廣告 API，有機會喺中途觸到限制，某一段 query 回傳空值或 error。Claude 未必識別錯誤同正常空值嘅分別，可能出一份「看似完整但其中一段缺數」嘅 email。

• 會爆成點：庫存一段出咗「冇低庫存 SKU」，其實係因為 API 未跑完，你誤以為今日庫存 OK，錯過補貨。
• 點救：喺 prompt 加：「每段跑完 check HTTP response code，唔係 200 就喺對應段落寫『API 未能取得數據，請人手核對』，唔好出空白。」另外喺 SHOPIFY_TOKEN 嗰個 private app 開 API call log，偶爾睇下有冇 429 error。

4. 退款只睇 pending 會漏走「已批出未落賬」 Shopify 退款有多個 status：pending（申請中）、open（已批准、處理中）、success（已完成）。Prompt 只篩 pending 嘅退款，open 狀態——即係已批出但 Stripe / FPS 仲未回賬客戶——唔會出現喺提示。

• 會爆成點：你以為退款清晒，但有幾單已批出嘅退款其實仲 pending 落賬，客戶等唔到錢就投訴。
• 點救：將退款篩選改為：「列出 status 係 pending 或 open 嘅退款」——兩個都要跟，直到 success 先算完成。

5. 環比數字用錯時區搞甩比較基準 你 Shopify store 嘅時區設定影響 API 回傳嘅時間戳。如果 store 設咗 UTC（Shopify 新帳嘅預設），「過去 24 小時」嘅切割點係 UTC 00:00，唔係 HKT 00:00；「同上星期同一日比」如果跨晒假期或者促銷日，數字咋唔正常但唔係真實趨勢。

• 會爆成點：每朝環比顯示「跌 30%」，其實係因為 UTC 日期切割比你早咗 8 小時，今日只有幾個鐘嘅單對比昨日全日。
• 點救：Shopify admin → Settings → General → Store time zone，改成「Asia/Hong Kong (UTC+8)」；Prompt 入面明寫「用 HKT 時區做日期切割」，並請 Claude 每次喺 email 頂部標明「統計區間：YYYY-MM-DD HKT 00:00 至 HKT 08:59（出報告時間）」方便人手核對。

呢幾個位，就係「第一次跑靚仔」同「跑足一年、每朝 email 數字都信得過」之間嘅距離。

點解呢個 task 啱 Cowork

每朝 9am 開 admin 行三圈嘅嘢，唔係難——係「日日要做、漏一日就有人投訴」。Cowork 嘅價值唔係取代你嘅判斷，而係幫你每朝塞一封信入信箱，逼你飲咖啡嗰 15 分鐘埋一次數。

呢個任務符合 Cowork 嘅篩選條件：

• 重覆：一年 365 次
• 機械式：API call + 門檻比對，冇創意成份
• 唔涉寫入動作：純讀取，最壞情況都係出錯提示，唔會炒咗訂單
• 容錯率高：出咗錯你撳入 admin 一睇就知

最後提一句——Shopify token 唔好放雲端同步資料夾（iCloud / Dropbox），放本機 + macOS Keychain 最穩陣。Cowork 跑工作嗰部機，瞓著咗嘅時候排程就跑唔到，所以呢類每日 ops 要部機長開（或者用 server / 公司閒置嗰部 mac mini 跑）。