交屋後 LINE 報修淹沒客服？建商需要的是可追蹤的售後工單

能辨識新案、補件和重開案，保留住戶確認。

專題編輯：Sylvia Yeh｜人才發展與職場編輯

本文為文件研究與流程教學。情境、數字和工作表資料均為模擬，參考答案經本地規則或數值核對。未使用真實客戶資料，也未在企業系統或特定 AI 產品帳號實測。

住戶報修若停留在 LINE 對話，客服難以掌握分派、處理期限與修繕品質。把訊息轉為標準工單，再交由 AI 協助分類、彙整與提醒，才能留下完整售後服務紀錄。

交屋後第一個月，客服群組可能同時出現漏水、門鎖、油漆、保固期限、約工班等訊息。住戶以為「我已經告知」，客服以為「師傅已經接手」，工程端卻只看到一張沒有地址的照片。問題的核心不是訊息太多，而是每一次承諾都沒有明確的工單身分、責任人與結案標準。

先設計工單，不急著做聊天機器人

最小工單包含 case_id、建案、戶別或經安全識別的單位代碼、問題描述、必要圖片、受理時間、分類、優先級、責任人、承諾回覆時間、狀態與結案證據。住戶姓名、電話、門禁資訊不應任意出現在跨公司工班群組。系統可以從客服訊息產生「待確認工單」，但住戶身份、保固資格與實際施工地址要透過安全流程核實。

問題類型決定處理路徑

漏水與用電疑慮可能涉及安全，應轉專業人員優先評估；一般五金、外觀修補或預約服務則走標準排程。AI 依文字建議分類和缺漏欄位，不得依文字自行認定責任歸屬、法律保固成立與否或緊急危險已排除。對安全可能有影響的事件，保留人工緊急轉接與明確通知責任。

從受理到結案的六個狀態

RECEIVED 表示已收到；NEED_INFO 表示資料不足；ASSIGNED 表示有人接案；IN_PROGRESS 表示施工處理中；CUSTOMER_CONFIRM 表示等待住戶驗收；CLOSED 表示依內規完成結案。若住戶反映修繕後問題仍在，應回到 REOPENED，並保留原案歷史，不創造一個看似全新的工單以掩蓋重工。

SLA 如何避免變成漂亮數字

服務水準承諾要分清「首次回覆」「實際派工」「修復完成」，不能一個時限包辦所有事件。合約、保固條款與現場工作量會影響承諾內容。建議先公布可履行的內部目標並依建案調整；由 AI 提醒逾期與待回覆，不能直接對住戶承諾未經客服確認的期限。

一個月的成效應如何看

每週追蹤首響時間、中位處理天數、逾期未處理工單、重開件數、相同問題重複發生率與住戶確認率。若工單增加不代表品質變差，也可能是原本沒被記錄的問題開始被看見；應用相同口徑比較。先讓主管看見問題全貌，之後才考慮與建案維修、客服與行動裝置系統整合。

報修分流範例與客戶通知原則

客服收到「浴室天花板有水痕」時，不應自動回覆「一定是樓上漏水」。比較好的第一則回覆，是確認已建立工單與所需照片，並告知由誰在何時確認下一步。若有立即安全風險，使用建商既定的緊急聯繫與現場查核機制。對油漆修補、設備異音、衛浴排水等不同類型，分別列出必要資料與負責單位，避免讓客戶在不同窗口重複敘述。

把客服與工程拉到同一個結案定義

客服可能把「已約師傅」視為案件完成，工程卻認為「現場修復且確認沒有復發」才是完成。應明確區分預約、施工、完成、住戶確認與保固爭議處理。若客戶拒絕簽收，不表示客服可以無限期把工單留在同一狀態；可依契約及內規設立爭議處理與主管複核，但不能自行取消住戶主張。跨團隊一個 case_id 的價值，就在於每位角色都看得到同一段處理歷史。

工單驗收的負面測試

測試時刻意輸入四種訊息：「只說好像有問題」「兩張屬於不同戶別的照片」「同一住戶重複報修」「要求刪除先前誤傳的個人資料」。好的流程應分別要求補件、阻擋錯誤合併、關聯舊工單與啟動資料更正程序。若系統直接產出自信的故障原因，或把資料分享給不應接收的供應商，即使回覆速度再快，也不適合正式導入。

企業導入的下一步

建商可從客服與工程共同使用的售後工單原型開始，先確認權限、SLA 與結案責任。

下載工作表與核對範例

沒有足夠照片或戶別證據時保留補件狀態，住戶未確認時不可當作修繕結案。

下載模擬工作表與核對答案（ZIP）

參考資料

• 全國法規資料庫｜個人資料保護法
• NIST AI RMF Core

實際工程、旅客通知、合約或財會處理依適用規範、契約和具權責人員核定。