這一行的實際狀況
- 同一位個案一天會有好幾趟。去程、回程與日間照顧的接送分散在不同時段，調度要自己確認同一個人不會被排在兩個地方。
- 地址寫法沒有統一。家屬寫門牌，機構寫大樓名稱，同一個地點常有好幾種寫法。地圖查不到，就得回頭打電話問。
- 輪椅與陪同是派車的條件，不是備註。車型怎麼配，取決於這兩件事。但很多時候它只寫在紙條上，司機出車前還要再問一次。
- 臨時改期與取消很常見。地點一改，預估里程就得重算。取消也不能只是消失，原因要分派車前、派車後、行程中與管理員取消，才看得出問題出在哪裡。
- 預估里程和實際里程是兩個數字。建單時算出的是預估，司機結束行程後回報的是實際。月底要用哪一個，得在一開始就講清楚。
動工之前，我們會先問的事
想做或想換派車系統的車隊，我們會先問這些。每一題的答案，都會改變系統該怎麼記。
- 一天會替同一位個案排幾趟？去程、回程與日間照顧接送，是各建一張單，還是綁在一起？
- 上下車地址是誰寫的？地點現在有沒有存成固定的座標，還是每次都重打一次？
- 個案的輪椅型式與陪同人數，現在記在哪裡？司機出車前是怎麼得知的？
- 臨時改期或取消，通常是誰打給誰？取消的原因現在有沒有記？
- 調度的人有幾位？如果最熟的那一位請假，誰能接手派車？那些口頭約定的事，他能不能交出來？
- 司機回報的實際里程與車資，現在是用什麼方式交回來？多久一次？
我們在這個現場做了什麼
做法的核心只有一句話：預約時記下的東西，要夠調度、里程與月底核銷一起用。所以預約單上的每一個欄位，都是從後面的步驟倒推回來的。
- 預約單：個案與預約人分開記，上下車地址與座標各自保存，去程與回程兩筆訂單互相指向。陪同人數、乘車人數與輪椅型式分開記。
- 調度台：車與司機必須成對指定，只選一樣會被擋下。上方的時段統計只是列出該時段已有訂單的車與司機數，並扣掉可用數，不會自動排班。
- 里程：用 Google Maps 的駕車路線計算。起點與終點有有效座標就用座標，沒有才用地址，地址只在台灣範圍內搜尋。建單時算預估里程，實際里程另外保存。
- 司機回報：司機在 LINE 內開啟行程頁，只看得到派給自己的訂單。開始時記下實際上車點，結束後填寫實際里程、跳表車資與個案自付的部分，並可簽名確認。未填寫的訂單會停在待填寫記錄裡。
車資怎麼算、請款怎麼做，各有獨立的說明頁：多縣市長照交通接送計費規則，以及 支審核銷。
這類案子，我們通常怎麼開始
- 從預約單的欄位談起，畫面放後面。欄位少記一個，後面的里程、派車與核銷都會缺一塊，而且當下通常沒人覺得是問題。
- 地址整理成幾種固定寫法。把常去的地點存成座標，比追求每一筆地址都查得到，更快看到效果。
- 排班留給調度的人判斷。時段統計只是讓調度看清楚現況。要不要照著統計調整班表，還是要由調度的人判斷。
- 取消原因先留下紀錄，報表之後再說。資料先留得住，之後想看趨勢都還來得及。
適合來談的人：有固定長照接送班表、車輛與司機多到靠一個人記憶排不完的車隊，需要安排日間照顧接送的單位，以及要替這類單位建置系統、需要有人懂這一行的團隊。
常見問題
長照交通接送的排班怎麼做才不會漏單？
先把時間、上下車地址、輪椅與陪同需求記完整，再由調度台依時段排車。系統不允許只選車或只選司機就完成派車。
預估里程和司機回報的實際里程不一樣，以哪一個為準？
預估里程在建單時算出，實際里程由司機在行程結束時回報，兩者分開保存。月底核銷取用的是實際里程。
派車之後，訂單還能取消嗎？
可以，但取消時要選原因，原因分派車前、派車後、行程中與管理員取消。已完成簽名確認的訂單，司機端不能再取消。
車隊要換調度系統，應該從哪裡開始？
先從預約單開始。請調度照常記一段時間個案、地址、輪椅與陪同、去回程這幾個欄位，看哪些常常空白、哪些寫法最亂，摸清楚之後再決定調度台要做成什麼樣子。
這個案例實際用的技術：ASP.NET Core（.NET 8）、SQL Server、Vue 3、AG-Grid、LINE、Android、Google Maps。技術跟著問題走，不是重點。