企業 AI 語音客服如何串接即時派單｜GoGoCha 技術案例

問題背景

長輩、旅客與企業客戶可能從電話、網站或 LINE 叫車。如果各入口分開保存任務，營運端就需要在不同介面核對資訊。這個案子的重點是讓入口接到共用派單後端，使司機、乘客與營運端能核對同一筆任務狀態，同時保留資訊不足時的人工介入。

實作方式

• —AI 電話入口負責收集叫車資訊，共用後端負責保存與派單；將對話與任務狀態分開，讓電話、網站與 LINE 能銜接同一套營運流程。
• —使用 Express、PostgreSQL、Redis、BullMQ 與 Socket.IO 建立即時派單後端。
• —網站車資試算先呼叫真實費率 API，失敗時以本地規則提供清楚的替代結果。
• —以大字級、語音優先與高對比方式處理長輩使用情境。

隼訊實際負責範圍

• 品牌官網與車資試算介面
• AI 電話接聽入口與任務資料結構
• SmartDispatcherV2 即時派單後端
• LINE Bot、司機／乘客 App 與營運後台整合

AI 接聽至派單的資料流

1. 01使用者由電話、網站或 LINE 提出叫車需求。
2. 02系統整理地點、聯絡與任務欄位，送入共用派單流程。
3. 03後端以 PostgreSQL 保存狀態、BullMQ 處理佇列，並透過 Redis／Socket.IO 即時同步。
4. 04司機端、乘客端與營運介面取得同一筆任務狀態。

限制、失敗降級與替代方式

• —AI 無法可靠確認地點、聯絡或任務資訊時，應由人工進一步確認，不能把模型猜測當成可執行的派單資料；本頁不宣稱所有來電都能無人處理。
• —網站費率 API 失敗時以本地規則提供替代估算，畫面須揭露估算依據與限制。替代結果不代表即時費率 API 成功，也不代表已完成叫車或取得正式報價。
• —佇列與即時通訊分層處理，避免單次連線問題直接等同任務消失。

證據如何核對

• ✓可由公開品牌網站核對電話、網站、LINE 與車資試算等入口。
• ✓公開 App 畫面與網站畫面用來證明跨入口產品範圍，不包含私人乘客或司機資料。
• ✓技術架構來自隼訊實際負責範圍；未公開營運量、接通率、節省工時或正式 SLA。

可公開的量測與能力