Make.com 自動化教學完整指南：6 個中小企業實戰場景 + 4 個 vs n8n / Zapier 選型決策 + 3 個收費區間

你確定你需要 n8n 嗎？對中小企業老闆來說，Make.com（前身 Integromat）可能反而是更便宜、更快上手的起點。

最近我們在自家內部盤點 20+ 個 AI 流程的時候發現一件事——並非每條流程都需要 n8n 那種「程式碼介入彈性」。有幾條跑得最穩、最不需要工程師維護的，反而是用 Make.com 那種「視覺化拖拉場景」做出來的。我們團隊內部主力跑 n8n（self-host、控制權高、長期省錢），但客戶第一次導入自動化、或業務跟行銷自己想跑、不想等 IT 排程的場景，我們會直接推 Make.com。

這不是「Make.com 比 n8n 好」的結論——是「中小企業選自動化工具，先看自己卡在哪、團隊長什麼樣，再決定走 self-host 還是 SaaS」。這篇我們把過去半年看過、跑過、聽過的 Make.com 用法整理成 6 個中小企業實戰場景 + 4 個 vs n8n / Zapier 選型決策 + 3 個收費區間，幫你在動手前先把判斷做完。本篇是 N8N vs Make vs Zapier 完整比較 的延伸——那篇講「三家整體差異」，這篇深入講「Make.com 本身怎麼用、跟誰比、怎麼選」。

有一個數字很值得注意——根據 Gartner 2024 年的自動化採用調查，全球 60% 以上的中小企業自動化專案是由「業務 / 行銷 / 營運部門」自己發起的，而非 IT。這個趨勢直接決定了 Make.com 在中小企業的位置——核心使用者就是「會用 Excel、但不會寫程式」的部門主管，而工程師反而比較少用它。

為什麼中小企業老闆每天都在「重複貼資料」？

PTT Soho 板、Dcard 創業板、Facebook 中小企業社團三天兩頭都有同一類抱怨：

• 「客戶填了表單通知不到業務，每天要手動截圖丟 LINE 群」
• 「Shopify 訂單要手動 key 進 ERP，月底對帳對到崩潰」
• 「Email 收的客訴沒人分派，週末爆炸才發現」
• 「FB 廣告跑了結果報表要自己每週 export 整理，老闆每個禮拜一抓狂」
• 「Google Form 報名後，要手動寄確認信、加進 Google Calendar、通知主辦人——一場活動要做三次」

這些都是「工具有了、人也在做、但沒串起來」的典型症狀。在我們的 AI 顧問經驗中常聽到客戶問：「我已經用了 7 套 SaaS（Shopify、HubSpot、Slack、Notion、Google Workspace、ChatGPT、LINE OA）——為什麼員工還是在做手動搬運？」答案幾乎都一樣：選工具的時候沒人想過「資料怎麼在工具之間流動」。

這就是 Make.com 的位置——它不取代你現有的 SaaS，而是當「資料搬運工」。它每分鐘檢查一次 A 工具有沒有新事件，有就觸發一連串動作把資料推到 B、C、D 工具。聽起來很簡單，但對「不會寫 API」的老闆和員工來說，這層「視覺化拖拉場景」就是把「程式設計」變成「畫流程圖」的關鍵。

Make.com 怎麼運作？場景、模組、操作數三個關鍵詞

Make.com 的核心概念只有三個，搞懂這三個你就會用了：「場景（Scenario）」、「模組（Module）」、「操作數（Operation）」。

場景（Scenario）= 一張流程圖

一個場景代表一個自動化流程。例如「Shopify 新訂單 → 寄信給業務 → 加進 Google Sheets → 通知 Slack」這整條鏈就是一個場景。每個場景都有一個「觸發器」（trigger，例如新訂單）+ 多個「動作」（action，例如寄信、新增列、發訊息）。

模組（Module）= 場景裡的每個節點

