- 自動通知
帳務資訊變更：待辦收成一則 Slack 訊息
把標記為「待修改」的抬頭與地址彙成一則 Slack 提醒；後台更新與清除旗標仍由人完成。
背景與使用技術（4 項）
客戶換了公司名稱或搬了地址，發票上的抬頭與地址就得跟著改，但待改項目散在彙總表的各列裡，只能靠人一列一列盯。改成定時掃描「待修改」旗標（彙總表上標記待辦的欄位）的排程腳本，把當下所有待辦收成一則 Slack 訊息。刻意不做防重發：旗標本身就是唯一的狀態來源，處理完清掉旗標就不再提醒，代價是旗標沒清掉就會反覆提醒。
誰在用
處理客戶帳務資訊變更的營運同仁
原本怎麼做
每張發票上都印著客戶的公司登記名稱與地址。客戶改了名稱或搬了地址，發票上的這兩行就得跟著改，而要改的是開立發票的那個服務後台的資料，沒有人去改，下一張發票還是舊的。客戶透過表單提出變更，全部彙總到一張試算表，但試算表不會主動告訴你哪一列要處理，下班前也沒有任何地方記著「全部待辦」。
前後對比
量測：實測＝有計時或有紀錄；估計＝喜特先生推估；客戶自述＝客戶回報；規格＝設計上的固定條件；待補＝尚未取得數字。
流程一眼看懂
客戶表單彙總成試算表
靠人翻表找待辦
排程掃描旗標欄
彙整成一則 Slack 訊息
人到後台更新
清除旗標
流程示意：依本案既有做法整理，非客戶實際畫面。
做了什麼
- 旗標即狀態：不另存「已通知」，只有一份狀態來源。
- 把所有待辦收成一則訊息，而不是每列一則。
- 刻意不做防重發，把「旗標沒清」變成看得見的提醒。
程式碼與實作細節收在頁面下方，需要時再展開。
你的情況像這樣嗎？
- 客戶的變更請求集中在一張表，但沒有人主動去看。
- 你想只認一份狀態，不想表上同時有「待辦」與「已通知」兩套標記。
- 每天只需要一則「現在還有哪些要處理」的清單。
更多成果與運作條件
不再人工巡檢
背景排程自動掃描，同仁不必打開表格逐列查看
一則訊息看完全部待辦
客戶名稱、統編與要改的內容集中在同一則訊息裡
單一狀態來源
只認旗標欄一處，清除旗標就是唯一的收尾動作，沒有第二份紀錄需要同步
- 漏件變得看得見：是否漏件從「有沒有人記得去看表」變成「旗標有沒有清掉」，後者可以直接檢查
以上為本案既有成果與運作條件；估計值依原始資料標示，其他專案需另行評估，並非通用成效保證。
挑戰：原本遇到的困難
每張發票上都印著客戶的公司登記名稱與地址。客戶改了名稱或搬了地址，發票上的這兩行就得跟著改。真正要改的不是我們自己的表格，而是開立發票的那個服務後台的資料，沒有人去改，下一張發票還是舊的。
- 待辦看不見：客戶透過表單提出變更，全部彙總到一張試算表，但試算表不會主動告訴你哪一列要處理，漏看就是真的漏掉
- 沒有人知道還剩幾筆：下班前從來沒有任何地方記著「全部待辦」，只能靠人翻表
- 狀態不能有兩份：若通知完在表上另記一筆「已通知」，同一張表就會有兩份狀態，遲早對不起來
- 執行時間有上限：排程腳本單次執行有六分鐘上限，表越長、逐列寫回的次數越多，越容易逼近逾時
所以目標是讓待辦主動出現在同一個地方，且只認一份狀態來源。
完整解決方案與設計取捨
一支寫在變更彙總試算表裡的 Apps Script，由時間驅動的背景排程觸發，不需要任何人手動操作。
- 時間驅動觸發：排程依設定的頻率呼叫通知函式。這個觸發器不在程式碼與版本管理的範圍內，需要在 Apps Script 編輯器中手動建立
- 掃描彙總表：逐列檢查抬頭旗標欄與地址旗標欄，只要任一為「待修改」，該列即納入本次通知
- 彙整成一則 Slack 訊息：把所有命中的列組成單一純文字訊息，包含客戶名稱、統一編號、要改的新抬頭或新地址，發送到指定頻道
- 到服務後台更新並清除旗標：依訊息內容更新公司抬頭或地址，處理完把該列旗標改掉，下一次掃描就不會再納入
設計上沒有防重發機制：只要旗標仍是「待修改」，每次執行都會再次通知同一列。
技術與實作細節
展開完整實作說明
為什麼改一個抬頭會影響發票？
發票上的公司登記名稱與地址，決定這張發票屬於哪一家公司。所以客戶換了登記名稱或搬了地址，從下一張發票開始，發票上的資訊就必須是新的。
真正容易出錯的是「改在哪裡」。改我們自己的彙總試算表沒有用，因為開立發票的是外部的電子發票服務後台。在有人進去把那筆資料改掉之前，每一張發票都會繼續帶著舊資訊出去，而第一個發現問題的通常是客戶。
所以這不只是資料登打的問題，而是交接的問題：客戶透過表單提出變更，變成表上的一個待處理列，接著要有人把它搬到真正會印出抬頭的系統裡。這支通知存在的理由，就是讓這個交接主動說出自己，而不是等著被發現。
慢的不是資料量，是逐列回寫
舊版腳本逼近了六分鐘的執行上限。直覺上會以為是資料量太大，所以應該縮小掃描範圍或分批處理。
實際量過之後，時間花在回寫那一段，不在掃描。逐列寫入每寫一格就是一次對試算表服務的呼叫，列數越多，往返次數越多。而那些逐列回寫，寫的正是原本規劃的「已通知」欄位。
新版把「已通知」欄整個拿掉，一次解決兩個問題：表上不再有第二份可能和旗標不同步的狀態，也不再有那批把執行時間推向上限的寫入。現在只認旗標一個來源。代價是沒有防重發，這點在文件中特別標註，避免之後有人想順手補上防重發，卻沒意識到它是刻意拿掉的。對操作的人來說，表再長，這支腳本仍然跑得完。
欄位位置集中設定，邏輯不寫死
彙總表的欄位位置不是穩定不變的。統編、客戶名稱、新抬頭、新地址與兩個旗標欄，都可能因為表單調整而挪動。所以程式碼中只有一處設定寫死欄位索引，掃描與彙整邏輯都透過這份設定讀值。表格版面改了，只改設定，不動邏輯。
例外通知走另一個頻道
主流程用 try/catch（攔截錯誤的寫法）包住，失敗時發到專用的錯誤頻道，而不是和一般提醒混在同一個頻道。這兩種訊息的閱讀對象與急迫程度不同：例外要有人盯著看，一般提醒不用。混在一起的話，例外訊息很快就會被每天的彙整提醒洗掉。
排程觸發器不屬於程式碼的管轄範圍。推送程式碼不會建立、搬動或刪除觸發器，觸發器是某個人用自己的帳號在編輯器中建立的，建立後就綁在那個帳號上。之後若改名或刪除觸發器指向的函式，觸發器不會知道，仍會按時觸發並因找不到函式而失敗。換人接手或帳號異動時，清理只能進到那個帳號裡手動處理。凡是用這種方式排程的專案，都有這個隱形依賴，建議在文件中記錄觸發器的建立者與設定。
因為沒有防重發，觸發頻率要照「旗標會在多久內被清除」來抓，別設得太密，否則同一則待辦會被反覆提醒，造成雜訊。