全通路客服系統怎麼選?OMO 五步導入指南|Alta.DI

客戶從 LINE 換到官網後,為什麼還要重述需求?本文整理全通路客服系統的四層架構、五步導入流程與八項選型問題,協助企業規劃可衡量的 OMO 客戶旅程。

Alta.DI
發布日期
17 Apr 2026
05 Oct 2026
更新日期

客服人員剛回完 LINE,下一則官網訊息卻是同一位客戶追問同一筆訂單。因為兩個後台沒有共同紀錄,客服只能再問一次會員資料,客戶也得重新說明需求。

‍

這是許多企業都有的常見情境。問題不在於管道太少,而是顧客身分、對話紀錄、企業知識與轉真人流程沒有接續。全通路客服系統要處理的,正是客戶換管道後,服務能不能從原本的位置繼續。

‍

本文用四層架構、五個導入步驟與八項選型問題,說明企業如何規劃 OMO 客戶旅程,以及 Alta.DI 可以承接哪些環節。

‍

‍

全通路客服系統是什麼?和多通路客服差在哪裡?

‍

多通路客服解決的是「客戶能不能找到你」。企業可能同時經營 LINE、官網 LiveChat、Facebook Messenger、Instagram Direct、電子郵件與門市,但每個管道各有一套後台。客服人員看得到眼前訊息,卻不知道客戶昨天在別處問過什麼。

‍

全通路客服處理的是「換管道後能不能接續」。例如,客戶先在 LINE 詢問商品,隔天改到官網追問庫存;系統若能辨識為同一位客戶並保留前次對話,客服就不用要求對方重述需求。

‍

這裡要注意一條界線:訊息集中,不等於所有資料都已連通。若客戶走進門市,門市人員能否看到線上對話,仍取決於會員識別、CRM 或門市系統是否完成串接,不能只靠客服收件匣推定。

‍

OMO(Online-Merge-Offline)又比全通路客服多一層營運設計。線上互動要能引導到門市、預約或交易,線下行為也要能回到後續服務流程。全通路客服可以是 OMO 的服務入口,但 OMO 還包含會員、訂單、門市與行銷流程,兩者不能畫上等號。

‍

‍

為什麼只把訊息集中在一個後台仍不夠?

‍

全通路客服常見三個斷點:資料分散、重複處理成本與跨管道服務中斷。

‍

訊息集中可以減少客服切換視窗的時間,但企業還要處理三個問題:客戶從外部搜尋、社群或門市進來後,誰能辨識他、誰能接手,以及資料能不能安全地帶到下一步。

‍

Gartner 在 2025 年 1 月至 2 月調查 5,801 名客戶,發現 51% 的客服旅程從 Google、YouTube、ChatGPT 等第三方平台開始,而不是企業自有管道。[1] 官方新聞稿沒有列出受訪者的地區組成,Gartner 也以商業研究服務為業,因此這筆資料適合觀察跨平台服務行為,不能直接推論為台灣市場占比。

‍

較早的零售研究也能說明跨管道行為不是短期現象。Harvard Business Review 於 2017 年發表一項 46,000 名消費者研究,其中 73% 在購物旅程中使用多個管道。[2] 研究資料來自 2015 年 6 月至 2016 年 8 月、單一美國零售商,只能作為歷史基準,不能代表 2026 年台灣消費者現況。

‍

採購平台前,先回答前述三個問題。答案會決定身分識別、資料權限與服務流程怎麼接,也能避免企業買了一套功能很多的系統,第一線仍得複製貼上。

‍

‍

全通路客服系統要處理哪四層?

先把四層分開盤點,才不會把「收到訊息」誤認為「資料已整合」。

‍

全通路客服可拆成訊息入口、顧客與業務資料、企業知識、服務與轉交四層。每一層的資料來源、權限與維護方式不同,缺少其中一層,客戶換管道時仍可能遇到斷點。

‍

全通路客服四層架構:訊息入口、顧客與業務資料、企業知識、服務與轉交
層次 要處理的問題 盤點內容 驗收方式
① 訊息入口 客服能否在一致的工作介面接收與回覆訊息 LINE、LiveChat、社群、電子郵件等實際使用管道 用測試帳號完成收件、分派與回覆
② 顧客與業務資料 換管道後能否辨識身分並取得必要資料 識別欄位、訂單、會員資料、權限與串接條件 測試正確合併、錯誤修正與權限限制
③ 企業知識 AI 與真人是否依同一套核准內容回答 答案來源、適用範圍、負責人、更新與下架日期 測試同義問法、過期內容與知識庫無答案情境
④ 服務與轉交 Flow Bot、AI Bot 與真人如何分工及接手 轉交條件、對話摘要、待辦、例外與人工權限 從客戶提問一路測到案件完成

‍

第一層:訊息入口

‍

先列出客戶會從哪裡發出訊息,例如 LINE、官網 LiveChat、Facebook Messenger、Instagram Direct、WhatsApp 或電子郵件。這一層的目標,是讓客服在一致的工作介面接收、分派與回覆訊息。

