這部影片介紹一種以 LINE、Google Apps Script 與 Google 試算表組成的輕量電商系統，並以販售滴雞精為例，說明如何用日常工具快速建立具備商品介紹、下單、訂單管理與自動客服功能的 MVP（最小可行產品）。
一、核心想法：先用最少成本驗證生意
影片中的創作者原本想替家裡販售農產品，於是先請 AI 協助規劃一套輕量電商系統，而不是從頭自行開發完整平台。
其策略重點是：
- 先用現有工具拼出可運作的購物流程
- 避免一開始投入昂貴的平台費與伺服器費
- 以 MVP 的方式測試商品與營運流程，再視需求擴充
影片強調，這類架構可將每月的平台代管與伺服器成本降至零；不過，這指的是影片描述的工具與使用情境，實際費用仍可能受到各服務方案、使用量或功能需求影響。
二、三大核心架構
| 工具 | 在系統中的角色 |
|---|---|
| LINE | 顧客接觸店面：提供商品資訊、客服互動、下單與查詢訂單 |
| Google Apps Script | 後端處理中樞：接收 LINE 的請求，執行自動化邏輯 |
| Google 試算表 | 資料與營運管理：保存商品、關鍵字、訂單與狀態資料 |
三者透過 Webhook 串接：顧客在 LINE 上操作後，系統便可觸發 Apps Script，再讀取或更新試算表內容。
三、支付方式的關鍵取捨
創作者原本考慮串接第三方信用卡金流，但在開發過程中遇到技術障礙：Google Apps Script 處理信用卡付款成功後的轉址流程不夠順利，容易發生錯誤。
因此，系統改採：
- 銀行轉帳
- 貨到付款
影片的核心結論不是「信用卡金流不可用」，而是：對這個 MVP 而言，若金流串接會增加大量複雜度，不如先選擇容易維護的付款方式，降低技術風險與建置成本。
四、LINE 購物與自動化功能
影片介紹的購物體驗包含多種自動化功能：
- 關鍵字客服：店主在試算表設定關鍵字對應內容，例如輸入「加熱」即可收到商品加熱方式，輸入「優惠」則可取得促銷資訊。
- 動態計算貨到付款費用：依購物車金額計算手續費；影片舉例為 2,000 元以內收 30 元、超過 2,000 元收 60 元。
- 節慶選單切換：依日期更換選單，例如母親節期間顯示節慶版本。
- 回訪顧客記憶：辨識舊顧客並帶入上次的收件地址。
- 新訂單通知：有新訂單時自動寄送 email 通知店主。
這些功能讓試算表不只是存資料，也成為設定規則與支援營運的簡易管理工具。
五、訂單管理與狀態同步
影片描述的後台流程相當簡潔：
- 顧客選擇商品並完成下單。
- 若採銀行轉帳，顧客匯款後在 LINE 輸入帳號末五碼。
- 付款資訊同步到 Google 試算表，店主核對付款。
- 店主在試算表中更新訂單狀態，例如「已收到款項」或「已出貨」。
- 顧客透過 LINE 查詢時，即可看到更新後的訂單狀態。
因此，試算表與 LINE 形成 雙向同步：店主更新後台資料，顧客端也能取得最新資訊。
六、部署概念
影片將初步部署流程概括為四步：
- 開通 LINE API，建立系統與 LINE 的溝通管道。
- 取得專屬 Token，並放入 Apps Script 中使用。
- 將 Apps Script 發布，讓使用者能呼叫。
- 把 Webhook 網址設定回 LINE，完成串接。
影片沒有詳細展開程式碼或資安設定細節，而是著重說明整體架構與實際用途。
🧩 主要結論
這個案例展示了：小型商家不一定要一開始就購買完整電商平台，利用 LINE、Apps Script 與試算表，也能先建立一套具備基本銷售與營運能力的 MVP。
最值得帶走的策略有三點：
- 先解決最必要的問題：讓顧客能看資訊、下單，讓店主能接單與出貨。
- 遇到高複雜度環節時，先考慮簡化流程：例如暫不串接信用卡，改用轉帳或貨到付款。
- 把日常工具組合成工作流程：透過自動回覆、訂單通知與狀態同步，減少重複人工處理。
整體而言，影片傳達的不是「這套方式適合所有規模的電商」，而是：對想低成本開始、測試產品與驗證流程的小型賣家而言，先做出可用版本，往往比一開始追求完整平台更務實。
實務提醒：若要正式營運，仍應評估個資保護、Token 管理、訂單備份、系統使用量限制，以及付款與物流流程是否符合自身需求。
