派車系統與司機 App

「派車系統」在不同的車隊，指的是完全不同的東西。遊覽車包車、貨運配送、固定接駁，這三種的派工單位、司機 App 畫面、後台看板都不一樣，資料結構也不一樣。

所以本文件的做法是：共通的核心先寫具體（任務單狀態、指派、司機接單回報、位置同步、工時檢核），分歧的部分攤開來讓您指認。請先看第二節那張表，告訴我您是哪一種，我再把對應的細節補上並更新報價。

因為通用的結果是三種都做不好。包車行程要處理的是跨日佔用與衝突，配送要處理的是一天幾十趟的順序與時窗，接駁要處理的是排班輪替與代班——硬做成同一張表單，最後三邊都要遷就。

共通的那七成我這份文件已經寫具體了，可以直接開工；剩下三成等您指認型態後補上，報價一併更新。

一、司機端的成敗在於他們願不願意用。 傳個連結就能開，比請司機去商店搜尋下載少掉一整段摩擦。改版也不必再拜託每個人更新。

二、唯一的功能差距是背景定位，而這個差距在實務上比帳面小。 司機一開導航，原生 App 也一樣被切到背景，還要跟導航搶電池。本案的做法是節點式定位：按「出發」「抵達」「完成」的當下各取一次座標，您得到「幾點從哪出發、幾點到哪」，對派工與對帳通常就夠。

三、真要即時看到車在哪，答案本來就不該是手機。 車機 GPS 比手機準、不吃司機電池與流量、司機關掉程式也照跑。貴司車上若已裝 GPS，本案可改讀車機資料，見〈參考附錄〉四。這條路和 A 併用，效果比 B 好也比 B 省。

若您評估後仍希望上架商店（例如司機流動率高、或希望有商店的正式感），做法是先做 A，再把同一套包成 App 送審。程式碼共用，所以 B 的 2.5 人天是加在 A 之上，不是重做一次。

也就是說，這個決定不必現在定死。第一期規格確認時再選，甚至先上 A 跑一陣子、之後要上架再補，都不會浪費前面的工。

您刊登的需求說明是一句話，所以本文件的內容來自我對派車營運的理解，不是來自對貴司的了解。文中若有與實際情況不符之處，以您的說明為準，本文件隨之修正並改版。

我沒有在文件裡寫任何關於貴司規模、車輛數或現有系統的推測——那些我不知道，等您告訴我。