每個 SaaS 在 Make.com 裡都有對應的「app」，每個 app 有多個「模組」對應不同動作。例如 Shopify app 有「Watch new orders」（觀察新訂單）這個觸發模組，也有「Update order」（更新訂單）這個動作模組。Make.com 目前支援 1,800+ app 整合——主流的 Shopify、HubSpot、Google Workspace、Slack、Notion、Airtable、Stripe、LINE、ChatGPT 都在。

操作數（Operation）= Make.com 的計費單位

這是最容易踩坑的概念。Make.com 的計費單位是「每個模組執行一次算一個 operation」，並不是按「執行次數」整條計費。例如「Shopify 觸發 → 寄信 → 加進 Sheets → 通知 Slack」這條鏈跑一次，會消耗 4 個 operations（觸發本身也算 1 個）。如果你一個月 1,000 筆訂單，這條鏈就吃掉 4,000 個 operations。

這個計費模型對「流程簡單但頻率高」的場景很友善（例如訂單通知），對「流程複雜但頻率低」的場景反而吃虧（例如月底跑一次的大型對帳，可能一次跑掉幾萬個 operations）。後面講收費的時候會再展開。

Make.com 的 6 個中小企業實戰場景

這六個場景是我們過去半年看過實際在跑、回收效益清楚、且新手能在 2 小時內自己拉出來的。順序依照「實作門檻由低到高」排列。先看下面這張對照表抓重點，再讀各場景細節。

場景一：Google Form 報名自動寄確認信 + 加進日曆

適合：辦活動、線上講座、預約服務的小團隊。流程：Google Forms「新回應」→ Gmail 寄確認信（含活動資訊）→ Google Calendar 新增事件並邀請對方 → Slack/LINE 通知主辦人。一場活動可以從「手動處理 30 分鐘 / 場」降到「報名完，所有人都收到該收的東西」。

Operation 消耗：每筆報名約 4 ops。月 200 筆報名 = 800 ops，Free 方案（1,000 ops/月）剛好接得住。

場景二：Shopify 新訂單自動進 Google Sheets + 通知業務

適合：用 Shopify 但還沒導入 ERP 的電商小團隊。流程：Shopify「新訂單」→ Google Sheets 新增列（訂單編號、金額、客戶、地址）→ Gmail 寄客製化「我們已收到您的訂單」感謝信 → Slack 通知客服 channel。

這條鏈的關鍵價值其實是「資料留下來了」，省時間反而是次要的。很多電商老闆到月底才發現「Shopify 後台看訂單很方便，但要做行銷分析、看上月成長、跨平台對帳——資料散在 5 個地方」。把訂單即時寫進 Sheets，就有了一個「總帳」，後面要接 GA4、要做廣告 ROAS 分析、要算客單價，都好辦。

場景三：LINE OA 訊息自動轉客服票單

適合：用 LINE OA 接客戶，但客服人員看不過來的服務業。流程：LINE OA「新訊息」→ ChatGPT（OpenAI 模組）分類訊息類別（詢價 / 客訴 / 一般詢問）→ 根據類別寫進 Notion 客服 database → 通知對應同事。

這條鏈的精華是「中間插一個 ChatGPT 模組做語意分類」。同樣的訊息「請問可以退貨嗎？」傳統規則匹配可能會漏，丟給 GPT-4o-mini 一次（成本約 $0.0002）就能準確分類成「客訴 / 退貨」。Make.com 的 OpenAI 模組可以直接拉，不用寫一行程式。

場景四：Email 收到附件自動歸檔 + OCR + 寫進 Notion

適合：每天收很多供應商發票、客戶報價、會議紀錄的小公司。流程：Gmail「收到指定標籤的信」→ 下載附件存進 Google Drive 指定資料夾 → OCR 模組（Make.com 有內建文字辨識 app）擷取金額和日期 → 寫進 Notion 財務 database。

