Cowork 每月 1 號自動出 SaaS founder dashboard：MRR / churn / cohort 一頁睇晒

情境

你係香港 indie SaaS founder，產品啱啱跑緊，每月有十幾單到幾十單 subscription。 每個月 1 號早上你會做同一件事：

• 開 Stripe dashboard，慢慢撳入唔同畫面
• 抄 MRR、新客、取消咗嘅單入一個 Google Sheet
• 用 Excel 公式計 churn rate、LTV、cohort retention
• 砌幾個圖表
• 寫一段月度檢視畀自己（有時順手 send 埋畀 advisor 或者 angel）

熟手都要兩個鐘。而且做到一半成日攰到唔想計 cohort，跳過咗，下個月又話「下次補返」——成年都冇補。

呢個工作嘅特徵：完全機械式、每月一次、資料來源同格式都唔變。 正正係 Cowork 嘅 sweet spot——你設定一次，佢每月 1 號 7am 自動跑，你 8am 起身就有份 dashboard 喺 inbox。

利益申報：Cowork 仲係 research preview，要 Pro/Max plan。 Stripe API key 等於你個荷包嘅總鎖匙——呢篇教你用嘅一定要係 restricted 唯讀 key，唔好用 secret key 或者全權限 key。 錯手用咗全權限 key 落一個 prompt 度，後果可以好嚴重。

跟住做

1. Stripe API key + Cowork 工作 folder

落 Stripe dashboard → Developers → API keys → Create restricted key。 權限淨係開：

• Charges: Read
• Customers: Read
• Subscriptions: Read
• Invoices: Read
• Products / Prices: Read

全部 Write 都唔好剔。 個 key 改名做「claude-cowork-readonly」，copy 個 key 出嚟（rk_live_... 開頭，唔係 sk_live_）。

開個 dedicated folder：

~/Documents/founder-dashboard/
├── .env                       ← Stripe key 擺呢度
├── 2026-05/                   ← 今個月嘅
│   └── (Cowork 生成嘅 dashboard)
├── templates/
│   └── dashboard-template.md
└── archive/                   ← 過往幾個月

.env 入面寫一行：STRIPE_API_KEY=rk_live_xxx。 呢個 folder 之後就係 Cowork 嘅工作範圍，唔好俾佢掂出面任何嘢。

2. 核心 prompt — 教 Claude 點計 SaaS metrics

呢個 prompt 比較長，因為 SaaS 指標嘅定義要寫死，唔好等 Claude 自己估。

我係 solo SaaS founder。 我想設定每月 1 號朝早 7 點自動跑一次嘅 founder dashboard。工作 folder： ~/Documents/founder-dashboard/
Stripe key： 由 .env 讀 STRIPE_API_KEY（restricted 唯讀 key）
今個月 folder： 2026-MM/（用上個月嘅年月）流程：第一步：用 Stripe API 拉上個月嘅資料
所有上個月 customer.created 嘅 customers
月頭同月尾兩個時間點嘅所有 active subscriptions snapshot
上個月所有 invoice.payment_succeeded
上個月所有 customer.subscription.deleted（churn 事件）
第二步：計核心 SaaS 指標
MRR（月底 snapshot）：所有 active monthly subscription 嘅 sum；yearly 嘅除 12
ARR：MRR × 12
New MRR：上個月新增 subscription 帶嚟嘅 MRR
Churned MRR：上個月取消嘅 subscription 失去嘅 MRR
：New − Churned

3. Output format + delivery

Cowork 出嘅 markdown 可以有兩個落腳點，揀一個（或者兩個都做）：

• Notion：開個 database 叫「Founder dashboards」，每月一條記錄，title 用「2026-MM」。 Cowork 可以直接寫入（要 Notion integration）。
• Email：最簡單，直接 send 去你自己個 inbox，加 label 「founder-dashboard」歸類。

如果想睇趨勢圖，可以再多一步：叫 Cowork 將指標表同時加落一個 Google Sheet，到時圖表由 Sheet 出。 圖表唔好喺 markdown 入面砌——出嚟好醜，而且 Cowork 砌圖表容易出錯。

