畢業專題小札記07：最適合夜市攤商的試算表 CRM 系統成本分析：100-1500 單／天最低竟只要 800 元

既然我的專題核心目標是要為微型商家打造一個低成本、簡單易用的 CRM 系統，我最好還是做個成本分析，來證明它確實有達到這個目標。

之前沒跟到這個系列的話，可以從畢業專題小札記01：利用 LINE 和 Google 試算表建立微型商家 CRM 與點餐系統開始看。

前提

系統只計算 RFM 和 CAI。
每筆訂單一定發送 1 則 LINE 通知（例如：訂單完成通知，目前尚無此功能，先加進去保留）。
另有分群行銷推播（依攤位規模不同，頻率不同）。
沒有使用到 AI 的功能（如自動生成信件等）。

攤位規模定義

攤位規模	細分	訂單量
小攤	偏冷門	100～200 單／天
中等熱門	低	300 單／天
中等熱門	高	600 單／天
超熱門	中	800 單／天
超熱門	高	1,500 單／天

LINE 官方帳號

LINE 官方帳號的成本資訊主要參考自 https://blog.cresclab.com/zh-tw/line-oa-price-2023。

一對一聊天

LINE 官方帳號聊天方案功能一覽表，取自 https://blog.cresclab.com/zh-tw/line-oa-price-2023

群發訊息與 Messaging API

比較項目	輕用量方案	中用量方案	高用量方案
固定月費	0 元	800 元	1,200 元
免費訊息則數	200 則	3,000 則	6,000 則
加購訊息費用	不可加購	不可加購	0.2 元/則起降

我們發信功能的成本主要是看這個表。

Google Apps Script

Google Apps Script 的限額資訊來自 https://developers.google.com/apps-script/guides/services/quotas?hl=zh-tw，Google Workspaces 的定價資訊則是依據 https://workspace.google.com/intl/zh-TW/#pricing。

	免費	付費（Workspace，最低 7 美元/月）
寄信	100人／天	1,500人／天
觸發器	90 分鐘／天	6 小時／天

免費

付費

（Workspace，最低 7 美元/月）

寄信

100人／天

1,500人／天

觸發器

90 分鐘／天

6 小時／天

此專案主要觸發器使用情況

我先用「夜市單一攤位」最常見的點餐流程，把一天大概會發生多少次操作拆開估算（4 種觸發對應到不同動作）。

下面是我用 ChatGPT 生成的對應假設：

onEdit：約1秒／次，店員在表單／試算表改某個欄位（例如備註、數量、訂單狀態）。
installableTriggerOnEdit：約3秒／次，同上，但裝了觸發器做更多事（計算RFM、CAI）。
doPost：約10秒／次，送出一筆訂單（客人按「送出」／店員改訂單狀態）。
doGet：約2秒／次，開頁面／查訂單狀態／刷新（客人或店員看訂單頁）。

把「每單會觸發幾次操作」拆解

我用常見的操作頻率來估：

A) 每筆訂單（doPost）

1 次／單（送出就一次）→ doPost ≈ 訂單數

B) 每筆訂單狀態更改（onEdit / installable onEdit）

通常一筆單至少會改狀態 2 次：已接單 → 製作中 → 已完成／已取餐。

所以我抓：

狀態更改：2～3 次／單。

另外還可能有：

更改內容（加辣/去蔥/加料/取消）：0～0.3 次／單（看攤位類型）。

保守版：onEdit、安裝型 onEdit 合計 2 次／單。
忙碌版：合計 3 次／單。

同時有 onEdit 與 installableTriggerOnEdit，編輯一次會兩個都跑

所以一次編輯可能同時算 1 次 onEdit + 1 次 installableTriggerOnEdit。

C) 查詢／刷新（doGet）

這個最浮動：客人一直刷、店員一直看，都會增加。

常見抓法：

2～6 次／單。

1) 小攤：100 ～ 200 單／天

觸發器	最保守（100 單；每單編輯 2 次；每單查詢 2 次）	最忙碌（200 單；每單編輯 3 次；每單查詢 6 次）
doPost	100 × 10s = 1,000s = 16 分 40 秒	200 × 10s = 2,000s = 33 分 20 秒
onEdit	200 × 1s = 200s = 3 分 20 秒	600 × 1s = 600s = 10 分 00 秒
installable onEdit	200 × 3s = 600s = 10 分 00 秒	600 × 3s = 1,800s = 30 分 00 秒
doGet	200 × 2s = 400s = 6 分 40 秒	1,200 × 2s = 2,400s = 40 分 00 秒
總時間	2,200s = 36 分 40 秒	6,800s = 1 小時 53 分 20 秒

2) 中等熱門：300 ～ 600 單／天

觸發器	最保守（300 單；編輯 2 次；查詢 2 次）	最忙碌（600 單；編輯 3 次；查詢 6 次）
doPost	300 × 10s = 3,000s = 50 分 00 秒	600 × 10s = 6,000s = 1 小時 40 分 00 秒
onEdit	600 × 1s = 600s = 10 分 00 秒	1,800 × 1s = 1,800s = 30 分 00 秒
installable onEdit	600 × 3s = 1,800s = 30 分 00 秒	1,800 × 3s = 5,400s = 1 小時 30 分 00 秒
doGet	600 × 2s = 1,200s = 20 分 00 秒	3,600 × 2s = 7,200s = 2 小時 00 分 00 秒
總時間	6,600s = 1 小時 50 分 00 秒	20,400s = 5 小時 40 分 00 秒

3) 超熱門：800 ～ 1,500 單／天

