派車系統與司機 App
您的需求是「派車系統，想要司機 App」。本文件把這兩件事拆成可以討論的具體範圍，並列出開工前必須先問清楚的問題。上方欄位可全文檢索三份內容（Ctrl K）。
這兩份是可以直接點的原型，不是截圖。 現在就能操作看看：
「派車系統」在不同的車隊，指的是完全不同的東西。遊覽車包車、貨運配送、固定接駁，這三種的派工單位、司機 App 畫面、後台看板都不一樣，資料結構也不一樣。
所以本文件的做法是：共通的核心先寫具體（任務單狀態、指派、司機接單回報、位置同步、駕車時間檢核），分歧的部分攤開來讓您指認。請先看第二節那張表，告訴我您是哪一種，我再把對應的細節補上並更新報價。
任務單狀態機、後台與司機端的功能界線、駕車時間檢核、驗收標準。
九個項次、分期付款、服務範圍與合作約定。
法定駕車時間、位置怎麼取、技術選型、與現成 GPS 產品的關係。
我做過人資系統與派車系統。這兩類東西的骨架是同一套：角色與權限、狀態流轉、每一步都要留痕、以及「誰在什麼時候改了什麼」要查得出來。派車再多一層：時間與資源的衝突，同一個人同一台車不能同時出現在兩個地方。
所以本文件寫得出任務單的六個狀態、時段衝突怎麼擋、駕車時間怎麼算——不是查來的，是做過才知道要注意這些。
一、速讀
| 項目 | 內容 |
|---|---|
| 本案在做什麼 | 一套派工後台加一個司機端：建單、指派、司機接單與回報、狀態同步、駕車時間檢核、報表 |
| 核心範圍 | 22 人天 × NT$5,000＝NT$110,000（未稅）。由工項推算，不是先看預算再開價。車隊型態造成的差異不含在內，見〈報價單〉第三節 |
| 工期 | 7 至 8 週。第一週的流程訪談是關鍵路徑 |
| 司機端 | 兩種做法由您選：LINE 綁定＋網頁介面（建議，含在報價內）或原生 App（另加）。比較與理由見第三節 |
| 驗收怎麼算 | 五項由您的調度與司機實際操作，見〈工作說明書〉第六節 |
| 最大的不確定 | 您的車隊型態，以及現在派車是怎麼運作的。這兩件事定了，其餘都是實作 |
| 交付什麼 | 完整原始碼、API 文件、部署說明。不綁定由我方後續維護 |
二、您是哪一種車隊
這是開工前最需要先確定的一件事。三種型態的共通部分約佔七成，剩下三成的差異決定了任務單長什麼樣、司機 App 主畫面放什麼。
| 型態 | 派工的單位 | 難點在哪 | |
|---|---|---|---|
| A | 遊覽車／包車 | 一趟行程（可跨日、跨縣市） | 車輛與司機被長時間佔用，衝突檢查是重點；行程常變更，改期改車要能追溯 |
| B | 貨運／配送 | 一張配送單，一天數十趟 | 重點在一天內的路線順序與時窗，司機 App 要能快速連續回報與取得簽收 |
| C | 交通車／固定接駁 | 一條固定班次 | 重點是排班輪替與代班，派工多為週期性複製而非逐筆建立 |
因為通用的結果是三種都做不好。包車行程要處理的是跨日佔用與衝突，配送要處理的是一天幾十趟的順序與時窗，接駁要處理的是排班輪替與代班——硬做成同一張表單，最後三邊都要遷就。
共通的那七成我這份文件已經寫具體了，可以直接開工；剩下三成等您指認型態後補上，報價一併更新。
三、司機端：兩種做法，我的建議與理由
您提到「想要司機 App」，兩種做法都做得出來，選擇權在您。以下把差別攤開，並說明我建議哪一種、為什麼。
建議的 A 案是用 LINE 當入口、網頁當介面：司機在 LINE 加好友、按一下綁定就完成註冊，之後派工通知直接發到 LINE，點開就是任務畫面。司機不必下載任何東西，也不必記密碼。
| A · LINE 綁定 ＋ 網頁介面 建議 | B · 原生 App（上架商店） | |
|---|---|---|
| 司機怎麼開始用 | 在 LINE 加官方帳號、按一下綁定，完成。不必下載、不必記密碼 | 到 App Store／Play 商店搜尋、下載、註冊 |
| 每天怎麼用 | LINE 收到派工通知，點開就是任務畫面 | 開 App，或從推播點進去 |
| 改版 | 後台一發布，所有人下次開啟就是新版 | 重新送審、等審核通過，司機還得自己更新 |
| 雙平台 | 同一套，不分平台 | Android 與 iOS 的差異要各自處理 |
| 開發者帳號 | 不需要 | Apple 每年 US$99、Google 一次性 US$25，由貴司持有 |
| 通知 | 走 LINE，司機本來就在看 | App 推播，需司機允許通知權限 |
| 離線暫存與續傳 | 支援 | 支援 |
| 拍照、撥號、導航 | 支援 | 支援 |
| 背景持續回報位置 | 不支援 | 支援 |
| 費用差 | 含在報價內（22 人天） | 加 2.5 人天／NT$12,500（未稅），含雙平台容器打包與首次送審。背景定位需另估，見下方說明 |
一、司機端的成敗在於他們願不願意用。 司機本來就整天在 LINE 上，加好友按一下就開始用，比請他去商店搜尋、下載、註冊少掉一整段摩擦。改版也不必再拜託每個人更新。
二、唯一的功能差距是背景定位，而這個差距在實務上比帳面小。 司機一開導航，原生 App 也一樣被切到背景，還要跟導航搶電池。本案的做法是節點式定位：按「出發」「抵達」「完成」的當下各取一次座標，您得到「幾點從哪出發、幾點到哪」，對派工與對帳通常就夠。
三、真要即時看到車在哪，答案本來就不該是手機。 車機 GPS 比手機準、不吃司機電池與流量、司機關掉程式也照跑。貴司車上若已裝 GPS，本案可改讀車機資料，見〈參考附錄〉四。這條路和 A 併用，效果比 B 好也比 B 省。
LINE 官方帳號的主動推播是計費的（司機主動傳訊、我方回覆則不計）。派工通知與異動提醒都屬於主動推播，費用隨司機人數與每日派工次數成長。
實際級距依 LINE 當期方案而定，我會在第一期依貴司的司機人數與每日派工量算出月費區間再交給您，這筆錢由貴司直接支付給 LINE，不含在本報價內。若評估後覺得不划算，通知可改走網頁推播，介面完全不變，只是司機要多做一次「加到主畫面」的動作。
若您評估後仍希望上架商店（例如司機流動率高、或希望有商店的正式感），做法是先做 A，再把同一套包成 App 送審。程式碼共用，所以 B 的 2.5 人天是加在 A 之上，不是重做一次。
也就是說，這個決定不必現在定死。第一期規格確認時再選，甚至先上 A 跑一陣子、之後要上架再補，都不會浪費前面的工。
四、接下來怎麼走
- 回覆您屬於上表哪一種（或都不是，請描述一下現在怎麼派車）
- 第三節的司機端 A／B 選一個，或告訴我您的顧慮。這一項可以留到第一期再定
- 看〈工作說明書〉第七節的六個待確認事項，前三項不先定義，做出來一定與預期不符
- 確認後我補上型態相關的細節，更新本文件與報價單作為簽約版本
您刊登的需求說明是一句話，所以本文件的內容來自我對派車營運的理解，不是來自對貴司的了解。文中若有與實際情況不符之處，以您的說明為準，本文件隨之修正並改版。
我沒有在文件裡寫任何關於貴司規模、車輛數或現有系統的推測——那些我不知道，等您告訴我。
Email：sscott6317tw@gmail.com ｜ 作品：xuzheng.com.tw、chihuahuatrip.tw