這條鏈跑起來的價值是「會計小姐不用再人工 key in」。對 10-30 人的中小企業，月底對帳通常會吃掉行政 1-2 個工作天。OCR + Notion 自動化下來，可以把那 1-2 天壓到 2-3 小時抽查。

場景五：Stripe 訂閱續約失敗自動寄催繳信 + 通知財務

適合：賣訂閱制 SaaS / 線上課程 / 會員服務的團隊。流程：Stripe「訂閱續約失敗」→ 透過 OpenAI 模組生成客製化催繳信文案（依用戶分級用不同語氣）→ Gmail 寄出 → 寫進 Airtable 追蹤 → Slack 通知財務。3 天後若仍未付，再寄一封；7 天後自動暫停訂閱。

這條鏈是「dunning（催繳）自動化」，國外 SaaS 圈標配。台灣中小企業很少做，但對訂閱制業務、每流失 1% 月經常性收入（MRR）都是真實的錢，導入回收期通常 2-3 個月。

場景六：FB 廣告報表每週自動匯整 + GPT-4 寫摘要 + 寄給老闆

適合：自己投廣告的中小企業老闆，或代理商每週要做客戶報告。流程：Schedule（每週一 9:00）→ Meta Ads（撈上週數據）→ Google Sheets（追加列存歷史）→ ChatGPT GPT-4o（產生「上週表現 + 建議調整」摘要）→ Gmail 寄給老闆 + 業務群。

這條鏈把「行銷主管每週花 2 小時做報表」這件事壓到 0。但要注意——GPT 寫的摘要會「太樂觀」，建議在 prompt 裡明確要求「列出 3 個需要立刻處理的問題」，不要寫成「整體表現良好」這種廢話。

這六個場景的共同點是：起點都不是「我們公司要全面數位轉型」這種大方向，而是「業務 / 行銷 / 客服 某個具體的痛」。在我們服務 30+ 企業客製案落地的經驗中，看過最容易導入自動化的都是這種「小場景、清楚邊界、看得到 ROI」的入口；反過來最容易失敗的，是老闆想「一次把整個訂單流程自動化」的大爆炸式專案。如果你還在想「先從哪一條開始」，可以參考我們另一篇 3 個 N8N 案例分享（Email 陌生開發、客服助理、人資發薪） 找靈感——那篇講的是 n8n，但場景設計邏輯一模一樣。

Make.com 的天花板在哪裡？什麼時候該升級到客製化系統

我們認為 Make.com 對中小企業是「最划算的第一步」，但它不是萬靈丹。在我們做 AI 落地實戰諮詢的經驗中，看過至少 5 種「Make.com 做到一半撞牆」的情況——撞牆的點通常不在工具本身，是在「業務流程的複雜度跨過某個閾值」。

訊號一：操作數爆炸

如果你的場景每月吃 50,000+ operations，月費已經上看 $100 美元/月，這時候 self-host n8n（VPS 月費 $20 + 自己維護）就會更划算。算式很簡單：Make.com Teams 方案 $29/月送 10,000 ops，超過要加購；自架 n8n 只要伺服器撐得住就 unlimited。

訊號二：流程複雜到 router 超過 5 層

Make.com 的 router（分流）和 aggregator（聚合）超過 5 層後，視覺化反而變累贅——你會發現「我用 Make 拉這個流程要 30 分鐘，寫 Python 只要 5 分鐘」。這時候轉向客製化系統（或自架 n8n + 加自己寫的 webhook）更合理。

訊號三：要做「跨資料庫複雜 join 或業務邏輯」

例如「訂單金額 > 10 萬 + 客戶過去 6 個月有 3 筆以上訂單 + 該客戶所屬產業是製造業 → 觸發 VIP 客戶流程」這種需要 SQL join 多張表的判斷，Make.com 雖然做得到但會很笨重。這時候不如把流程切兩半——用 Make.com 處理「資料搬運」，業務邏輯部分串到自己的 backend（或我們的 客製化系統開發）來處理。

