沒有資訊部門，也能推動 AI 自動化嗎？中小企業從 Excel、表單與 GAS 開始

一家 12 人的公司每天收到詢問表單，行政將資料貼進試算表，再寄訊息提醒業務；每週五有人重新整理案件進度，最後由主管複製到報表。這些工作看起來不複雜，卻因為每天發生，反覆消耗人力。企業主常以為要解決它，必須採購新的 CRM、雇用工程師或讓 AI Agent 直接操作所有系統。事實上，一條小流程可以先從既有工具的資料整理與事件觸發開始。

Google 官方將 Apps Script 定義為整合 Google Workspace 的快速開發平台，使用 JavaScript，能在瀏覽器編寫腳本並與 Sheets、Forms、Gmail 等服務協作。^[1] 它不是大型 ERP 的替代品，也不自動擁有 AI 推理能力；它更像是能依規則執行的工作助手。把固定、可預測的動作交給程式，把文字理解與草稿交給 AI，把重要核准留給人，是更容易驗收的入門分工。

自動化之前，先把「工作事件」說清楚

很多失敗專案一開始就要求 AI「自動處理所有行政工作」。這句話沒有規定輸入來自哪裡、成功要留下什麼紀錄、錯誤時誰要接手，也沒有說明哪些資料可以傳送給模型。工具越強，這種模糊要求就越容易把錯誤放大。最小可行工作流應該先回答：何時啟動、讀什麼資料、根據什麼規則、改動什麼、誰驗收、失敗怎麼辦。

以「收到企業內訓詢問後通知負責業務」為例，觸發事件是 Google 表單收到一筆新提交，輸入是公司名稱、聯絡方式、需求類別與希望時段，規則是檢查必要欄位與分派對應窗口，輸出是在工作表標示案件狀態並通知內部人員。若缺少必要欄位，應顯示待補而不是自動對客承諾。這是一個教學例子，並不代表已替任何企業建立或上線。

這個流程裡，AI 其實可能不是第一個需要的工具。表單欄位完整、資料格式一致、提醒規則明確時，傳統 Apps Script 就能處理大部分工作。只有當客戶留下大量自由文字，例如「我們想改善跨部門行政效率，但部門狀況不太一樣」，才可能需要模型協助摘要、分類或提出下一步澄清問題。不要為了使用 AI，而把原本確定的規則交給不確定的文字生成。

場景一：Google 表單進來，案件自動進入可追蹤清單

第一個適合試行的場景，是把原本由員工複製貼上的資料整理工作變成事件驅動。Google 表單提交後，回應可記錄在試算表；若需要客製處理，可設定 Apps Script 的可安裝表單提交觸發器，呼叫對應處理函式。^[2] 例如系統可檢查需求類別是否為既定選項，缺少必填項目就標成「待補資料」，通過後才列為「待分派」。

案件清單的欄位至少包含案件 ID、提交時間、需求類別、目前狀態、負責人、最後更新、下一步期限與例外原因。不要直接讓 AI 填寫「成交機率 80%」這種缺乏驗證依據的數字。若企業確實要評估商機，可先從可觀察的需求完整度、對方是否回覆、是否安排會議等事實開始，再由業務主管建立分級規則。

這個流程最重要的驗收不是程式能不能跑一次，而是能否穩定處理重複提交、缺漏欄位及格式錯誤。若表單在短時間被重送兩次，系統不應在沒有人確認的情況下建立兩份重複案件；若負責人尚未指定，案件必須清楚顯示待處理，不能假裝已成功交接。看似單純的狀態欄，是避免「系統有紀錄，但沒有人負責」的基本設計。

場景二：每週報表自動整理，但數字必須可重算

第二個常見任務是從多張試算表整理週報。公司可能每週匯總案件數、報價金額、付款狀態及處理進度。人工整理時常因欄位順序改變、不同同事填寫方式不一致或重複列而出錯。這時先建立資料字典，比直接用 AI 生成一張圖表更重要。

一個好用的資料字典至少規範案件 ID 唯一性、日期格式、金額幣別、有效狀態值及資料來源。Apps Script 可負責讀取、整理和排程固定欄位，Excel 或 Sheets 公式負責可重算的計算；若需要人閱讀的說明，AI 可以根據已核對的結果草擬摘要。但模型不應在缺少資料時自行補出業績、金額或成長率。所有報告都應標示截止時間及資料涵蓋範圍。

