短期顧問聘用：業務填一份表單，協議、金額、勞務報酬單自己接上

情境改寫：依這類案件的常見做法整理，細節為示意。

某個工作日，一位業務同事談成了一位顧問來公司做一天實作。接下來他要做的事是：打開 Word 協議範本，把顧問的姓名、email、日期、費率一格格打進去；存成 PDF 寄出；過幾天再寄一封信問對方簽了沒；最後回到共用試算表，手動記下「這件簽了、那件還沒」。同一筆資料要在 Word、PDF、信箱、試算表四個地方各打一次，任何一處少打一個字，後面的步驟就跟著錯。

一兩件案子時，他還顧得來。後來這條鏈接成一套流程：業務填一份表單開案，之後交給系統。以下說明它怎麼接、怎麼擋重複觸發，以及踩過的坑。

人工做，會壞在哪一步

案子一多，這條鏈會斷在三個地方。

第一是忘了追簽名。協議寄出後，沒有任何東西提醒誰該再寄一封信；簽回來也沒有東西提醒誰該算錢、發下一張表。

第二是套錯地區的範本。三地的勞務契約與報酬單格式不同，同時在跑的案子越多，拿錯範本的機率越高。

第三是同一份協議寄了兩次。Word 範本不會記得自己已經產出過合約，對一個已經簽過的人，它照樣會再產出一份。這一種最危險：漏掉一步事後還能補，簽了兩份內容矛盾的協議，補不回來。

怎麼接成一條鏈：三步，每步都寫明下一步

← 左右滑動看完整的圖，點圖可放大

圖：三個階段由左到右串接，token 在每一步發出，狀態閘靠它判斷這一步是否已經做過。

第一步：業務開案，系統寄出協議

業務填寫該地區的協議表單，帶入顧問的姓名、email、日期與費率。系統收到表單後，複製一份協議文件（Google 文件），產生預覽 PDF 與線上簽署連結，寄給顧問。顧問點開連結線上簽署，簽署版 PDF 存入雲端硬碟，並寄給雙方留存。

開案由業務填，是因為只有業務知道案子存不存在、費率是否已談定。系統在顧問簽名前，先用這些資料做基本核對。

第二步：填會議次數，系統算金額

一日實作的錢分兩塊：固定的實作費，加上會議單價乘以當天實際開的會議次數。業務在系統頁面填入次數，系統算出總額，再寄出一份已預填好的發票表單連結給顧問。

第三步：回收勞務報酬單，依地區分流

顧問填寫表單，提供個資與證件資訊，系統複製一份勞務報酬單。這一步依地區分流：其中一地寄出未簽版本，請顧問列印、親簽、掃描後上傳；另外兩地直接帶入數位簽名，PDF 完成即可。最後系統通知雙方與營運窗口，案件結束。

同一件案子，怎麼擋住第二次觸發？

沒有後端資料庫，能用的只有 Apps Script（Google 的指令碼環境）與試算表。這裡的做法是 token 加狀態閘。token 是系統在某個動作完成時發出的一組隨機字串，存進追蹤表那一列；狀態閘則是下一次請求進來時的判斷：這個 token 是否已經用過、這份文件是否已經簽過。

流程的三個接觸點各有一個 token：consent（協議同意）、invoiceSetup（發票設定）、signatureReturn（簽名回收）。token 一旦發出就永不清除。清掉它，系統就忘了這一步做過，閘也就形同虛設。

下面是簽名回收那一關的判斷邏輯，示意用：

function acceptSignature_(row, token) {
if (row.signatureReturn !== token) return fail_('token 不符');
if (row.signed === true) return fail_('已簽署，拒絕重送');
row.signed = true;
return ok_(row);
}

發票回收那一關另外疊了兩道檢查：先核對表單提交人的 email 是否與案件記錄的顧問 email 一致，再檢查 invoiceReturned 狀態旗標。任何一關沒過，就退回並送 Slack 通知，不硬把資料寫進去。被轉寄出去的連結、被重複點下去的按鈕，都會撞上閘門。這些情境目前只用程式路徑檢查過，還沒有用真實的重送資料跑完整批測試。

追蹤表：一案一列，34 欄

所有狀態都在一張 Tracking 試算表上，每件案子一列。34 欄包含主鍵、各表單回填的資料、各階段的簽署狀態，還有指向雲端硬碟上 PDF 的檔案 ID，另有幾欄公式做彙總。

← 左右滑動看完整的圖，點圖可放大

圖：示意資料，只畫出 34 欄中的 7 欄。選取框停在協議 token，簽署閘讀取的就是這一格。

檔案 ID 指向的是實際用於交換的 PDF，文件本身仍是 Google 文件。文件是活的，隨時可能被改動；寄出去、被當作憑據的是 PDF。預覽版與正式簽署版各自留在雲端硬碟，對帳時對到的，才是當時寄出的那一份。彙總頁（Dashboard）是唯讀的，要改案件資料，只能改 Tracking 本身。

兩筆幾乎同時回填，會發生什麼？

每個 Web App 的 doPost 處理函式（Web App 是 Apps Script 發布成的網址，用來接收表單提交）一開始就取得 LockService.getScriptLock()。兩筆提交幾乎同時回填時，若不排隊，兩個寫入可能同時碰到追蹤表的同一列，後寫的會蓋掉先寫的。排隊慢一點，寫進去的內容才確定。

地區差異，改哪裡？

三地的差異包括費率、表單 ID、範本文件 ID，以及可以開案的業務名單，全部放在一個 REGIONS 常數裡。要調某一地的費率，或加第四地，改這個常數就好，不必到各處找判斷式。

通知只寄給送件的人，並固定 cc 一位維運窗口。其中一地另外有一組 initiators 白名單，記的是實際會送該地協議表單的業務，出事時知道該找誰。

踩過的坑

限制與還沒量到的事

錯誤回報是自己寫的一層薄包裝 tryRun，統一處理 try-catch 與錯誤通知。沒有沿用另外維護的共用函式庫，因為這個專案的接觸點與狀態流程，和那套函式庫假設的不同。

目前還沒量到的有三件：每件案子從開案到案件結束實際花的時間，尚未實測；重複觸發的整批重送測試，尚未實測，目前只有程式路徑的檢查；上線前人工作業花了多少時間，沒有留下記錄，無法拿來比較。