訊號四：要符合台灣資安 / 個資 / 醫療法規

Make.com 資料中心在歐美，所有資料流經第三方雲端。對需要符合台灣 個資法 或醫療資料保護的業者，這是硬傷。這類客戶我們建議直接走客製化 + self-host n8n on 台灣機房的組合，從第一天就把合規問題鎖死。

訊號五：自動化變成「公司核心競爭力」

如果你做的事情，自動化流程本身就是賣點（例如做行銷代操，「我們有獨家自動化報表」是賣給客戶的）——這時候卡在 Make.com 的視覺化框框裡，等於把你的核心 IP 鎖在 SaaS 上。一旦 Make.com 漲價、改條款、或更糟的下架某個 app，你會非常痛。這時候自架 n8n 或客製化系統才是長期解。

Make.com vs n8n vs Zapier：4 個選型決策框架

這三家是 2026 年中小企業自動化工具的三大主流。我們的判斷是——沒有「全面最佳」，只有「適合你目前狀況的」。先用下面四個決策維度看自己卡在哪，再決定走哪條路。

決策一：你的團隊有沒有工程師願意維護？

有 → n8n（self-host 長期最便宜，且能跑進階流程）。沒有 → Make.com 或 Zapier。這個分歧點是 80% 中小企業最該先回答的問題。「我們公司沒工程師但想長期省錢」這種想法是陷阱——沒人維護的 self-host 系統一年內崩潰的機率比省下來的成本高得多。

決策二：你的「流程」是高頻簡單還是低頻複雜？

高頻簡單（例：每天 1,000 筆訂單通知） → Zapier 反而會貴爆炸，選 Make.com 或 n8n。低頻複雜（例：月底跑一次的大型對帳） → Make.com operation 計費會爆，選 n8n（自架）或 Zapier（單筆便宜但條件複雜）。

決策三：你的資料能不能離開台灣 / 離開公司？

可以 → Make.com / Zapier / n8n Cloud 都行。不行（個資、醫療、財務、政府標案） → 只能 n8n self-host on 台灣機房，或客製化系統。這是「能用 vs 不能用」的硬限制，不是「方便 vs 不方便」。

決策四：你最熟悉的是哪個 SaaS 生態系？

Google Workspace 重度用戶 → Zapier 最快（整合最全，但你也可以考慮 Google Apps Script（n8n 教學裡有對照） 直接在 Google 內處理）。Shopify / Stripe / SaaS 重度用戶 → Make.com 視覺化最直觀。Notion / Airtable 重度用戶 → n8n 對這類「資料庫導向」的整合最深。

我們的看法是——這三家其實是不同需求的工具，吵「誰最好」沒意義。如果一定要給結論：「中小企業老闆 + 沒有 IT 團隊 + 想 1 個月內看到自動化效益」→ Make.com。「工程師團隊 + 想長期省錢 + 願意花一週學節點式邏輯」→ n8n。「完全沒接觸過自動化 + 只想串 Gmail + Slack + Trello」→ Zapier。

Make.com 收費怎麼看？3 個區間 + 避坑指南

Make.com 的收費邏輯有 2 個獨立軸：「方案等級」決定功能（多少場景、多少資料保留天數、有沒有 team feature），「operations 用量」決定變動成本。先把方案盤清楚，再看真實用量。

區間一：月用量 < 5,000 ops（小型團隊試水溫）

選 Free 或 Core（$9/月）。這個區間最常見的場景是「1 個老闆 + 2-3 個員工 + 3-5 條簡單場景」，例如「Google Form 自動回信」「Shopify 訂單通知」「Stripe 收款通知」這類。月成本 < $300 TWD，回收期 1 個月。

區間二：月用量 5,000–50,000 ops（中小企業主力區）