‍

第二層:顧客身分與業務資料

‍

同一個人在 LINE、官網與門市可能有不同識別碼。企業要先定義用什麼資料比對身分,以及哪些人有權合併紀錄。訂單、會員等級、庫存或門市紀錄屬於另一組業務資料,能否查詢要看電商平台、CRM、POS 或其他系統的串接條件。

‍

第三層:企業知識

‍

AI 客服與真人客服應引用同一套已核准內容,包括商品規格、退換貨規則、運送方式與門市資訊。知識庫還要有負責人、更新日期與下架規則;否則舊答案即使回得快,仍會造成後續客訴。可先參考AI 客服知識庫建置方法,整理第一批適合上線的資料。

‍

第四層:服務與轉交流程

‍

企業要先寫清楚哪些問題由 Flow Bot 引導、哪些由 AI Bot 回答、哪些必須轉真人。轉交時至少要帶上顧客問題、已查過的資料與待辦事項,客服才能接續處理。退款、個資、例外折扣或客訴升級等情境,仍應保留人工判斷與權限控管。

‍

‍

全通路客服系統怎麼導入?五步完成 OMO 服務流程

先修好一段高頻旅程,再決定下一段要接什麼。

‍

步驟一:盤點接觸點,找出最常重述需求的環節

‍

列出客戶從提問到完成服務會經過的接觸點。每個接觸點記錄四件事:顧客提出什麼問題、使用哪個管道、需要查哪些資料、最後由誰完成。

‍

第一段旅程應選擇發生頻率高、交接次數多,而且能用既有資料驗證結果的情境。例如「詢問商品後預約門市體驗」比「一次整合所有會員行為」更容易界定起點與完成條件。

‍

步驟二:定義顧客識別與資料串接邊界

‍

把資料分成「客服平台已有」「其他系統可查」「目前不能使用」三類,再確認身分比對欄位、系統 API 條件、資料更新頻率,以及合併錯誤時如何拆回。

‍

這一步也要處理最小權限。客服可能需要查訂單狀態,但不一定需要看到完整付款資料;門市人員可能需要知道預約內容,卻不該讀取全部客訴紀錄。邊界寫清楚後,企業才知道哪些情境可以在第一階段承諾。

‍

步驟三:整理知識庫,訂出 AI 回答與轉真人規則

‍

先整理高頻、答案穩定、風險較低的問題,例如運費、配送範圍、營業時間與標準退換貨條件。每則內容要標示來源、適用範圍、核准者與更新時間,再用真實提問測試不同問法。

‍

AI 找不到核准知識時,不應自行補完。企業可以設定固定說明、要求客戶補充資料,或轉交真人。付款爭議、個資異動與例外承諾可直接進人工流程。若還不確定 Flow Bot、AI Bot 與真人客服如何分工,可先看AI 客服三種模式選型指南。

‍

步驟四:串接需要的管道,跑完一條 OMO 情境

‍

測試時不要只看 AI 能不能回答,而要從第一次提問一路走到完成:換管道後是否認得同一個人、資料是否正確、轉真人是否帶著脈絡,以及門市或後台是否收到待辦。

‍

以「線上詢問後預約門市」為例,完成條件可以是:客服取得門市與時段需求、建立預約、回傳確認訊息,並讓門市看到提問重點。若其中一步仍需人工複製貼上,就把它列為下一輪要處理的交接點,不必假設第一階段能全部自動完成。

‍

步驟五:比較上線前後指標,再決定擴充範圍

‍

客服層可追蹤首次回應時間、首次解決率、轉真人率與重複提問率;旅程層則依情境追蹤預約完成率、案件完成時間或跨管道重述比例。

‍

指標變動時,要回到對話紀錄找原因。轉真人率上升,可能是知識不足,也可能是規則成功攔下高風險問題;首次回應變快,也不等於問題已解決。若要建立共同判讀方式,可搭配顧客體驗指標整理定義資料來源與查看頻率。

‍

‍

選擇全通路客服平台時,先確認哪三件事?

‍

功能清單只能說明平台宣稱具備哪些能力,無法證明它能接上企業現有流程。第一輪評估先問三件事:

  1. 現有訊息管道是否支援? 不同方案是否有管道限制,是否能用測試帳號實際收發訊息。
  2. 客戶換管道後如何辨識? 系統依什麼資料判定為同一人,錯誤合併後能否修正。
  3. AI 不知道答案時怎麼處理? 找不到核准知識時,會顯示固定說明、要求補充資料,還是轉交真人。

這三題若答不清楚,先不要被報表數量、自動化比例或展示畫面帶走。它們分別決定訊息能不能進來、服務能不能接續,以及 AI 回覆是否可控。

‍

第二輪再檢查五項進階條件

  • 轉真人時會帶上哪些對話摘要、顧客資料與待辦?
  • 訂單、商品、CRM 或門市資料如何串接?標準整合與客製串接的邊界在哪裡?
  • 客服、主管、行銷與 IT 各自能看到什麼?操作與資料是否留下紀錄?
  • 報表能否同時看服務效率與旅程完成結果?資料能否匯出供後續分析?
  • 上線後由誰維護知識、規則與系統串接?調整時是否需要額外開發?

