Excel 報表自動化實戰:n8n + Claude + Notion 三件套,把週報從 4 小時壓到 12 分鐘
n8n 跑流程、Claude 寫摘要、Notion 留版本。一家 38 人 B2B 公司的週報從 4 小時壓到 12 分鐘,月省 12.6 小時,建置兩週、月運行 1,420 元。
為什麼用 n8n + Claude + Notion 三件套(不是單一工具)
老闆常問:「Excel 報表自動化不就一個工具搞定嗎?買個 RPA 不就好了?」
我們在三家中小企業實作完才確認,單一工具做不到。每個工具負責一段,彼此分工,才跑得穩。
n8n 負責「流程骨架」:排程、抓檔、條件分支、錯誤重試
n8n 是流程引擎,不是商業邏輯引擎。它的工作是:每週一 09:00 觸發、去 Google Drive 抓 Excel、檔案不存在重試三次、處理失敗推 Slack 通知。
它不寫「為什麼這週業績下滑」這種判斷,那是 Claude 的工作。n8n 的價值在它不會抱怨重複跑、不會放假、不會把流程跑到一半忘記怎麼接下一步。
Claude 負責「語意處理」:讀數字、解讀差異、寫人話摘要
這段是傳統 RPA 解不開的卡點。RPA 可以幫你把兩個 Excel 合併、抓出環比差異欄位,但它寫不出「客服第三班的回覆時間從 12 分鐘拉到 28 分鐘,主要影響來自週四晚間 2 名新進客服尚在訓練」這種摘要。
Claude 讀得懂結構、抓得到異常、能寫出主管直接拿去看的人話。延伸看 Claude + MCP 的企業內部應用。
Notion 負責「結果留存」:版本、決策軌跡、跨部門分享
Notion 不是當資料庫用,是當「對話紀錄 + 決策軌跡」用。每週的摘要、主管留下的問題、後續處理動作都進 Notion DB。下次主管問「上個月那個異常後來怎麼處理?」,翻紀錄就能答。
不存進 Notion 的下場是,三個月後主管質疑某筆數字怎麼來的,你只能調原始 Excel 自己再算一次。
把三個工具混用是因為每個工具單獨做都會卡住:純 n8n 寫不出語意摘要、純 Claude 沒辦法排程、純 Notion 拉不到原始資料。
案例背景:38 人 B2B 公司的「週報痛點」
這家公司賣 SaaS 給中型製造業,客服團隊 6 人、每週要交一份「客服績效週報」給營運主管。
原本的 4 小時流程:客服匯出 → 自己合併 → 手填註解 → 寄給主管
每週一早上,客服主管做這 5 步:
- 客服系統匯出 3 份 Excel(進線量、回覆時間、滿意度)
- 用 vlookup 合併成主表
- 算每個欄位環比、和上月平均
- 寫一段 600 字的「本週重點 + 異常說明 + 下週重點」
- 寄信給營運主管 + 上傳到 Notion
整個過程 4 小時,通常從早上 09:00 跑到 13:00,中間還會被工程師打擾問客服系統 bug。
真正卡住的不是合併,是「每週寫差異註解」的 90 分鐘
我們去拆流程才發現,前 4 步加起來 90 分鐘,真正吃時間的是第 5 步「寫差異註解」。
主管要的是:「這週為什麼第三班的回覆時間突然變長?是離職、訓練、還是排班問題?」這種判斷需要看上週、上月、同期客戶投訴內容、值班表。
客服主管每週寫這段要 90 分鐘,而且寫久了內容會變制式,主管讀不到差異。
為什麼之前跑 RPA / Zapier 都失敗(語意層處理不了)
公司過去試過兩次自動化:
第一次用 UiPath 把前 4 步包成 robot,但 robot 寫不出第 5 步的人話摘要。最後客服主管還是要花 90 分鐘自己寫。
第二次用 Zapier 串 ChatGPT,結果 prompt 太鬆、每週風格不一致、有時連數字都會記錯。主管讀了三週就不信任了。
我們進來時,客服主管的話是:「不要再給我半套了。我要不省時間,要不就讓我繼續手做。」
三件套架構圖與資料流
整個 pipeline 五個階段:觸發 → 收檔 → 處理 → 寫回 → 失敗處理。每段對應一個或多個 n8n node。
觸發層:n8n cron(每週一 09:00)+ webhook 備援
主流程是 n8n 的 Schedule Trigger,設定週一 09:00 觸發。但客服系統有時會延遲到 09:30 才匯出檔案,所以另接一個 webhook,客服系統匯出完成後 ping n8n,跑同一條 workflow。
兩條入口共用後續節點,任一條跑成功就標記本週完成,不會重跑。
n8n 自架 vs 雲端的部署成本差異,可以參考 n8n 自架與雲端 2026 部署成本。
收檔層:n8n Google Drive node 抓客服匯出的 Excel + 簡單欄位驗證
n8n Google Drive node 用 service account 抓固定資料夾的當週 Excel,檔名規則 weekly-cs-{YYYY-MM-DD}.xlsx。
抓回來先做三個檢查:檔案大小 > 10KB(避免空檔)、必要欄位齊全(進線量、回覆時間、滿意度)、欄位資料型別正確(數字不是字串)。
任一檢查不過就跳到失敗處理層,不浪費 Claude 的 token。
處理層:Claude 透過 n8n HTTP Request node,吃當週 + 上週數據
n8n 把當週 + 上週的 Excel 都讀進來,用 Code node 抽出要比較的欄位,組成精簡 JSON。
然後 HTTP Request node 打 Anthropic API(https://api.anthropic.com/v1/messages),傳入 prompt + JSON 數據,回傳 markdown 格式的摘要。
整個 Claude 呼叫每週用約 8,500 tokens(input 6,200 + output 2,300),成本約 18 元台幣。
寫回層:Claude 回傳 markdown 摘要 → n8n 寫進 Notion DB → 推播 Slack
Claude 回傳 markdown 後,n8n 解析成 Notion DB 的欄位:
- 週次(2026-W19)
- 摘要(markdown 全文)
- 異常項(逗號分隔的關鍵字)
- 環比變化(百分比)
- raw payload(原始 JSON 連結到 R2 儲存)
寫完 Notion 後推 Slack,訊息含 Notion 頁面連結 + 摘要前 200 字。主管手機開 Slack 就能讀。
失敗處理:Notion 留 raw payload + Slack 通知人工介入
任一節點失敗,n8n 跳到 Error Trigger 子流程:把錯誤訊息 + 當下的 raw data 寫進 Notion 失敗紀錄 DB,推 Slack 給工程師。
這樣即使 workflow 跑壞,raw data 不會丟,可以人工接手寫摘要。
Claude prompt 設計關鍵:別丟整份 Excel 給它
很多人實作 Excel 自動化時,直接把整份 Excel 轉成 csv 餵 Claude,以為這樣最簡單。實際跑下去就會發現:tokens 翻三倍、模型抓不到欄位語意、有時連欄位順序都會記錯。
先用 n8n 把 Excel 轉成精簡 JSON(只留要比較的欄位 + 上週同期)
我們在 n8n 的 Code node 做這段預處理。Excel 原本 60 欄,實際週報需要的只有 12 欄。
轉成 JSON 結構大致長這樣:
{
"week": "2026-W19",
"previous_week": "2026-W18",
"metrics": {
"incoming_count": {"current": 1842, "previous": 1601, "change_pct": 15.1},
"first_response_min": {"current": 14.2, "previous": 12.1, "change_pct": 17.4},
"csat": {"current": 4.6, "previous": 4.7, "change_pct": -2.1}
},
"shift_breakdown": [
{"shift": "morning", "agents": 3, "incoming": 612, "first_response_min": 11.8},
{"shift": "afternoon", "agents": 2, "incoming": 824, "first_response_min": 13.5},
{"shift": "evening", "agents": 3, "incoming": 406, "first_response_min": 28.1}
],
"anomalies_hint": ["evening shift first_response_min +132% vs previous"]
}
token 用量從直接餵 Excel 的 ~28,000 降到 ~6,200,模型回應品質還更好。
prompt 三段:背景 + 數據 + 輸出格式
prompt 結構固定三段,不要混。背景講公司情境、產品、團隊規模;數據塞 JSON;輸出格式規定要 markdown、要分哪幾段、異常項用 ⚠️ 標出來。
固定結構的好處是每週風格一致,主管讀久了會習慣特定段落順序。
為什麼不直接餵 csv:tokens 翻倍、模型抓不到欄位語意
我們有實測過。同一份 Excel,直接餵 csv 和先轉 JSON 兩種跑法,結果是:
| 方式 | input tokens | output 品質 | 異常識別 |
|---|---|---|---|
| 直接餵 csv | ~28,000 | 段落混亂 | 漏 2/5 |
| 先轉 JSON | ~6,200 | 結構清楚 | 5/5 |
差異不是 Claude 變笨,是 csv 沒有欄位語意。模型看到 evening,3,406,28.1 和 {"shift": "evening", "agents": 3, "incoming": 406, "first_response_min": 28.1},後者一眼看出 28.1 是 first_response_min。
一段可直接搬走的 prompt 模板(含 placeholder)
下面這段是我們客戶在用的精簡版,你可以直接搬:
你是 {{COMPANY_NAME}} 的客服營運分析師,負責產出每週客服績效週報摘要。
# 背景
- 公司規模:{{TEAM_SIZE}} 人,客服 {{CS_TEAM_SIZE}} 人
- 產品:{{PRODUCT_TYPE}}
- 主管關注:回覆時間、進線量、滿意度
- 異常閾值:single metric 環比變化 > 15% 視為異常
# 數據(JSON)
{{METRICS_JSON}}
# 輸出格式(strict)
- 只輸出 markdown,不要前後加說明文字
- 結構 4 段:## 本週重點(3 行內)/ ## 異常說明(逐項) / ## 下週重點(2 行內) / ## 備註
- 異常項在開頭加 ⚠️
- 數字後面加百分比變化(例:回覆時間 14.2 分鐘 ⚠️ +17.4%)
- 不要寫「以下是分析」、「希望這份報告對您有幫助」這類客套話
placeholder 在 n8n 的 Set node 替換完再丟給 HTTP Request。
整套 workflow 的 node 化做法,延伸看 n8n + Claude Skills + MCP 的 workflow 節點化。Token 計費規則參考 Anthropic Claude API messages 文件。
真實成本與時間:兩週建好、月運行 1,420 元
老闆最在意的兩件事:多久能跑、每月要付多少錢。
建置成本:諮詢拆流程 1 週 + n8n flow 搭 3 天 + 校正 prompt 3 天
我們的建置順序固定:
- 第 1 週:跟客服主管把現行 4 小時流程拆細,確認哪 12 個欄位真正需要、主管最常問哪 5 個問題、什麼算異常
- 第 2 週前 3 天:在 n8n 搭觸發 + 收檔 + 預處理 + 寫回 4 個節點,先跑通空 prompt 流程
- 第 2 週後 3 天:用 4 週歷史數據校正 prompt,直到主管讀了第 3 週覺得「這就是我要的格式」
兩週是有經驗的人外包做,公司內部第一次做大概要 4 週。
每月運行:Claude API ~720 元、n8n cloud ~600 元、Notion 既有
每月實際支出:
| 項目 | 月費 | 說明 |
|---|---|---|
| Claude API(sonnet 4.6) | NT$720 | 4 週 × 約 18 元 = 72 元,加上失敗重試與其他 workflow 共用 |
| n8n cloud(Starter plan) | NT$600 | 5,000 executions/月,本案約用 200 次 |
| Notion | 0 | 公司既有授權 |
| Google Workspace | 0 | 既有 |
| 合計 | NT$1,320 | 加上 100 元雜項 buffer = NT$1,420 |
如果跑 self-hosted n8n(VPS NT$300/月)還能再省 300。
省下時間:每週客服 3.5 小時 + 主管 0.5 小時 = 月省 12.6 小時
客服主管每週省下 3.5 小時(原本 4 小時 → 12 分鐘檢查 + 微調),營運主管省 0.5 小時(原本翻 5 份 Excel → 直接讀摘要)。
每月 4.2 週,4 × 4 = 16 小時的客服主管時間,加上 2 小時的營運主管時間,合計約 18 小時。扣掉中間還是會出狀況需要人工介入的 5.4 小時(估每月 3 次小狀況 × 1.8 小時),淨省 12.6 小時。
6 個月回收線:NT$36,000 ÷ 月省 NT$8,820,約 4.9 個月回本
回收計算:
- 建置成本:NT$36,000(顧問費 + 公司內部協作時間)
- 月節省人力成本:12.6 小時 × 700 元/小時 = NT$8,820
- 月節省 - 月運行 = NT$8,820 - NT$1,420 = NT$7,400 淨節省
- 回收期:NT$36,000 ÷ NT$7,400 ≈ 4.9 個月
放寬成 6 個月內就回本。回看 自動化前後 ROI 怎麼算,這個案是「先省時間、後再算客單」的典型路徑。
90 天落地路線:先跑通一份報表再擴
很多公司一開始野心很大,想一次自動化所有報表。實作下來都失敗,因為各部門報表規則差異大,一次做完會卡在某幾份特例上,整個專案停擺。
D0~D14 找一份「每週都要做、規則不複雜」的報表先做
選題標準三條:每週固定要做(不是月報、季報)、欄位邏輯不會每月換、出問題不會立刻惹爆部門。
通常符合的有:客服週報、業務週報、產品使用週報。盡量挑一份就好,做完再擴。
D15~D45 加進主管最常問的 3 個比較欄位(環比、同期、警示閾值)
第一版上線後通常會收到主管「我希望也能看 X」的需求。挑最常問的 3 個加進去,不要全收。
通常是:環比(對比上週)、同期(對比去年同週)、警示閾值(連續 2 週超標就要紅標)。
D46~D90 把同模板擴到第二份報表,第三份用 self-service 範本給其他部門
第 45 天當第一份報表跑穩,複製整個 workflow 改 prompt 變數做第二份,通常 1 週搞定。
第 90 天時公司內已經有 2 份固定報表 + 一份模板。其他部門想做時,把模板給他們、教他們怎麼改 prompt 就好。
5 個踩坑清單:不要重蹈覆轍
我們做完三家公司後整理出 5 個常踩坑,提醒你避開。
坑 1:n8n self-hosted 沒設備份 → 一次重啟整套 workflow 沒了
解法:每週固定匯出 workflow JSON 進 Notion 留版本、git 倉庫,容器升級前先 snapshot。社群節點用法參考 n8n 官方文件 community node。
坑 2:Claude prompt 太鬆 → 摘要每週風格不一致
解法:在 prompt 裡寫 strict 輸出格式、定段落順序、列禁止用語。我們有客戶連「不要寫『綜上所述』」都列進去。
坑 3:把 Excel 整份貼進 prompt → tokens 暴衝
解法:n8n 一定先做欄位篩選 + JSON 化,只給 Claude 它真的要看的東西。一份 60 欄的 Excel 通常只用 10~15 欄。
坑 4:Notion DB schema 沒先設計 → 後期報表反查很痛苦
解法:第 1 週就把 schema 釘死,至少含週次、摘要、異常項、環比、raw payload 連結 5 個欄位。view 先設好(主管看的、團隊看的、稽核看的)。
坑 5:沒留 audit trail → 主管質疑數字無從驗證
解法:raw JSON 進 R2 / S3 留 90 天,Notion 紀錄裡放連結。任何「這個數字怎麼來」的質疑,都能 1 分鐘給答案。
如果你公司也有類似的痛點,週報、月報、客戶報表卡在「合併不難、寫摘要要命」這個段落,我們可以幫你拆。
預約 30 分鐘策略對話,我們會把你目前最痛的一份報表攤出來看,給你一份可帶回去自己列工作的清單。30 分鐘內,具體可量化的一步,不講虛的。
FAQ
Excel 報表自動化用 n8n + Claude + Notion 適合多大的公司?
20~150 人最甜蜜。低於 20 人通常報表頻率還沒固定、規則還在換,自動化會變成自綁手腳。高於 150 人通常已經有 BI 工具(Tableau / Power BI),那種情境下三件套是補 BI 工具寫不出語意摘要的那塊,不是取代。
建置兩週後可以自己維護嗎?
n8n flow 改不太需要動,主要要維護的是 Claude prompt。建議公司內找一個「對流程熟、會寫 markdown」的人(通常是業務分析或營運專員),花 4 小時跟我們做 prompt 微調訓練,之後就能自己改。每月平均要改 prompt 1~2 次,每次 30 分鐘內。
失敗了怎麼回退?
回退三層:
- 單週失敗:n8n Error Trigger 推 Slack,客服主管手動寫一份(就是回到舊流程)
- 整個 workflow 壞掉:Notion 還有上週版本,raw JSON 在 R2,可以重新跑單次
- Claude API 不可用:n8n 切到備援 prompt 模板(更短、純結構化),先撐過當週,主管收到「降級版摘要」標記