4. Schedule + first-month sanity check

第一次跑唔好即刻排程。 叫 Cowork：「即場用上個月嘅資料跑一次，唔好 email 我，喺 chat 度 show 我出嚟」。

你要逐項核對：

• MRR：開 Stripe dashboard → Billing → MRR view，對比 Cowork 計嘅數啱唔啱（差 < 1% OK，差 > 5% 一定有問題）
• Churn：揾返上個月取消咗嘅 customer，自己數一次
• Cohort：揀一個你記得嘅 cohort（例如三個月前），睇下 retention 啱唔啱
• 公式：睇 report 底嗰啲公式，會唔會將 yearly subscription 當成 monthly（呢個係最常見嘅錯誤）

第一個月嘅 dashboard 唔可以盡信。 跑完第二第三個月，數對得返 Stripe，先當佢穩定。 然後先啟用排程。

變化

變化 1：唔用 Stripe，用 LemonSqueezy / Paddle / Gumroad

（同主 prompt 一樣，但改）：
API 來源換成 LemonSqueezy API（唯讀 key）
LemonSqueezy 已經幫你計咗部分指標（dashboard 有 MRR / churn），但 cohort retention 同 LTV 仲係要 Claude 自己計
Subscription status 嘅 enum 名唔同（LemonSqueezy 用 active / on_trial / cancelled / expired）—— Claude 要識區分
Webhooks 嘅 event 名都唔同——但因為我哋係月底 snapshot，唔靠 webhook，問題唔大
Paddle 同 Gumroad 同理，叫 Claude 一開始確認你個平台嘅 API endpoint 同 field 名。

變化 2：加 product analytics data merge

（喺主 prompt 第二步同第三步中間加）：第 2.5 步：由 PostHog API（或者 Plausible）拉上個月嘅產品使用數據
DAU / WAU / MAU
Activation rate（你定義嘅核心動作）
邊個 feature 最多人用
第 3.5 步：將 Stripe 嘅 customer ID 同 PostHog 嘅 user ID 配對（假設你有將 distinct_id 設成 stripe customer id）
計返「paying customer 嘅參與度」：佢哋上個月有冇用過個產品
標示高 churn 風險：付緊錢但 30 日冇登入
呢個版本特別有用：淨睇 revenue 指標，望唔到 customer 緊唔緊張你個產品。 一個 paying customer 三十日冇登入 = 下個月好可能流失。

變化 3：Weekly 版本（每星期一 9am 跑簡化版）

我想加多一個每週一 9am 嘅輕量版本（除咗月度 dashboard 之外）。每週版只需要：
過去 7 日 new MRR
過去 7 日 churned MRR
過去 7 日嘅新客（連名單）
過去 7 日取消咗嘅 customers（連名單同取消原因，如果 Stripe 有 metadata）
同上週對比
唔需要 cohort、唔需要 LTV、唔需要文字段落。
直接 email 落我 inbox，subject：「Weekly pulse — week of 2026-MM-DD」。呢個係輕量嘅「脈搏」，畀我每週一返工前掃一眼就知個產品健唔健康。

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

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

呢套流程最唔老實嘅地方係：demo 一次對得到 Stripe，唔代表每個月出嚟嘅數都係真嘅。計 SaaS 指標有幾個位特別容易靜悄悄出錯，你唔逐月核對係唔知嘅：

1. Yearly subscription 冇除 12，MRR 即刻虛高 Stripe 入面，月付同年付都係 active subscription。年付嘅 amount 係全年金額，唔係月份金額。Claude 明白你嘅計算公式，但如果 API 返嚟嘅 billing_interval 唔係逐筆都係 month，佢有機會將年付直接加埋 MRR，而唔除 12。

• 會爆成點：你嘅 MRR 一夜之間暴升，ARR 虛高十倍，你以為業務大躍進——其實係計漏咗。
• 點救：prompt 明確指示「billing_interval = year 嘅 subscription，金額除 12 先計入 MRR，並喺 report 底列出有幾多張年付單」；第一次跑完，自己落 Stripe 數一數年付客有幾多張，交叉核對。

