M3 — 供需媒合與排程

M3-matching-scheduling 流程圖

流程概述

把搭乘需求分配給對的司機和車輛。依場景不同有「搶單」和「指派」兩種主要模式。

觸發時機：M2 完成（需求已建立、價格已確認）
執行角色：司機自主（C2C 搶單）/ 管理員（B2B 指派）
產出結果：行程確立，司機與車輛已綁定，通知已排程

Happy Path

步驟 1：需求聚合

判斷哪些需求可以合併為同一趟行程。

場景	做法
C2C 共乘	系統使用 BestFlow 演算法計算最佳共乘組合（4 種路線排列取最優解），價格依合併後的路線重新分配
B2B 接駁	管理員手動選擇同日期、同方向的需求，組成一條路線

若無可合併的需求，則作為單趟行程進入下一步。

步驟 2：路線規劃

場景	做法
C2C	Google Maps 即時計算路線（單趟或共乘合併路線）
B2B	路線最佳化引擎計算最佳站點順序

B2B 路線最佳化細節：

管理員可選擇策略：最短時間 / 最短距離 / 平衡 / 成本最佳 / 容量最佳
系統非同步處理，依站點數量動態調整計算時間：

站點數	預估計算時間
≤ 3 站	約 1 秒
≤ 6 站	約 3 秒
≤ 10 站	約 10 秒
> 10 站	約 30 秒

產出內容：站點順序、每站預計到達時間、每段距離與行車時間、總距離與總時間

步驟 3：資源匹配（司機 + 車輛）

依場景分為兩種模式：

搶單模式（C2C 為主）

行程發布到司機 App 的「可搶行程」列表
司機查看行程詳情（路線、時間、預估收入）
司機按下接單（進入暫時接單狀態，5 分鐘內需正式確認）
司機正式確認 → 行程綁定該司機
若無人接單超時 → 進入 Worst Case 處理

指派模式（B2B 為主）

管理員從可用車輛列表中選擇車輛（考慮座位容量、車輛狀態）
管理員從可用司機列表中選擇司機
將司機和車輛指派到該路線

步驟 4：行程確立

行程狀態更新為「已確立」
通知所有相關方：
- 乘客：行程確認、司機和車輛資訊
- 家長/監護人（若適用）：同上
- 司機：行程細節確認

步驟 5：進入通知時間軸

依服務方案設定，系統自動排程後續通知：

時間點	通知內容
前一天 20:00	行程資訊確認通知
每週一 15:00	週行程提醒
每週五 15:00	下週行程提醒
其他自訂時間	依服務方案設定觸發

→ 流程結束，等待行程執行日（進入 M4）

Worst Case

WC-1：無司機接單（C2C 搶單模式）

等待時間超過設定門檻
系統通知乘客「尚無司機接單」
乘客可選擇：
- 延長等待時間
- 取消行程（觸發退款）
若平台介入 → 管理員可強制派單（見 WC-2）

WC-2：管理員強制派單

搶單模式的 fallback 機制
管理員從可用司機中指定一位，強制接單
司機收到強制指派通知

WC-3：路線最佳化失敗（B2B）

最佳化引擎回傳錯誤
管理員可選擇：
- 重新提交最佳化計算
- 手動排序站點順序

WC-4：最佳化計算超時

計算時間超過 9 分鐘 → 任務自動取消
管理員可重新提交或調整站點數量後再試

WC-5：車輛容量不足

系統提示已選車輛座位數不夠
管理員可選擇：
- 更換較大車輛
- 拆分路線為兩趟行程

WC-6：司機臨時無法出勤

場景	處理方式
B2B 指派	管理員重新指派其他司機
C2C 搶單	行程重新進入搶單列表

WC-7：需求變更（取消或修改）

乘客取消或修改需求
系統重新計算路線和價格
通知受影響的其他乘客

WC-8：共乘價格重分配後有人不接受

共乘合併後，各乘客收到新價格通知
若有乘客不接受新價格 → 該乘客退出共乘
系統恢復該乘客為原始單趟狀態
剩餘共乘乘客的價格重新計算

WC-9：指派後車輛故障

司機或管理員回報車輛故障
管理員重新指派可用車輛
通知相關乘客車輛變更資訊

WC-10：通知發送失敗

系統啟動重試機制
重試間隔：10 分鐘 → 30 分鐘 → 60 分鐘
最多重試 3 次
3 次皆失敗 → 記錄異常，管理員可手動處理

相關子流程

子流程	說明
路線規劃與最佳化	BestFlow 共乘演算法、B2B 路線最佳化引擎
車隊管理	車輛與司機的可用性查詢、指派
共乘媒合	C2C 共乘組合計算、價格重分配
排程通知	行程確認通知、週期提醒排程

場景差異速查

項目	C2C 共乘	B2B 接駁	企業接駁	校車	旅遊包車
需求聚合	系統自動（BestFlow）	管理員手動	管理員手動	管理員手動	不適用（單趟）
路線規劃	Google Maps 即時	最佳化引擎	最佳化引擎	最佳化引擎	Google Maps 即時
資源匹配	搶單	指派	指派	指派	指派/搶單
通知對象	乘客、司機	乘客、家長、司機	乘客、司機	家長、司機	乘客、司機