例如本週詢問量比上週增加 10 件，這只是計數差異，不足以證明廣告或內訓需求上升是由某項活動造成。若資料包含多個來源，還要檢查重複案件、欄位轉換與缺漏。主管想要快速知道變化，可以讓 AI 幫忙整理異常清單，但正式營運數字仍應回到可稽核的計算表。這種做法也讓新人比較容易查明每個數字從何而來。

場景三：提醒與追蹤自動化，讓人工集中處理例外

第三個場景是案件逾期提醒。當一件工作超過指定天數沒有更新，GAS 可以依固定規則找出案件，寫入待辦清單或通知負責人。這類工作不需要 AI 重新判斷「好像很急」，因為時間門檻和責任歸屬是明確的。AI 如果參與，較適合協助將多件逾期原因整理成主管容易閱讀的摘要，而不是獨自決定誰應被責備。

不過，自動通知也是最容易造成干擾的功能。一個有瑕疵的排程可能每十分鐘寄出相同信件，反而讓同事忽略重要訊息。設計時應有去重、頻率上限、通知日誌及停用開關。若連續失敗，系統要讓管理者知道「這項提醒沒有送出」，而不是默默重試到配額用完。

Google 官方說明，可安裝觸發器可依事件或時間執行，但它始終以建立者的帳號身分運作，並受服務配額限制。^[2] 這意味著員工離職、帳號被停用或權限改變，都可能影響流程持續運作。因此即使只有一段小腳本，也要指定正式管理者、備援人員和維護文件，不能讓所有自動化都綁在一位同事的私人帳號。

Excel、Sheets、GAS、AI 其實各有不同職責

Excel 適合許多既有財務、營運與分析工作，特別是公司已建立的計算模型與報表。Google Sheets 是雲端協作試算表，可與 Forms 和 Apps Script 在同一套 Workspace 中配合。GAS 負責按規則讀寫資料、觸發通知與安排定時任務；AI 模型擅長整理非結構化文字、提出分類建議與產出初稿。它們並非完全替代關係。

如果公司核心資料都在本機 Excel 或封閉網路，不能直接假設 GAS 可存取。資料需要經過授權的匯出、同步或 API 才能進入雲端服務；若政策禁止上傳，就必須採用內部允許的工具，而不是繞過管控。這也是為何導入前要先檢查企業的資料地理位置、保密義務及存取規範，再決定工具組合。

經常有人問「可不可以由 AI 幫我寫 Apps Script？」可以，但要將生成程式碼視為需要測試的草稿。AI 能產生看似完整的 JavaScript，卻可能使用錯誤 API、過度要求授權、忽略重複執行或錯誤處理。若非工程師使用，先在測試用表格執行，確認讀寫範圍、權限、失敗狀態及備份方式，再交由具備能力的人審查生產部署。不要把「模型寫得出來」等同「公司可以直接上線」。

一個最小示範：只做欄位檢查，不直接寄送郵件

以下程式是教學用的表單回應檢查示例，需依實際表單欄位調整，並在連結表單回應的測試試算表中，設定 Google Sheets 的可安裝表單提交觸發器。它示範如何從 e.namedValues 取得表單輸入，驗證欄位存在，並將記錄寫入執行日誌；不會直接寫入正式客戶清單、不會自動寄信，也不含任何外部 AI API 呼叫。正式使用還需考慮資料保護、去重、授權與錯誤通知。

function onFormSubmitExample(e) {
  if (!e || !e.namedValues) {
    throw new Error('必須由表單提交事件觸發');
  }
  const values = e.namedValues;
  const company = String((values['公司名稱'] || [''])[0]).trim();
  const demand = String((values['需求類別'] || [''])[0]).trim();
  if (!company || !demand) {
    console.warn('資料待補：缺少公司名稱或需求類別');
    return;
  }
  console.log('資料欄位通過基本檢查');
}

這段範例刻意沒有把原始公司名稱輸出至日誌，以降低不必要的資料曝露。它不具完整安全性驗證，也不是可直接放進正式營運環境的完整產品。實際表單回應事件有不同觸發來源與事件物件結構，應依使用的是 Forms 還是 Sheets 的表單提交觸發器核對官方文件。若不知道程式會用誰的權限執行、資料會寫到哪裡，就不應直接部署。

權限是最容易被忽略的實作細節