觸發器	最保守（800 單；編輯 2 次；查詢 2 次）	最忙碌（1,500 單；編輯 3 次；查詢 6 次）
doPost	800 × 10s = 8,000s = 2 小時 13 分 20 秒	1,500 × 10s = 15,000s = 4 小時 10 分 00 秒
onEdit	1,600 × 1s = 1,600s = 26 分 40 秒	4,500 × 1s = 4,500s = 1 小時 15 分 00 秒
installable onEdit	1,600 × 3s = 4,800s = 1 小時 20 分 00 秒	4,500 × 3s = 13,500s = 3 小時 45 分 00 秒
doGet	1,600 × 2s = 3,200s = 53 分 20 秒	9,000 × 2s = 18,000s = 5 小時 00 分 00 秒
總時間	17,600s = 4 小時 53 分 20 秒	51,000s = 14 小時 10 分 00 秒

雲端伺服器（部署 LIFF App 和 Go 後端）

雖然我自己有伺服器（使用家裡舊電腦），但為了穩定性和載入速度，這個專案我決定使用雲端伺服器。

Oracle Cloud Infrastructure 有推出 OCI Cloud Free Tier 方案，只要不超過它的上限，就完全免費。

https://www.oracle.com/tw/cloud/free/

我用的配置是：4 個 ARM Ampere A1 運算執行處理 （每個月 3,000 個 OCPU 小時和 18,000 GB 小時）

OCPU 小時：代表你使用 CPU 核心的時間。例如 3,000 OCPU 小時就是一個月內總共可用的 CPU 運算時間。
GB 小時：指的是記憶體容量乘上使用時間。
例如，如果你配置了 1 GB 記憶體並且持續運行 1 小時，就消耗了 1 GB 小時。
如果你配置了 6 GB 記憶體並且持續運行 1 小時，就消耗了 6 GB 小時。
所以 18,000 GB 小時的意思是：你在一個月內最多可以使用的記憶體資源總量。

此專案（全天運行）

1. OCPU 小時

每台 VM：4 OCPU。
一個月時間：約 720 小時。

4 OCPU × 720 小時 = 2,880 OCPU 小時

👉 這剛好落在免費額度 3,000 OCPU 小時以內。

2. GB 小時

每台 VM：24 GB RAM。
一個月時間：約 720 小時。

24 GB × 720 小時 = 17,280 GB 小時

👉 這也在免費額度 18,000 GB 小時以內。

系統整體月成本總表（依每日訂單量區分）

攤位規模	單日訂單量（約）	LINE 使用方式說明	LINE 官方帳號	Google Apps Script	雲端伺服器（OCI）	每月總成本
小攤（偏冷門）	100 ～ 200 單／天	每單通知＋少量分群行銷	NT$800	NT$0	NT$0	NT$800
中等熱門（低）	300 單／天	每單通知＋定期分群行銷	NT$1,200	NT$220	NT$0	NT$1,420
中等熱門（高）	600 單／天	每單通知＋高頻分群行銷	約 NT$3,600	NT$220	NT$0	約 NT$3,820
超熱門（中）	800 單／天	每單通知＋高頻分群行銷	約 NT$6,000	NT$220	NT$0	約 NT$6,220
超熱門（高）	1,500 單／天	每單通知＋密集分群行銷	約 NT$9,000 以上	NT$220	NT$0	約 NT$9,220 以上

結論

本成本分析以「微型商家是否能以可負擔的成本長期使用本系統」為核心評估標準，針對不同攤位規模與實際操作情境，分別估算 LINE 官方帳號、Google Apps Script 與雲端伺服器等主要成本來源。

分析結果顯示，系統整體成本結構高度集中於 LINE 官方帳號的訊息費用，其餘關鍵元件在合理使用前提下幾乎免費。對於每日訂單量介於 100 至 200 筆的小型攤位而言，即使每筆訂單皆發送完成通知，並搭配少量分群行銷推播，每月成本仍可控制在新台幣 800 元左右。此一費用水準已低於多數商用點餐或 CRM 系統的最低訂閱門檻，符合微型商家可負擔的營運範圍。

當攤位規模提升至每日約 300 至 600 筆訂單時，系統在 LINE 訊息用量與 Google Apps Script 執行時間上皆仍具備可預期的成長曲線。即便升級至 Google Workspace 付費方案以確保觸發器穩定性，整體月成本仍落在新台幣 1,400 至 4,000 元區間，顯示本系統在中等熱門攤位規模下，仍維持良好的成本可控性。

然而，在超熱門攤位（每日 800 至 1,500 筆訂單）的最忙碌情境中，若同時出現高頻訂單狀態更新、密集查詢行為以及即時計算 RFM 與 CAI 指標，Google Apps Script 的每日執行時間可能逼近甚至超過付費方案所提供的 6 小時上限。此結果顯示，對於極高流量且高度依賴試算表即時運算的攤位而言，GAS 可能成為系統擴展時的潛在瓶頸。

在雲端伺服器方面，採用 Oracle Cloud Infrastructure Free Tier 作為後端部署環境，在全天運行的前提下，其 CPU 與記憶體使用量仍可維持於免費額度內，使本系統在伺服器成本上幾乎不產生額外支出。

綜合以上分析可知，本系統在小型與中等規模攤位情境下皆能維持明確且穩定的低成本優勢，且主要支出與實際訂單量與行銷頻率呈線性關係，商家可依自身營運狀況彈性調整使用方式。整體而言，本成本分析結果證實本系統確實符合「低成本、可長期使用」之設計目標，具備實際導入微型商家營運環境的可行性。

前提