選 Pro（$16）或 Teams（$29）。這是台灣 10-50 人中小企業最常見的位置。月成本 $500-$1,000 TWD，配合 5-15 條場景，通常每月省下 1-2 名行政人力工時（折算約 $15,000-$30,000 TWD）。

區間三：月用量 50,000+ ops（要重新思考架構）

這個區間就要算清楚了。Make.com Teams 方案 $29/月送 10,000 ops，每多 10,000 ops 加購 $9——你跑 50,000 ops 就是 $29 + 4×$9 = $65/月，跑 200,000 ops 是 $200/月。同樣的用量，自架 n8n 在 DigitalOcean 一台 $24/月 VPS 上就能跑，差價 8 倍。

Make.com 跑不動之後：客製化系統升級的 3 種路徑

假設你照前面的步驟跑了 3 個月，Make.com 已經吃了 30,000+ ops、5 條場景在跑、團隊也習慣了「資料會自動流」這件事。接下來會發生 3 種情況之一——

路徑一：流程穩了、但成本爬上來 → 遷移到自架 n8n

最常見的演進路徑。把現有 Make.com 場景一條一條搬到自架 n8n（一台 $20/月 VPS 撐 50,000+ ops 沒問題），第一週通常會發現「以前 30 分鐘拉的場景，n8n 要 1 小時」——但長期看，每月省 $50+ USD、且 IP 完全在自己手上。我們的 5 分鐘學會 N8N 教學 講的是 n8n 基礎用法，跟 Make.com 的概念對得起來，遷移時可以照著走。

路徑二：業務複雜度爆炸 → 部分流程客製化

例如「訂單處理」這條流程從一開始的「通知業務」演進成「判斷 VIP → 走加急通道 → 串 ERP → 串財務系統 → 串會計報表」——這時候自動化工具已經吃力，該把這條流程從 Make.com 抽出來，做成一個獨立的客製化系統，把 Make.com 留給其他輕量場景。

路徑三：自動化變成公司資產 → 整套打包成內部平台

這是最進階的演進。當你有 20+ 條自動化在跑、團隊已經養成「先想自動化」的習慣、流程開始有自己的版本管理需求——這時候會需要一個內部「自動化平台」，可能是自架 n8n + 客製化 dashboard + 監控告警 + 內部文件 portal 的組合。我們在 30+ 企業客製案的經驗中看過 3-4 家走到這一步，省下來的人力成本通常超過 1 名全職員工 / 年。

我們在做 AI 系統開發 跟 客製化系統開發 諮詢的時候，最常遇到的就是「Make.com 用了一年，現在要升級」的客戶——所以我們把「先 Make.com、再 n8n、再客製化」當作中小企業自動化路徑的標準建議。延伸閱讀：本站 2026 企業 AI 自動化完整指南（從工具選擇到落地實施的整套思路）和 中小企業如何用 AI 自動化省下 50% 人力（5 個真實場景拆解）兩篇可以幫你把策略面想清楚。

如果你公司每天都有人手動把資料從一個系統搬到另一個系統、客服一週要把同樣的問題回十遍、月底報表還是得靠人工整理——這三件事裡中了兩件，我們會建議你先停下來，用 Make.com（或 n8n）把最痛的那一條流程先跑起來。可以把你現在的情況丟過來，我們陪你看哪一塊最值得先動。

Make.com 自動化常見問題（FAQ）

Make.com 對中小企業的價值不在「省了多少時間」這個表面數字——它真正的價值是「讓你看清楚自己公司的資料怎麼流動」。當你開始用視覺化的方式把訂單、客戶、報表、通知串成一條鏈，你會第一次清楚地看到「我們公司其實是一個資訊處理系統，而不只是一群人 + 7 套 SaaS 的拼湊」。這個視角轉換，比省下來的時薪重要 10 倍——它是中小企業老闆從「員工執行者」變成「系統設計者」的起點。