Apps Script 讀取私人 Google 服務資料時，需要 OAuth 授權。Google 的官方文件指出，權限範圍通常由程式使用哪些服務決定，也可以在應用的 manifest 中明確配置最小必要權限。^[3] 如果一段原本只需要整理試算表的程式，卻要求存取整個 Gmail 帳戶，管理者就應追查原因。從 AI 複製來的程式碼若加入不必要的服務呼叫，也可能因此擴大授權範圍。

此外，觸發器以建立者身分執行，不代表其他同事點開試算表就會自動以各自帳號執行同一個程式。這對通知郵件、文件讀取與資料修改的稽核很重要。建議將測試帳號與正式流程責任人分開，記錄誰授權了哪個範圍、何時可撤銷權限，以及發生錯誤由誰處理。對涉及對外寄送或資料變更的流程，應設計人工核准及回復機制。

配額限制會決定小工具能否長期運作

Google 官方列明 Apps Script 有每日配額和執行時間等限制，個人帳戶與 Google Workspace 帳戶的上限不一定相同，而且額度可能變更。^[4] 例如郵件收件人數、網址擷取次數、觸發器總執行時間都有不同限制。即使單次示範成功，也不代表每小時大量執行或多人同時觸發時能穩定運作。

因此在設計前先估算「一天最多幾筆、每筆呼叫幾次、失敗重試幾次、是否需要批次執行」。若每天只有數十筆簡單表單，可能有足夠空間試行；若每天要處理數萬筆紀錄、需要嚴格即時性或跨多個系統高頻同步，就可能需要不同的基礎架構。規模是否合適，應由實際測試與當下官方配額決定，而不是憑印象保證 GAS 一定能承受。

設計上也可以降低配額浪費。不要每讀一格就呼叫一次遠端服務，能批次處理就批次處理；不要讓同一個任務在失敗時無限重試；不要把排程設得比工作需要還頻繁。當遇到額度不足，應顯示未完成狀態並通知管理者，而不是繼續反覆觸發，直到更多工作受到影響。

30 天部署順序：小範圍、可回復、能交接

第一週先畫流程圖，標出輸入、欄位、資料所有者、責任人、錯誤處理和成功指標。第二週在測試表格建立最小腳本，只處理固定規則，不串外部 AI。第三週選擇少量去識別化資料試跑，把錯誤分為缺漏、重複、權限、配額和欄位變動。第四週由流程負責人驗收，確認資料正確、失敗可追查、通知不重複，並準備停用與交接文件。

只有當規則型自動化穩定，且確實存在大量非結構化文字需要理解時，才考慮加入 AI 摘要或分類。新增 AI 之後，應重新檢查資料是否能送往模型、輸出錯誤如何被攔截，以及是否會因此增加人工作業。若公司規模小，流程需求簡單，不必因為市場都在談 Agent 就強行增加工具層級。

驗收最好保留一組「標準、缺漏、重複、無權限、外部服務失敗」測試案例。每次腳本修改後重新跑這些測試，確保新功能不會破壞原本的基本流程。若有正式客戶資料，測試必須使用去識別化或合成資料，避免在測試過程中產生不必要的資料曝露。

交接規格：不是把程式碼交出去就算完成

中小企業最怕的是最初寫腳本的人離開後，沒人知道程式在哪裡、為什麼需要某個帳號授權、哪一天會自動執行。對這類工作，交付應包含比程式碼更實用的資訊：資料來源、正式使用帳號、觸發條件、產出位置、使用權限、出錯通知、操作說明和停用方式。只要一張簡潔的交接卡就足以降低許多維護風險，卻不能省略。

主管可以要求交接時做一次「不靠原作者」的演練：讓另一位同仁用測試資料提交表單，確認結果是否正確寫入，找到腳本執行紀錄，並示範如何停止觸發器。若同事只會點執行按鈕，卻不知道資料改到哪裡、權限從哪裡來，這套流程仍不具備企業可長期依賴的基本條件。

對具有正式營運影響的工作，還應保留已核准版本。某個月修改資料欄位或觸發條件之後，至少要知道以前的流程和目前流程有何不同、由誰驗收、出了問題如何回到上一個穩定版本。即使不用專業版控平台，也可用紀錄表管理版本日期與變更摘要；但對跨系統或多人維護的程式，正式版本控制與程式審查仍是較穩妥的作法。

什麼情況不適合繼續用簡單 GAS？