‍

要求廠商用你的測試資料跑完一段旅程,比看通用展示更有判斷力。測試至少要包含正常問題、模糊問法、知識庫沒有答案、需要查訂單及必須轉真人等情境。

‍

‍

Alta.DI 如何支援全通路 AI 客服?

‍

Alta.DI 是不被通路綁住的 AI 客服平台,將多個訊息管道、AI 回覆、顧客資料與真人客服流程放在同一個工作介面。企業仍需依現有系統確認身分識別與資料串接範圍。

‍

訊息管道方面,Alta.DI 可整合 LiveChat、LINE、Facebook Messenger 與 Instagram Direct;WhatsApp 從進階方案起提供。開店平台串接是另一件事,Shopify、Shopline/Shoplazza、WooCommerce/WordPress、TikTok Shop 用來連接商品與訂單資料,不能和訊息管道混為一談。

‍

服務流程方面,企業可依情境設定 Flow Bot、AI Bot 與真人客服。AI Bot 可從企業知識庫檢索答案;找不到知識時,可依自訂話術回覆或轉交真人。客戶標籤、畫像與分群可協助整理互動資料;自訂意圖、AI 對話標籤與增強訓練從進階方案起提供。

‍

這些功能能否形成 OMO,仍取決於資料與流程設計。門市、POS、CRM 或客製系統不會因接上客服管道就自動完成整合;OpenAPI 從進階方案起提供,但客製系統串接仍需依實際條件評估。可先查看Alta.DI AI 客服平台的公開功能,再用前一段的八項問題進行展示與測試。

‍

‍

全通路整合的成效要怎麼衡量?

‍

全通路整合應同時衡量服務效率、體驗連續性與旅程結果。單看 AI 回覆量或自動化比例,可能忽略客戶是否仍要重述需求,以及案件最後有沒有完成。

  • 服務效率:首次回應時間、平均處理時間、客服切換後台次數。
  • 體驗連續性:跨管道重述比例、轉真人後重問比例、同一案件的交接次數。
  • 旅程結果:依情境設定預約完成率、訂單查詢完成率、案件一次解決率或後續聯繫完成時間。

‍

每個指標都要有上線前基準、資料來源與檢視者。若目前沒有跨管道重述比例,可以先抽樣對話並標記;若預約結果分散在門市系統,先確認能否匯出。能穩定取得的普通指標,比看似完整卻無人維護的儀表板更有用。

‍

‍

結語:先選一段會中斷的旅程開始

‍

全通路整合的起點,是找出客戶在哪一次換管道時必須重述需求,再把那一段的身分、資料、知識與轉交流程接起來。完成一段可驗證的旅程後,再擴充到其他管道與情境。

‍

如果你正在評估全通路客服系統,可以準備一段真實客服旅程與現有系統清單,和 Data-DI 顧問一起盤點。顧問會先釐清資料與流程邊界,再確認 Alta.DI 適合承接哪些環節。立即預約全通路客服流程諮詢。

‍

‍

參考文獻

[1] Gartner。(2025.07)。Gartner Survey Finds More Than Half of Customer Service Journeys Now Start on Third-Party Platforms。Gartner Newsroom。
https://www.gartner.com/en/newsroom/press-releases/2025-07-23-gartner-survey-finds-more-than-half-of-customer-service-journeys-now-start-on-third-party-platforms

[2] Sopadjieva, E., Dholakia, U. M., and Benjamin, B.。(2017.01)。A Study of 46,000 Shoppers Shows That Omnichannel Retailing Works。Harvard Business Review。
https://hbr.org/2017/01/a-study-of-46000-shoppers-shows-that-omnichannel-retailing-works

常見問題
Q:全通路客服系統和多通路客服有什麼差別?
多通路客服讓客戶能從不同管道聯絡企業;全通路客服還要讓顧客身分、對話紀錄與服務流程在換管道後繼續,不必重新說明需求。
Q:企業導入全通路客服時,應從哪段旅程開始?
先選發生頻率高、交接次數多,而且能用既有資料確認結果的旅程,例如線上詢問後預約門市。完成一段後,再擴充到其他情境。
Q:現有 CRM 沒有標準 API,還能導入全通路客服嗎?
可以先整合訊息、知識庫與轉真人流程,再評估資料匯入或客製串接。能否即時查詢 CRM,仍要看版本、權限與現有系統條件。
Q:AI 客服找不到知識庫答案時應該怎麼處理?
系統應依預先設定的話術說明、要求客戶補充資料,或轉交真人,不應自行補完。付款爭議、個資異動與例外承諾可直接進人工流程。
Q:選擇全通路客服平台時,最先要確認什麼?
先確認現有訊息管道是否支援、系統如何辨識跨管道顧客,以及 AI 找不到答案時如何處理。這三項會直接影響服務能否接續與回覆是否可控。
< 上一頁
立即預約體驗
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.