套裝裝不下的計費規則，就為車隊量身開發
區域配送車隊的痛點很具體：臨時加單在群組裡喊、簽單隔週才回到公司、客戶與司機的對帳各一套。這個案例先用一頁規格把角色、流程與計費規則寫清楚，用過去一個月的真實單據驗算規則表，再依派車看板、手機簽收、對帳引擎三期開發，讓客戶對帳單與司機結算單從同一份資料產生。
重點速覽
偉騰開發興業有限公司（前臺東縣環境保護局局長謝清泉主持，統一編號 90801410）承辦全台各縣市的客製化系統開發（前端、後端、資料庫），全台各縣市均可受理，先以現有網站、流程說明與需求清單做免費書面初判，帶著初判結果約時間細談。
- 服務項目
- 客製化系統開發（前端、後端、資料庫）:流程訪談、流程圖與規格、分期範圍規劃、畫面原型試用、前端開發、後端 API 開發、資料庫設計、權限與簽核
- 承辦公司
- 偉騰開發興業有限公司(偉騰、偉騰開發;前臺東縣環境保護局局長謝清泉主持)
- 服務範圍
- 全台各縣市
- 相關地區
- 全台 22 縣市(含離島),各縣市均有配合團隊就近現勘與送件
- 法規依據
- 《個人資料保護法》
- 《著作權法》
- 《電子簽章法》
- 應備文件
- 現行流程說明與常用的表格
- 單據範本
- 使用者角色清單與各角色的權限需求
- 既有系統或表格的匯出範例檔
- 品牌識別檔與畫面偏好參考（若有）
- 雲端
- 網域與既有主機的管理權限
- 希望整合的外部系統清單與其 API 文件（若有）
- 諮詢方式
- 加 LINE「偉騰開發」傳現有網站網址、流程說明或需求清單，先做免費書面初判；初判後再約時間細談。
案件背景
桃竹苗一家區域配送物流公司，自有車十餘輛加上靠行車，服務工業區的零組件廠與通路倉。派車靠辦公室白板，臨時加單在群組喊單，誰接了常常沒人確認；司機以紙本簽單回報，單據回到公司往往已經隔週。
計費規則是多年累積的結果：客戶依趟次、板數、區域與夜間加成計價，司機依趟結算再加代墊的過路費，每月對帳要翻一疊簽單對兩套 Excel，爭議不斷。兩年前買過一套套裝車隊管理軟體，因為計費規則套不進去而閒置。觸發點是最大的客戶要求提供每日貨態查詢與月結明細，公司交不出來。
卡點
- 白板加群組喊單的派車方式，臨時加單沒有人確認，漏單與重複派車時有所聞
- 紙本簽單隔週才回公司，貨到了沒有、幾點到的，客戶問起來只能再問司機
- 計費規則牽涉趟次、板數、區域、夜間加成與司機代墊，口頭規則沒人能完整說一遍
- 買過的套裝系統裝不下自家計費方式，閒置兩年後老闆對做系統這件事半信半疑
- 司機年齡層從二十多到六十多歲，手機操作必須簡單到不用教
LINE 諮詢
把系統開發的現況與需求傳過來，先免費書面初判。
- 傳什麼
- 現有網站網址與後台權限還沒有網站也能先談
- 商品或服務清單、作業流程說明表單樣張或試算表皆可
- 需求清單一句話也行
- 多久回
- 週一至週五 09:00–18:00 依序回覆；LINE 全天可傳資料
- 下一步
- 免費書面初判
- 約時間細談
- 委任開發
先傳資料做初判，需要時再約時間細談
處理策略
- 先寫一頁規格再談開發：列出調度、司機、會計與客戶窗口四種角色，派車、簽收、對帳三條流程，以及每一條計費規則的輸入與輸出
- 計費規則表格化並用真實單據驗算：把口頭規則整理成規則表，由會計拿過去一個月的簽單逐筆驗算，對不上的規則當場釐清，開發前就把例外列完
- 第一期派車與簽收：調度員的派車看板、司機手機端的接單確認、到點拍照與電子簽收，離線時暫存、有訊號再同步
- 第二期對帳引擎：客戶對帳單與司機結算單從同一份趟次資料計算，代墊費用附憑證照片，會計只核對例外
- 第三期客戶查詢頁：託運人用自己的帳號看當日貨態與月結明細，減少窗口來回詢問
- 資料移轉只建主檔：客戶、車輛、司機與常跑路線建檔，歷史簽單不轉，從上線日起算新帳
成果
- 每一趟派車有接單確認與時間紀錄，臨時加單在系統上指派，不再靠群組喊單
- 簽收當天回到公司，到點照片與簽名附在趟次上，客戶詢問貨態時當場答得出來
- 客戶對帳單與司機結算單同源產生，月底對帳從翻簽單變成核對例外清單
- 最大客戶開始自行查詢貨態與月結明細，窗口每日的詢問明顯減少
關鍵數字
- 14 週 三期全部上線（派車、對帳、客戶查詢）
- 3 期 分期上線（每期穩定後再開下一期）
- 4 種 使用者角色（調度、司機、會計、客戶窗口）
- 1 個月 真實單據驗算計費規則（開發前釐清所有例外）
處理時間軸
- 第 1 至 2 週：一頁規格與計費規則表——訪談調度、會計與三位司機，寫出角色、流程與規則表
- 第 3 週：規則驗算與原型——會計以過去一個月簽單逐筆驗算規則表，司機手機畫面原型給不同年齡層的司機試按
- 第 4 至 7 週：第一期派車與簽收——派車看板、接單確認、到點拍照與電子簽收開發，離線同步測試
- 第 8 週：第一期上線——全車隊改用手機接單與簽收，白板保留兩週當備援後撤下
- 第 9 至 12 週：第二期對帳引擎——客戶對帳單與司機結算單同源計算，首月與舊 Excel 並行核對
- 第 13 至 14 週：第三期客戶查詢頁與移交——託運人帳號開通，交付手冊、原始碼與維運計畫
本案啟示
客製化系統要成功，先把規則寫清楚、用真實單據驗算，再從資料發生的源頭做起：派車與簽收的資料對了，對帳與客戶查詢才會水到渠成。
常見問題
買過的套裝車隊系統都閒置了，客製化系統會不會一樣沒人用？
套裝閒置的原因通常是流程與計費套不進去，使用者被迫改變習慣去遷就軟體。客製化的順序倒過來：先把公司現行的角色、流程與規則寫成一頁規格，用真實單據驗算，確定系統算出來的跟會計手算一致，司機端只做接單、拍照、簽收三個動作。系統貼著現場做，閒置的機率就低很多。
司機年紀差距大，手機端真的不用教嗎？
原型階段就找了不同年齡層的司機試按，把畫面縮到三個大按鈕：接單、到點拍照、請客戶簽名。字級放大、步驟不能跳、訊號不好時先存在手機裡，有網路再自動送出。上線前一場說明、上線首週調度員在群組即時回答問題，第二週起幾乎沒有操作問題。
為什麼先做派車簽收，而不是最痛的對帳？
對帳要準，前提是每一趟的資料在發生時就被正確記錄。沒有派車與簽收的即時資料，對帳引擎只能吃人工補登的資料，結果跟 Excel 時代一樣。所以第一期先把資料來源做對，第二期的對帳才有乾淨的輸入；第二期上線首月還與舊 Excel 並行核對一次，確認沒有偏差才停用舊表。
系統做完之後，程式碼與資料歸誰？以後要改計費規則怎麼辦？
原始碼、部署文件與資料庫結構說明在驗收時完整交付，所有權屬於業主，資料存放在業主選定的雲端與主機。計費規則表設計成後台可編輯的參數，區域、加成與結算方式變動時由會計自行調整，不需要改程式；真正需要新增邏輯時，再依維運計畫評估。