2. Stripe API 分頁截斷，大帳戶嘅 cohort 唔完整 Stripe API 每次 call 預設返 100 條記錄，超過就要翻頁（has_more: true + starting_after）。如果你有超過 100 個 active customers，或者某個月嘅 invoice 超過 100 張，Claude 可能只處理咗第一頁，剩低嘅靜悄悄唔見咗。

• 會爆成點：Cohort table 嘅 customer 數目比 Stripe dashboard 少；churn rate 偏低（因為部分 customer 冇被統計）；MRR 亦可能偏低。早期帳戶客少唔明顯，一增長就中招。
• 點救：prompt 加一句「每個 API call 必須翻頁直到 has_more 返 false，唔好淨取第一頁」；跑完核對 total active customers 數字啱唔啱 Stripe 嘅 Customers 頁面。

3. 同一個 customer 同月取消再重開，churn 計多咗 有 customer 取消咗、但幾日後又重新 subscribe（例如改咗 plan、信用卡問題解決）。Claude 係按 event 計，subscription.deleted 事件係一個 churn，但佢喺同月又出現喺 active subscription 入面。視乎 prompt 點寫，可能同時計入 churned customer 同 new customer，淨係出一個人做兩個故事。

• 會爆成點：logo churn rate 虛高；net new MRR 計法出錯；cohort retention 將呢個人計成「流失再重啟」而唔係「留低」，cohort 表扭曲。
• 點救：prompt 加「同一個 customer.id 喺同一個月內既有 subscription.deleted 又有 subscription.created，視為 reactivation，唔計入 churn，另外標示」。

4. LTV 公式喺 churn 率低嘅時候出天文數字 Prompt 用嘅 LTV = 1 ÷ monthly_churn_rate × ARPU，呢條公式假設客戶係以固定比率離開（幾何分佈）。早期 founder 最易出現嘅情況係：某個月 churn rate 係 0.5%，計出嚟 LTV 係 ARPU × 200——聽落好正，但呢條公式喺 churn 率極低時係高度不穩定嘅估算，一兩個客走咗 churn rate 就可以跳一倍。

• 會爆成點：你拿住呢個 LTV 數字去融資或者做 unit economics，investor 問起計法，答唔到；或者 churn rate 一個月 0.5%、下個月 1%，LTV 差一倍，你以為業務急劇惡化。
• 點救：prompt 已寫咗「LTV 係估算值，要 founder 確認」——自己記住唔好過份依賴呢個數字；如果 churn rate 低過 1%，睇 cohort retention 比睇 LTV 更可靠。

5. API key 出現喺 Cowork chat 記錄，等同明文儲存 Prompt 叫 Cowork 由 .env 讀 key——但如果 Cowork 喺某個步驟喺 chat 介面 print 出 API key（例如 debug 時顯示「讀到 key：rk_live_...」），個 key 就會儲落 conversation history 度。Cowork 係 Anthropic 基礎設施，但你自己都唔應該讓 secret 出現喺 chat 介面。

• 會爆成點：conversation 記錄被 export、截圖、或者 Claude.ai 用嚟做 training（視乎你嘅 privacy 設定），key 就唔再係 private。
• 點救：prompt 明確寫「唔好喺任何輸出或 debug 訊息度列印 API key 或任何部分」；定期喺 Stripe 落去 rotate key（尤其係頭幾次測試跑完之後）；.env 放落 .gitignore，唔好 commit 落 repo。

呢幾個位，就係「第一次跑靚仔、inbox 有 dashboard」同「個數可以拿出去見 investor 或者做決策」之間嘅距離。

Solo founder 最易犯嘅錯：每月 1 號好認真做 dashboard，第三個月開始懶，第五個月直接放棄，到 fundraising 或者第十個月先回頭執——但嗰陣 cohort 數據已經斷咗。 自動化嘅價值唔係慳嗰兩個鐘，係幫你冇得偷懶。 個 dashboard 每月 1 號 7am 一定喺 inbox，你睇唔睇就你嘅選擇——但起碼數據唔會斷。