台灣的客戶不離開 LINE。
他們在 LINE 上問問題、確認訂單、接收通知、甚至付款。但大多數官網和 LINE 官方帳號（LINE OA）之間沒有任何連結——你的客戶必須在兩個系統之間手動切換，而每一次切換都是一個流失點。
LINE OA 和官網的整合有三種主要架構，工程複雜度和適用場景差很多。這篇幫你釐清選哪個。
整合方式一：Webhook 推播通知
難度：低 / 適合：單向通知
最簡單的整合：官網發生事件（訂單成立、預約確認、表單送出），自動透過 LINE OA 推送訊息給客戶。
技術上就是：你的官網後端呼叫 LINE Messaging API，用客戶的 LINE User ID 發出訊息。前提是客戶曾經在 LINE OA 上按過「加好友」，才拿得到 User ID。
適合場景：
- 電商訂單確認、出貨通知
- 預約提醒（前一天自動推送）
- 表單送出的回覆確認
限制： 這是單向的，客戶收到訊息但沒辦法在 LINE 裡直接操作（例如改預約時間）。如果需要雙向互動，要搭配 Rich Menu 連回官網，或升級到下一種方式。
常見的坑： LINE User ID 不等於 LINE ID（那個類似 @username 的東西）。User ID 是每個人加入你的 OA 後才產生的 UID，不能自己猜。如果你沒有做過加好友流程設計，這個 ID 根本拿不到。
整合方式二：LIFF 嵌入式表單
難度：中 / 適合：把官網功能帶進 LINE
LIFF（LINE Front-end Framework）是把網頁直接嵌進 LINE 的技術。客戶在 LINE 裡點選單或連結，開啟的不是外部瀏覽器，而是一個在 LINE 內部跑的 web 視圖。
這讓你可以：
- 預約系統直接在 LINE 裡完成，不跳出去
- 填完表單自動拿到客戶的 LINE User ID 和 display name
- 結束後無縫回到 LINE 介面
適合場景：
- 服務業預約（美容、診所、餐廳）
- 活動報名、問卷
- 需要身份識別的流程（會員登入）
工程現實： LIFF 頁面本質上就是一個網頁，但有些限制要注意。Safari 的 cookie 限制在 LIFF 裡更嚴格，如果你的網站用 session 做登入驗證，很可能在 iOS 裡壞掉。另外 LIFF 視窗的高度是固定的，複雜的分頁介面體驗會很差。
開發一套完整的 LIFF 預約流程（含後台管理），從零開始大概是 4–8 週的工程量。
整合方式三：完整 CRM 串接
難度：高 / 適合：客戶旅程自動化
最完整的方案：LINE OA、官網、內部系統（CRM、ERP 或 Google Sheets）三方打通。
客戶在 LINE 傳訊息 → Webhook 觸發你的伺服器 → 判斷意圖（是在問庫存還是要改訂單）→ 呼叫你的後台 API → 回傳結果給客戶，全部自動化。
這個架構可以做到：
- 客戶在 LINE 直接查詢訂單狀態、剩餘點數
- 自動識別新客戶 vs 舊客戶，給出不同的回應
- 業務事件觸發 LINE 通知（付款過期、庫存不足）
- 對話記錄自動寫進 CRM
適合場景： 客戶量大、重複性互動多、有業務自動化需求的企業。
工程現實： 這不是一個外掛可以搞定的事，需要後端開發、API 設計、以及你願意把內部系統的資料暴露出來讓外部服務讀寫。整合工程量視系統複雜度從 2 個月到半年都有。搭配 Claude API 做意圖識別，可以讓自動回覆的理解能力大幅提升——但這也是多一層要維護的東西。
選哪個
不用追求最複雜的方案：
| 你的需求 | 建議方案 |
|---|---|
| 只想讓客戶收到通知 | Webhook 推播 |
| 想把預約 / 表單移進 LINE | LIFF 嵌入 |
| 想全面自動化客戶服務流程 | 完整 CRM 串接 |
大多數台灣中小企業從 Webhook + LIFF 的組合出發就夠了——推播通知覆蓋大多數的「告知客戶」需求，LIFF 把最高頻的流程（預約、報名）直接帶進 LINE。完整 CRM 串接留給你的業務量真的大到人工已經跟不上的時候再做。
從簡單的方案開始，先讓整合跑起來，再根據實際使用情況決定下一步，比一次規劃一個龐大系統然後半途放棄來得務實。