很多學校都在用 Google 表單。
報名活動、調查意願、蒐集名單、設備報修、申請代課、填寫成果、統計需求，幾乎什麼事情都可以開一張表單。
久而久之，我們很容易把 Google 表單理解成一種「比較方便的問卷工具」。
但如果從行政工作流的角度來看，Google 表單真正有價值的地方，其實不是「讓大家填資料」。
而是：
它可以成為一個工作正式進入系統的入口。
這兩種理解，差別很大。
表單填完之後，事情才真正開始
以設備報修為例。
傳統做法可能是老師走進辦公室說：
「主任，三樓那台投影機好像壞了。」
主任先記在腦袋裡，有空再去看看。
如果事情一多，就可能變成：
誰報的？
哪一間教室？
什麼時候報的？
修過了嗎？
現在在等誰？
過了一星期之後，可能連報修的人都忘記當初說過什麼。
這時候如果改成 Google 表單，事情通常會改善一些。
至少可以留下：
報修時間、地點、設備、問題說明、填報人。
但如果做到這裡就停止，Google 表單仍然只是一個「資料蒐集工具」。
真正進入工作流思維之後，我們會再往下問：
這筆資料進來之後，要發生什麼？
例如：
填表
→ 自動建立案件編號
→ 通知承辦人
→ 狀態設為「待處理」
→ 指派處理人
→ 更新處理進度
→ 等待廠商
→ 完成維修
→ 通知原填報人
→ 留下維修紀錄
到了這裡，表單就不再只是表單。
它變成了：
工作流的觸發點。
真正重要的，不是「收到了資料」，而是「產生了一個事件」
這是一個很值得建立的觀念。
當一張 Google 表單被送出時，我們通常會說：
「收到一筆回覆。」
但從資訊系統的角度來看，更精確的說法應該是：
發生了一個事件。
例如：
有人完成設備報修。
有人提出請購需求。
有人完成活動報名。
有人送出代課申請。
有人填寫成果資料。
這個事件發生之後，系統就可以決定下一步。
也就是說：
資料不是終點，而是後續動作的起點。
這也是為什麼很多行政流程一旦建立表單之後，下一步很自然就會接到 Google Sheet。
因為 Sheet 可以記錄這些事件。
再進一步，Apps Script 可以針對「表單送出」這個事件執行後續動作。
例如寄信、建資料夾、建立文件、更新狀態、送通知、建立行事曆提醒。
所以表單真正重要的角色，不只是把紙本電子化，而是把原本模糊、口頭、零散的需求，轉換成一筆可以被系統處理的結構化資料。
一張好表單，其實是在定義工作
這也是為什麼表單設計不能只想：
「我要問哪些問題？」
更應該問：
「後面的流程需要哪些資訊？」
例如要辦理一場研習。
如果只是蒐集：
姓名、Email。
那麼後續承辦人可能還要再查：
服務學校、職稱、飲食需求、是否需要研習時數、是否住宿。
這就代表工作流在後面又多了很多資訊搬運。
所以真正好的表單設計，不是問題愈多愈好。
而是：
第一次就收集足以推動下一步的資訊。
但同時又不能把所有未來可能用到的資訊全部塞進去。
否則使用者會覺得填表很痛苦。
這裡其實涉及一個很重要的工作流設計原則：
只收集「現在推動流程所需要的最小資料」。
這可以稱為 Minimum Necessary Data。
收太少，後面一直補資料。
收太多，前端填寫成本過高。
這中間需要的是流程判斷，而不只是表單美化。
表單欄位，其實會決定後面能不能自動化
再舉一個很常見的例子。
假設表單裡有一題：
「請說明您的需求。」
老師自由填寫：
「我下週二下午第二節有事情，可能需要找人代課，如果可以的話想找王老師，科目是自然。」
這個欄位人看得懂。
但如果未來希望讓系統自動處理，就會很困難。
系統要自己判斷：
日期是哪一天？
第幾節？
科目是什麼？
希望哪位老師？
這時候就會發現：
表單其實是在幫工作建立資料結構。
如果改成：
日期
節次
科目
代課原因
指定教師
每一欄都有明確格式。
後面系統就很容易做到：
自動統計節數、比對衝堂、建立代課紀錄、月底結算。
所以，工作流思維會反過來影響表單設計。
不是先做一張表單，再看看資料能做什麼。
而是先想清楚工作流程，再決定資料要怎麼進來。
表單最適合處理的，是「標準化的入口」
當然，不是所有行政工作都適合做成表單。
如果事情高度模糊、需要大量討論，或者每一次情境差異都非常大，硬做成表單反而會增加負擔。
Google 表單最適合的情況，是那些：
流程反覆出現、
需要固定欄位、
需要留下紀錄、
後續還有明確處理步驟的工作。
例如：
設備報修、活動報名、請購需求、代課申請、成果繳交、場地借用、帳號申請、意見回報。
這些事情的共同特徵是：
入口可以被標準化。
一旦入口標準化，後面的流程才容易跟著標準化。
而一旦流程標準化，自動化才真正有意義。
不要讓表單成為另一座資料孤島
不過，這裡也有一個常見陷阱。
很多學校建立了非常多 Google 表單。
每辦一件事，就開一張。
最後 Drive 裡面出現：
「報名表單 final」
「報名表單 final2」
「115 學年最新報名表單」
「115 學年真的最新版」
資料雖然都數位化了，卻仍然彼此斷裂。
這時候表單只是在製造新的資料孤島。
所以真正成熟的做法，應該開始思考：
這張表單進來的資料，是否能連到既有名冊？
是否能共用學校基本資料？
是否能對應到同一個案件？
是否能更新既有紀錄，而不是再建立一份新的資料？
也就是說，表單不應該只是：
新增資料。
更應該成為：
既有工作系統的一個入口。
從「做一張表單」改成「設計一個入口」
所以，下次當行政工作需要建立 Google 表單時，可以先不要急著想題目。
先問四件事：
這件事情從哪裡開始？
送出之後，誰要處理？
下一步需要哪些資料？
完成之後，要留下什麼紀錄？
當這四件事情想清楚，表單的角色就會完全不同。
它不再只是讓使用者「填完送出」。
而是正式把一件工作送進行政系統。
這也是從數位化走向工作流的第一個重要轉變。
表單的價值，不在蒐集資料。
而在於：
讓一件原本散落在口頭、紙本與訊息裡的事情，正式進入可追蹤、可處理、可自動化的流程。
當我們開始用這個角度看 Google 表單，它就不再只是一個免費的小工具。
它其實是很多學校行政工作流，成本最低、也最容易開始的一扇門。
