翻譯進度自動追蹤與催稿

🎯 這條流程解決什麼

翻譯案件不像買賣商品一手交錢一手交貨，它是一段橫跨一兩週、甚至一個月的協作過程，中間藏著初稿、自審、外部審稿、客戶確認、回修、定稿好幾道關卡。任何一道卡住，最後都會壓在交期那一天爆開來。

對 PM 來說，最折磨的是「看不見」。譯者埋頭在做，做到哪一步、會不會準時，PM 無從得知，只能靠經驗每隔兩三天就一個個敲訊息問「進度如何」。一家同時跑十五到二十件案子的中型翻譯社，PM 光是逐案追問、整理回覆、再轉達給客戶，每天就要耗掉兩到三小時，等於一個人三分之一的工時都花在「確認別人有沒有在動」這件沒有產出的事情上。

更糟的是，人工追蹤天生有盲點。PM 不可能每件都記得，往往是某個案子悄悄落後，等到交期前一天才驚覺初稿都還沒齊，這時只剩兩條路：要嘛譯者連夜趕工、品質打折，要嘛硬著頭皮跟客戶說要延期。前者傷了譯者，後者傷了信任，而信任這種東西，崩一次要補十次。

這條流程的核心，是讓進度自己浮上檯面，不必等人去問。系統每天定時巡檢所有進行中案件，比對交期與目前完成階段，依剩餘時間算出綠、黃、紅燈，黃燈先溫和提醒譯者、紅燈同步把 PM 拉進來協調，並把最新狀態同步到客戶可以自己查的進度頁。里程碑到期前自動排程提醒，讓問題在還是「小落後」的時候就被攔下，而不是變成「大延期」才被發現。

導入後的改變

導入前，PM 的一天從「今天有哪些案子該追了？」這個模糊的問題開始，全憑記憶與翻聊天記錄，漏掉一件就是一顆未爆彈；客戶想知道進度，得發信問 PM，PM 再去問譯者，一來一回半天過去，客戶體感是「這家好像不太上心」。

導入後，每天上班打開 Slack 就看到一份自動整理好的燈號清單：綠燈不用管、黃燈系統已替你提醒譯者、紅燈才需要你親自介入。PM 的注意力從「全部都要顧」收斂到「只顧真正有風險的兩三件」。客戶端則有一個隨時可查的進度頁，不必再問人。

以一家月接約六十件案子的翻譯社估算，PM 每天省下的逐案追問時間約兩小時，一個月就是四十多小時，相當於多出整整一週的可用工時去做更有價值的議價與客戶經營。因延誤未被及早發現而導致的緊急延期，依多數同業經驗可從每月三到五件降到一件以下，連帶減少賠償折讓與客訴。最難量化卻最關鍵的，是客戶因為「進度透明」而留下來的續約率，通常會明顯回升。

流程怎麼運作

第一步「排程巡檢」，由每日定時排程觸發，系統讀取案件清單（Google Sheets 或 Airtable）裡所有狀態為「進行中」的案子，抓出交期、目前完成階段與最後更新時間。

第二步「風險判定」，把剩餘天數除以剩餘工作量，算出每件案子的健康度。設定門檻，例如剩餘時間充裕標綠燈、進度落後於應有節點標黃燈、瀕臨交期且未到位則標紅燈。

第三步「分級提醒」，是這條流程的價值核心。黃燈時，系統透過 LINE Notify 或 Email 對譯者發出一則就事論事的提醒，附上案號、目前節點與建議完成時間；紅燈時，除了提醒譯者，還會在 Slack 同步通知 PM，附上案件摘要與風險原因，請 PM 介入協調。

第四步「進度同步」，把每件案子的最新狀態與里程碑回寫到客戶可見的進度查詢頁，讓客戶自己就能看到「初稿完成、審稿中」這類資訊，不必再來問。

第五步「里程碑提示」，在初稿、審稿、交件等關鍵節點到期前，透過 Google Calendar 自動排程提醒，讓相關人提前準備，而不是到期當天才手忙腳亂。

需要的工具與串接重點

平台用 n8n 或 Make 當排程與邏輯中樞。案件資料庫建議用 Airtable，它的視圖與狀態欄比純試算表更適合做看板；若團隊習慣 Google Sheets 也可以，但要把「交期、目前階段、最後更新時間」這幾個欄位固定下來，這是燈號計算的命根子。

提醒管道分兩層：對譯者用 LINE Notify 或 Email，貼近他們的工作習慣；對 PM 用 Slack，集中在一個頻道方便每天掃視。Google Calendar 負責里程碑排程提醒。

串接重點有三：一是燈號門檻要依你的案件類型實測調整，法律與技術稿件需要的審稿緩衝比一般文件長；二是提醒頻率要克制，黃燈一天一次即可，否則譯者會麻木；三是客戶進度頁只回寫「狀態與里程碑」這種抽象資訊，絕不外露譯者姓名或檔案內容。更多串接設定可參考 /recipes 的範例，整套自動化的全貌見 /automation。

常見錯誤與注意事項

最常見的錯誤，是把「燈號」當成「事實」直接對客戶承諾。燈號只是內部管理的風險提示，是否要對客戶承諾延期或調整交期，務必由 PM 人工判斷後再溝通，系統不取代專業協調。

第二個雷區是個資與機密。客戶進度頁僅顯示狀態與里程碑，絕不可外露譯者個資或案件正文內容；翻譯稿件常含營業機密與個資，存取必須分權限，不能全員可見。

第三，自動催稿的語氣要拿捏。提醒文案應就事論事、提供協助，避免變成機械式的逼迫，否則長期會傷害與譯者的合作關係。涉及報酬與合約的爭議，一律轉人工處理，AI 不介入判斷。

台灣中小企業情境案例

台北一家專做日文與英文商務文件的翻譯社，五位專職 PM、約四十位合作譯者，旺季同時跑近三十件案子。導入前 PM 每天花大量時間用 LINE 逐案問進度，仍每月發生三到四件因落後太晚發現而緊急延期，其中一次延誤一份重要合約翻譯，被客戶折讓兩成費用。

導入這條流程後，PM 每天打開 Slack 就看到當日燈號清單，黃燈案件系統已自動提醒譯者，PM 只需處理紅燈。三個月後，緊急延期降到平均每月一件以內，客戶因為有進度頁可自查、追問次數大減。PM 把省下的時間轉去經營大客戶，續約率與客單價都有感提升。

延伸應用

這條流程的骨架可以延伸到任何「多節點、長週期、需準時交付」的服務業。例如設計接案工作室可改成設計稿的初稿、修改、定稿追蹤；會計師事務所可用在報稅季的各客戶進度盯催；軟體外包團隊可套用在開發里程碑的進度同步。

在翻譯社內部，這條流程也能往前後延伸：往前接派稿與報價，往後接交件後的審稿驗收與客戶滿意度回收，形成從報價、派稿、進度到交付的完整自動化鏈，相關串接可參考 /workflows 的其他翻譯社流程。

⚠️ 客戶溝通提醒：自動催稿與燈號僅作內部管理輔助，是否對客戶承諾延期或調整交期，務必由 PM 人工判斷後再溝通，系統不取代專業協調。客戶進度頁僅顯示狀態與里程碑，勿外露譯者個資或案件機密內容。

流程圖

用到的工具

更多「專業服務」工作流

瀏覽全部工作流藍圖 → 自動化工作流中心 → AI Skills 食譜庫 →