拖吊車即時位置追蹤通知

🎯 這條流程解決什麼

車主在路邊拋錨等救援，心裡最大的焦慮只有一句話：「車到底還要多久才到？」尤其是高速公路、夜間、雨天或帶著小孩、老人的車主，每多等一分鐘，焦慮就多一分。於是客服電話被「司機到了嗎」「怎麼還沒來」的查詢電話灌爆，一位客服一天可能接到上百通這種純查詢的來電，而每接一通，調度員又得回頭打給司機問位置，司機在開車中還要接電話報座標，等於同一筆案件的位置資訊被反覆人工傳遞好幾次。

把這個成本量化一下：假設一天派工 60 件，平均每件衍生 2 到 3 通查詢電話，每通含調度回查約佔用 3 分鐘，等於客服與調度每天合計要燒掉 6 到 9 小時在「回報位置」這件本來不需要人工的事情上。更糟的是，一旦遇到塞車或司機臨時改道，車主在毫無資訊的情況下越等越不耐煩，輕則客訴，重則直接掛斷重新報案叫別家，車隊不但白跑還丟了案子。位置資訊的不透明，表面上是溝通問題，實際上是直接侵蝕服務口碑與接案率的營運漏洞。

這條流程把「被動接查詢」翻轉成「主動報進度」，讓車主在等待時始終握有資訊，客服與調度則從重複勞動中被解放出來。

導入後的改變

導入前，位置資訊是封閉的：只有司機自己知道，車主一無所知，客服與調度靠電話人工橋接，資訊延遲又容易出錯，承諾的到場時間常常是隨口估的，估不準就引爆客訴。

導入後，派工一成立系統就自動接管位置追蹤，在出發、半程、即將抵達等節點主動把進度推給車主，車主不必打電話也知道車在哪、大概多久到。以一天 60 件派工估算，這類查詢電話有機會減少六到七成，客服每天省下的時間可以挪去處理真正需要人工的派遣與安撫；調度員不再被「幫忙問司機在哪」打斷，可以專心做更有價值的路線調度。延誤偵測讓客服從「事後被罵」變成「事前安撫」，客訴率明顯下降，因等不耐而流失的案件也跟著減少。整段歷程留下完整時間軸，萬一日後對到場時間有爭議，也有客觀紀錄可查，不再各說各話。

流程怎麼運作

第一步「讀取車機」：派工成立後觸發，系統定時（例如每一到兩分鐘）輪詢這台出勤拖吊車的 GPS 車機 API，取得即時座標與行駛狀態，判斷車輛是已出發、行進中還是停滯。

第二步「計算進度」：把拖吊車目前座標與車主所在地點丟給 Google Maps API，依即時路況估算剩餘距離與動態到場時間，並比對是否明顯偏離預期路線。這裡算出來的是會隨路況變動的「動態 ETA」，而不是出發時算一次就不變的死數字。

第三步「推播車主」：在幾個關鍵節點透過 LINE Messaging 主動推播給車主——出發時告知「司機已出發，預計約 X 分鐘抵達」、行程過半時更新進度、即將抵達時提醒車主到車旁等候。節點化推播避免疲勞轟炸，又確保車主在重要時刻收得到資訊。

第四步「延誤偵測」：當動態 ETA 比原先承諾明顯超標（例如多出十分鐘以上），系統自動標記這筆案件，提醒客服主動致電車主說明原因並安撫，把可能的客訴在爆發前先攔下來。

第五步「抵達確認」：司機抵達現場觸發到場打卡，系統把案件狀態更新為「已到場」並停止輪詢，避免無謂的 API 呼叫，整筆位置時間軸也同步歸檔到 Google Sheets。

需要的工具與串接重點

平台用 n8n 或 Make 串接即可。GPS 車機 API 是資料源頭，建議確認車機回傳頻率與穩定度，若車機本身回傳間隔太長，推播就會延遲。Google Maps API 負責距離與 ETA 計算，要注意它是按呼叫次數計費的，所以輪詢頻率要拿捏：太密集成本高，太稀疏 ETA 不準，一般每一到兩分鐘輪詢一次是合理的平衡，車輛接近目的地時可以提高頻率。LINE Messaging 是台灣車主最習慣的通知管道，比簡訊親切也比 App 推播觸及率高。Google Sheets 擔任案件狀態與位置時間軸的紀錄中樞。串接時最關鍵的兩件事：一是「到場打卡要確實停止輪詢」，否則案件結束後還在空轉燒 API 費用；二是「推播節點要去重」，避免同一節點因輪詢多次而重複發送，讓車主收到一堆重複訊息。更多救援車隊流程可參考 /workflows，通知訊息與進度模板收錄在 /recipes，想規劃整體導入步驟可看 /automation。

常見錯誤與注意事項

第一個必須謹慎處理的是個資與隱私。GPS 軌跡屬於司機與車輛的位置個人資料，僅能用於該筆救援案件的進度通知，不可長期保存、不可挪作司機績效監控以外的用途，蒐集與使用都必須符合個人資料保護法的目的限定原則，案件結束後的軌跡資料應有保存期限與刪除機制。

第二，推播給車主的到場時間是「預估值」而非保證。訊息文案務必明確標示「預計」「約」並提醒可能因路況變動，千萬不要寫成精確到分鐘的承諾，否則一旦塞車或臨時改道，過度精確的承諾反而成為客訴的把柄。

第三，自動化通知不取代人工溝通。遇到嚴重延誤、車主情緒激動、或現場狀況特殊時，仍須由客服或司機即時人工聯繫，系統的角色是減少例行查詢，而不是把所有溝通都自動化掉，這條界線要劃清楚。

台灣中小企業情境案例

桃園一家區域型道路救援公司，旗下六台拖吊車，主要承接保險派工與一般民眾報修。導入前每逢上下班尖峰與雨天，客服三線電話幾乎全被「司機到了沒」塞滿，調度員平均每十分鐘就要被打斷一次去幫車主問位置，旺季時客訴件數居高不下，常見抱怨就是「等了半小時都沒人告訴我車在哪」。導入這條流程後，車主在 LINE 上就能看到司機出發、過半、即將抵達的進度，純查詢電話大幅減少，客服得以把精力放在真正需要安撫的延誤案件上。約兩個月後，與到場時間相關的客訴明顯下降，車主滿意度回升，連帶保險公司的派工評比也變好，接案量穩定成長。

延伸應用

這條流程的位置資料可以再延伸出更多價值。對外，可以把推播升級成附帶司機姓名、車牌與聯絡方式的「司機資訊卡」，讓車主更安心；也能在抵達後自動接續「完工回報歸檔」流程，做到從派工到結案一氣呵成。對內，累積的 ETA 與實際到場時間差，可以拿來分析各區域、各時段的平均到場效率，找出哪些路段常塞、哪些時段人力吃緊，回頭優化據點佈署與排班。若同時經營多據點，還能把即時位置整合成一張全車隊地圖看板，讓調度一眼掌握所有車輛動態。想把這些延伸需求系統化規劃，可從 /automation 的導入框架著手。

流程圖

用到的工具

更多「汽機車」工作流

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