跳到主要內容跳到頁尾
作品
  • 自動通知

退票通知:有退票才發 Slack 私訊,沒有就安靜

每天檢查退票紀錄,只把當日要處理的項目彙成一則 Slack 私訊。

2026/08
每天掃描 1 次、1 則 Slack 私訊
案例閱讀約 2 分鐘
背景與使用技術(4 項)

退票有處理時限,漏看當天就可能錯過處理窗口。過去要靠人記得打開試算表逐列看,現在一支定時 Apps Script 每天掃描退票紀錄,把當天的退票彙整成一則 Slack 私訊給承辦人。沒有退票的日子完全不發訊息,安靜本身就代表「今天沒有要處理的事」。

Google Apps ScriptSlack排程通知

誰在用

處理退票的承辦人

原本怎麼做

支票遭退回是有時效的事,漏看退票的那一天,等發現時下一個處理週期可能已經過了。表格不會主動說話:每一筆退票只是在試算表上多出一列,沒有任何東西提醒「今天多了一筆」。忙的時候最容易漏,而且若每天都推一則「今天 0 筆」,真的有事的那天看起來會跟其他每一天一模一樣。

前後對比

發現退票改造前試算表多一列,沒人提醒改造後每天比對日期欄,命中的列彙整成 1 則 Slack 私訊規格
沒有退票的日子改造前若每天推「今天 0 筆」,有事那天看起來沒差別改造後不發任何訊息,安靜就是訊號規格
彙整方式改造前每筆退票是試算表上的一列,要自己逐列看改造後命中的列彙整成 1 則私訊,每列以「欄位名稱:值」逐項列出規格

量測:實測=有計時或有紀錄;估計=喜特先生推估;客戶自述=客戶回報;規格=設計上的固定條件;待補=尚未取得數字。

流程一眼看懂

改造前
  1. 試算表多一列退票

  2. 靠人記得去翻表

改造後
  1. 每天定時執行

  2. 比對日期欄是否為今天

  3. 命中列彙整成一則訊息

  4. Slack 私訊(0 筆不發)

流程示意:依本案既有做法整理,非客戶實際畫面。

做了什麼

  1. 單一比對條件:只檢查日期欄是否等於今天。
  2. 彙整成一則訊息,每列以「欄位名稱:值」逐項列出。
  3. 命中 0 筆就不發訊息,安靜是刻意設計。
  4. 例外走另一個頻道,避免被誤認成「今天有退票」。

程式碼與實作細節收在頁面下方,需要時再展開。

你的情況像這樣嗎?

  • 你的事件只是在表格裡多一列,沒人會主動去看。
  • 漏看一天的代價,是下一個處理週期已經過了。
  • 你不想每天被「今天沒事」的訊息洗版。

更多成果與運作條件

  • 退票彙整為 1 則通知

    有退票的當天,彙整成一則 Slack 私訊

  • 無退票就不通知

    沒有退票的當天不發任何訊息,安靜即是訊號

  • 毋須額外維護通知狀態

    不另存用來防止重複通知的「已通知」狀態

以上為本案既有成果與運作條件;估計值依原始資料標示,其他專案需另行評估,並非通用成效保證。

挑戰:原本遇到的困難

支票遭退回是有時效的事。漏看退票的那一天,等發現時下一個處理週期可能已經過了,原本只是例行處理的事,就變成要去追的事。

  • 表格不會主動說話:每一筆退票只是在試算表上多出一列,沒有任何東西提醒「今天多了一筆」,只能靠人去翻
  • 忙的時候最容易漏:承辦人很難保證每天都會打開那張表,漏看通常是在最忙的時候發生
  • 「沒事」與「沒看」分不清:若每天都推一則「今天 0 筆」,真的有事的那天看起來會跟其他每一天一模一樣

完整解決方案與設計取捨

一支寫在退票紀錄試算表裡的 Apps Script,由時間驅動的排程(trigger)每天執行一次,不需要任何人手動觸發。

核心設計

  1. 單一比對條件:只檢查日期欄是否等於今天,命中的列才算退票
  2. 彙整成一則訊息:所有命中的列組成一則 Slack 私訊,每列以「欄位名稱:值」逐項列出
  3. 0 命中就完全不發訊息:安靜是刻意設計的結果,代表今天沒有要處理的退票
  4. 例外走另一個頻道:執行本身失敗時發到專用的錯誤頻道,不與正常通知混在一起,避免被誤認成「今天有退票」

技術與實作細節

展開完整實作說明

不做防重發,因為比對條件會自動失效

避免同一筆退票重複通知,最直覺的做法是通知後在列上標記「已通知」。這支腳本不需要。它唯一的比對條件是「日期欄等於今天」,昨天符合的列到了今天自然不再符合,不需要追蹤旗標,也不會出現另一份可能與表格內容對不起來的狀態。

表格的形狀是隱形的前提

腳本假設第 2 列是欄位標題,資料從第 3 列開始。若有人在標題列上方插入一列,欄位對應就會在腳本不知情的情況下錯位。症狀不是報錯,而是通知不見了,或內容欄位亂掉,事後很難追出原因。

日期欄也必須是真正的日期值,不能是看起來像日期的文字。腳本以型別判斷,文字格式的日期會被悄悄跳過,不會報錯,那一筆退票永遠不會被通知,靜靜留在表上,外觀跟已經通知過的列一模一樣。

注意

交接給維護這張表的人時,要明確交代兩件事:不要在標題列上方插列,日期欄維持真正的日期格式。這兩件事一旦違反,症狀是「沒有通知」,不會有任何錯誤訊息。

看不見的排程

每日觸發的排程(trigger)不是由 clasp(把程式推送到 Apps Script 的工具)建立的,而是有人用自己的帳號,在 Apps Script 編輯器中手動建立。它獨立於程式碼存在,不會出現在原始碼或版本紀錄裡。

這代表那個帳號一旦不再使用,通知就會停止,而程式碼中找不到任何線索。這件事值得在交接時明確記錄,而不是等出事之後才查。

Bot token 不進原始碼

Slack 機器人的存取憑證(bot token)放在專案的 Script Properties(Apps Script 存放設定值的地方),不寫在程式碼裡。clasp 推送只會搬動原始碼,不會連帶搬動憑證,所以 token 不會以明文留在版本紀錄或共用的程式碼倉庫中。

延伸閱讀

有類似的情境想討論

帶著現有流程與去識別範例,討論適合的做法。