如果需要全天候高可靠服務、嚴格即時性、複雜權限分層、龐大交易量或跨多個既有核心系統，使用小型腳本長期承擔全部工作可能會出現可靠性與治理缺口。這不是 GAS 本身「不好」，而是任何工具都有適用範圍。到此階段，企業應評估正式 API、工作佇列、資料庫、監控、部署管理與備援，而不是繼續將所有流程塞進同一個試算表。

另一種需要升級的情況，是資料正確性已經直接涉及財務結算或重大法律責任。試算表可能仍可作為前端管理工具，但交易紀錄與核准證據需要更正式的資料治理。當業務成長到這個程度，維護成本、資料一致性和稽核要求，應一併納入下一階段選型。不能因為最初的原型能運作，就讓它在沒有監督下變成正式核心系統。

即使未來導入 AI Agent，也應保留最初建立的輸入欄位、完成標準和例外規則。這些是企業自己的工作資產，不會因為換工具而失效；相反地，沒有這些資產，更昂貴的系統仍可能把模糊指令變成更快速的錯誤。把規則與資料從個人習慣中整理出來，是自動化最可複用的投資。

自動化成效要扣除維護與檢查成本

假設原本每天花 30 分鐘整理表單，改成自動化後只需 10 分鐘核對，表面每週省下不少時間；但若腳本每月需要主管花兩天修復，實際收益可能沒有那麼高。這裡的時間均為示意，不是工具效能承諾。企業應記錄日常處理時間、錯誤率、維護工時與未完成案件，讓「省下時間」經得起完整計算。

還要問省下的時間去了哪裡。若行政原本每天忙著複製資料，改成能追蹤客戶回覆、確認報價進度，可能改善的是服務品質；若只是把工作從行政轉移到主管每天檢查自動化錯誤，效益則需要重新評估。能夠保留完整例外紀錄並持續改善，比追求第一天完成全自動更具持續性。

讓每一段自動化有一個可見的停止條件

小型腳本上線後，不應只有「執行成功」和「執行失敗」兩種模糊狀態。資料缺漏、權限不足、重複提交、額度耗盡與外部系統暫停，都需要不同處理方式。若腳本檢查到關鍵欄位缺漏，可將案件留在待補；若沒有授權，應停止寫入並通知管理者；若是短暫服務錯誤，才考慮有次數上限的重試。這些規則讓企業知道什麼時候必須由人接手。

另一個基本原則是保留人工可執行的替代作業。當腳本、帳號或外部服務暫時不可用時，員工仍應知道如何接收新案件、記錄狀態並恢復處理。自動化不代表移除所有人工步驟，而是把日常重複動作交給系統，讓人可以處理例外與維護服務承諾。

結語：企業最需要的不是一個萬能 AI，而是一條可信的工作流程

中小企業沒有專職 IT，不代表只能使用手動流程。但也正因為沒有專人維護，更需要從規模小、規則清楚、失敗可回復的任務開始。Google Forms、Sheets 和 Apps Script 可以先接住資料收集、狀態更新與通知；AI 再處理需要理解文字的部分；重要決策由人掌握。這種清楚分工，比把所有權限交給一個黑箱 Agent 更容易管理。

第一步很簡單：找出同事每天重複做、錯了又容易發現的一件事，寫清楚資料從哪來、何時算完成、遇到例外交給誰，先做一個可驗收的版本。若一個月後確實減少重複整理且沒有增加錯誤，再擴充下一條工作流。公司需要的不是更多自動化展示，而是能連續運作、可被同事接手的工作成果。

實務延伸

若希望透過培訓建立小型流程，可讓學員分組完成一張表單、一份標準試算表、一段經過測試的 GAS、基本錯誤處理與交接說明。產出應由企業資料政策與業務主管驗收，不能直接把教學腳本視為已完成正式系統。

參考資料

1. Google for Developers，〈Google Apps Script Overview〉：https://developers.google.com/apps-script/overview
2. Google for Developers，〈Installable Triggers〉：https://developers.google.com/apps-script/guides/triggers/installable
3. Google for Developers，〈Authorization for Google Services〉：https://developers.google.com/apps-script/guides/services/authorization
4. Google for Developers，〈Quotas for Google Services〉：https://developers.google.com/apps-script/guides/services/quotas?hl=zh-tw
5. Google for Developers，〈Simple Triggers〉：https://developers.google.com/apps-script/guides/triggers

圖片資訊

封面為 AI 生成的表單、腳本與試算表串接概念插畫，非 Google 官方介面。