AI 原生 CRM 怎麼設計？電話、LINE、SMS、email 寫回同一條客戶時間軸｜2026 台灣實戰
TL;DR — LINE 在台灣 2024 年使用者達 2,200 萬、每日通話數達 1 億次（LINE 2024）。AI 原生 CRM 的關鍵，是讓電話、LINE、SMS、email 寫回同一條 contact timeline。
為什麼 AI 原生 CRM 不是把 AI 加到 CRM 上
多數 CRM 的歷史包袱，是把客戶資料當成「欄位」。姓名、電話、email、公司、銷售階段、下次跟進日期。這些欄位重要，但不足以支撐 AI 電話。
AI 電話真正需要的是「脈絡」。客戶剛剛在 LINE 問過什麼？上次電話是人接、未接、語音信箱，還是失敗？SMS 是否送達？email 報價單寄出後，對方有沒有回覆？如果這些事件散在不同工具裡，AI 電話每次開場都會像第一次見面。
這就是 AI 原生 CRM 的分水嶺。
舊式 CRM 是「先有資料庫，再把 AI 接上去」。AI 原生 CRM 是「每一次對話都先被設計成可寫回、可追蹤、可接力的資料」。電話、LINE、SMS、email 不是四套工具，而是同一個 contact timeline 的四種事件來源。
如果你想先看產品層怎麼把 AI 電話、聯絡人管理與自動化接起來，可以參考 Brightalk.ai AI 電話功能介紹；本文則專注在背後的資料設計。
「AI 電話不是一個獨立通路。它是客戶時間軸上的主動接觸層。」——這句話如果沒有資料模型支撐，就只是行銷話術。
4 個通路，各自該寫回什麼
跨通路 CRM 最常見的失敗，是只存「有發生過」。例如：有打電話、有發 SMS、有收到 LINE、有寄 email。這種紀錄只能證明系統動過，不能支撐下一步決策。
真正可用的 contact timeline，至少要把每個通路的事件、狀態與下一步分開保存。
| 通路 | 最少要寫回 | 沒寫回會壞在哪裡 |
|---|---|---|
| AI 電話 | outcome、逐字稿、摘要、錄音、下一步動作 | AI 下次不知道上次是否真的有效對話 |
| LINE | inbound/outbound、訊息內容、LINE 使用者對應 contact、是否可推播 | LINE 問過的問題無法接到電話腳本 |
| SMS | 內容、gateway message ID、sent/delivered/failed 狀態 | 系統以為提醒已送達，實際可能失敗 |
| thread、message、subject、direction、sent_at、附件狀態 | 報價、條款、同意文件散在收件匣裡 |
這四類資料的共通點，是都必須指向同一個 contact_id。沒有這個共同鍵，後面所有「AI 讀取客戶脈絡」「自動接續對話」「真人交接」都會變成人工整理。
✅ 判斷標準：一套 CRM 是否 AI 原生，不是看它有沒有 AI 按鈕，而是看同一名客戶的電話、LINE、SMS、email 能不能依時間排序，並被下一次 AI 或真人互動讀取。
LINE 在台灣不是附加通路，是主幹通路
台灣市場不能把 LINE 當成可有可無的聊天外掛。LINE 官方 2024 年公開資料顯示，LINE 在台灣使用者達 2,200 萬、每日通話數達 1 億次，電腦版使用者也超過 500 萬（LINE 2024）。對 SMB 來說，客戶在 LINE 問問題、傳截圖、改預約、確認地址，是日常流程，不是例外。
因此，AI 電話的跨通路設計至少要解決三件事。
第一，LINE user 要能對應到 CRM contact。LINE 的 line_user_id 是平台身份，不等於手機號碼，也不等於 CRM 裡的姓名。系統必須保留 line_user_mappings 這層，把 LINE 使用者與 contact 連起來；還沒連上的 LINE 使用者，也應該能在 CRM 裡等待人工或自動配對。
第二，LINE webhook 要能去重。LINE Developers 文件提醒，webhook redelivery 可能讓同一事件送達多次，應使用 webhookEventId 偵測重複（LINE Developers 2026）。如果沒有去重，客戶傳一則訊息，CRM 可能寫成兩則；AI 電話讀取 timeline 時就會誤判對話熱度。
第三，LINE 訊息要能即時更新。LINE 是即時通路，不是每日批次匯入。當客戶剛傳「我明天早上可以」時，AI 電話若 5 分鐘後外撥，就應該已經看到這句話。
⚠️ 常見錯誤：把 LINE 對話只放在 LINE 後台，不寫回 CRM。這會讓團隊看似有 LINE 客服，實際上 AI 電話與業務員都看不到那段客戶脈絡。
SMS 的價值不在長對話，而在狀態可靠
SMS 不適合承載長對話，但很適合做三件事：漏接後補一個短連結、預約前提醒、術後或會議後送確認資訊。它的優勢是不用安裝 app，也不依賴客戶是否已加入 LINE 官方帳號。
但 SMS 要能進 CRM，不能只存「發送成功」。至少要保存 gateway message ID，並透過 webhook 更新 sent、delivered、failed 三種狀態。狀態更新還要有 precedence，避免較晚到的舊 webhook 把 delivered 倒退成 sent。
這件事聽起來細，但它會直接影響自動化規則。
如果 SMS delivered，下一步可以等客戶點連結或回覆。若 SMS failed，系統應該改走 LINE 或 email，而不是盲等。如果 webhook 沒有寫回 contact timeline，AI 電話下次回撥時就不知道「我上次傳的簡訊其實沒送到」。
email 是正式文件通路，必須保留 thread
電話與 LINE 適合即時互動，email 則適合正式文件：報價單、條款、合約、術後注意事項、付款資訊。AI 原生 CRM 在處理 email 時，不能只把 email 當成一則 activity。它必須保存 thread 與 message。
Gmail API 提供 users.messages.send 送信端點（Google Developers 2025）；Microsoft Graph 也提供 sendMail 與 draft send 流程（Microsoft Learn 2025）。但對 CRM 來說，真正關鍵不是「能寄信」，而是寄出後能否記住：
- 這封信屬於哪一個 thread。
- 它對應哪一位 contact。
- direction 是 inbound 還是 outbound。
- 是否有附件。
- 最後一封訊息時間與摘要。
沒有 thread，email 會變成散落事件。AI 電話下次問「請問您收到我們昨天寄的文件了嗎？」時，系統就沒有可靠依據。
同一條時間軸的 5 個必存欄位
要讓 AI 與真人共用 customer context，每個事件至少需要 5 個欄位。
| 欄位 | 用途 | 範例 |
|---|---|---|
contact_id |
把事件綁回同一名客戶 | 同一人電話、LINE、SMS、email 共用 |
channel |
標記來源通路 | call、line、sms、email |
direction |
判斷客戶主動或企業主動 | inbound、outbound |
status/outcome |
決定下一步規則 | answered、no_answer、delivered、failed |
created_at/sent_at |
排序時間軸 | 依事件發生時間，不依匯入時間 |
進階一點，還會加上 summary、transcript、provider_message_id、thread_id、automation_run_id、source_call_id。但如果前面 5 個欄位沒有打穩，後面的 AI 分析都會建立在錯誤地基上。
這也是為什麼 AI 電話自動化與 outcome routing 不能孤立存在。routing 決定下一步，timeline 決定下一步是否知道過去發生過什麼。
醫美 inbound 場景：22:30 LINE 諮詢，到隔天電話回訪
痛點： 醫美診所晚上 22:30 仍會收到 LINE 諮詢。客戶問療程、改期、術後注意事項，但櫃台已下班。隔天早上真人或 AI 電話回撥時，如果看不到前一晚 LINE，開場就會變成「請問您想了解什麼？」客戶會覺得自己被當新客重跑一次流程。
AI 解法： 這是典型 inbound 流量：客戶先主動進 LINE，再由系統接住需求。LINE inbound 寫入 line_messages，對應到 contact；AI LINE 助理先回覆基本 FAQ，遇到診斷或療效問題則拒答並建立隔日回電任務。隔天 AI 電話回訪前讀取 contact timeline：昨晚問過哪個療程、是否點過預約連結、SMS 是否送達、email 是否已寄術後說明。
預期效益： 客戶不用重講。真人或 AI 都能從「接續昨晚 LINE 的問題」開始，而不是從零蒐集資料。完整醫美導入情境可參考 醫美 AI 電話導入實戰。
壽險 outbound 場景：電話篩選，到 LINE 補資料
痛點： 壽險團隊用 AI 電話做第一波名單篩選，但客戶常在電話中說「資料傳 LINE 給我」。如果電話紀錄、LINE 訊息與業務員後續拜訪分開，業務員只看到一個「有興趣」標籤，卻不知道客戶關心的是保障內容、付款方式，還是家人共同評估。
AI 解法： 這是典型 outbound 流量：團隊先用 AI 電話主動篩選名單，再把有意願的客戶接到後續通路。AI 電話 outcome 寫回 contact，摘要標記「要求 LINE 補資料」。系統觸發 LINE 或 SMS 接力，把指定文件連結送出；若客戶回覆問題，再寫回同一條 timeline。業務員接手前，看到的不只是 lead status，而是「電話問過什麼、LINE 補了什麼、哪一步需要真人說明」。
預期效益： AI 只處理名單篩選與第一波接觸，業務員保留專業說明責任。這條邊界也符合 保險業務員管理規則第 15 條 對親自說明的要求。更完整的壽險流程，可讀 壽險 AI 電話導入實戰。
AI 原生 CRM 的 4 個治理問題
跨通路寫回不是只為了方便。它其實是在回答 4 個治理問題。
| 治理問題 | 如果沒有 timeline | 有 timeline 之後 |
|---|---|---|
| 誰說過什麼 | 通話錄音、LINE、email 分散 | 依 contact 聚合，能回溯 |
| 下一步誰負責 | 每個通路各自派工 | automation 與任務接同一脈絡 |
| AI 能不能回答 | AI 只看當下輸入 | AI 可讀歷史摘要與拒答邊界 |
| 合規如何留痕 | 告知與同意散在不同紀錄 | 告知、錄音、轉交、文件都可稽核 |
這也是 AI 電話合規地圖 要和 CRM timeline 一起看的原因。個資法與通保法討論的是蒐集、告知、錄音與使用邊界；timeline 則是企業如何證明自己有照流程做。
常見錯誤：把 inbox 當 CRM
很多團隊第一版跨通路整合會做成 unified inbox。所有 LINE、email、SMS、電話都進同一個收件匣，看起來很漂亮，但不一定是 CRM。
inbox 解決的是「今天誰要回」。CRM timeline 解決的是「這個客戶一路發生過什麼」。兩者可以共存，但不能混為一談。
如果只做 inbox，會出現三個問題：
- 客戶歷史被 conversation 視角切碎。
- AI 電話只知道最新訊息，不知道完整關係。
- 自動化規則難以判斷長期狀態，例如 30 天內三次未接、兩次 SMS failed、一次 LINE 已讀未回。
💡 實務通則：先把事件寫進 contact timeline，再決定要不要顯示在 inbox。不要反過來，否則 CRM 會被收件匣的 UI 結構綁死。
建置順序：不要一開始就追求全通路完美
導入 AI 原生 CRM，建議照這個順序。
- 電話先寫回 timeline：每通電話至少有 outcome、summary、錄音或逐字稿連結。
- LINE user mapping：把 LINE 使用者與 contact 對上，處理未連結使用者。
- SMS delivery status：保存 message ID 與 delivered/failed，讓自動化知道訊息是否真的送達。
- email thread：把 Gmail/Outlook thread 對應 contact，正式文件不要散在個人信箱。
- AI 讀取 timeline 摘要：讓下一次 AI 電話、LINE 回覆或真人 handoff 讀同一份脈絡。
前四步是資料層，第五步才是 AI 層。順序不能反。資料沒有整理好，AI 只會更快地把錯誤脈絡放大。
✅ 快速行動：先挑 50 位真實客戶，把近 30 天電話、LINE、SMS、email 手動或半自動匯成同一條 timeline。你會立刻看出資料缺口在哪裡：通常不是 AI 不夠聰明，而是系統不知道哪個事件屬於哪個 contact。
FAQ
AI 原生 CRM 跟傳統 CRM 最大差別是什麼？
傳統 CRM 以欄位與銷售階段為中心；AI 原生 CRM 以對話事件與客戶脈絡為中心。它不只保存 contact 資料，也保存電話、LINE、SMS、email 在同一條時間軸上的互動紀錄，讓 AI 與真人都能接續。
LINE 訊息一定要寫回 CRM 嗎？
在台灣市場，建議要。LINE 是主流客戶通路，不寫回 CRM 會讓 AI 電話、業務員與客服看不到客戶真正的最新脈絡。尤其是預約、改期、術後關懷、文件補件，LINE 常常比電話更早發生。
SMS 已經很短，為什麼還要進 timeline？
因為 SMS 的價值在狀態。是否送達、是否失敗、是否已觸發下一步，會影響後續自動化。SMS 不寫回，系統就無法判斷該等待、改走 LINE，還是重新外撥。
email 要不要跟電話放在一起？
要，但不是把整封 email 貼進電話紀錄。正確做法是保存 thread、message、摘要與 contact 對應。電話負責即時溝通，email 負責正式文件；兩者放在同一條 timeline，才能支撐合規與後續追蹤。
這跟 AI 客服轉真人有什麼關係？
handoff 的品質取決於 timeline。真人接手時如果只收到一句「客戶有問題」，就會要求客戶重講；如果收到通話摘要、LINE 前文、SMS 狀態與 email thread，才是真正的 warm handoff。可搭配 AI 客服轉真人怎麼設計 一起看。
想看完整 AI 電話導入路徑、選型方法與產業案例？閱讀本系列的支柱長文 AI 電話行銷完整指南。