LINE Webhook與Bot自動回覆教學：事件接收、訊息回覆與商家應用完整

如果你想建立 LINE Webhook 與 Bot 自動回覆，建議先完成官方帳號與 Messaging API Channel 設定，再準備可公開存取的 HTTPS 伺服器，讓 LINE 能把使用者事件送到你的 Webhook URL。本文會整理事件接收、訊息回覆、測試上線、安全驗證與商家客服應用，幫你從基礎流程開始建立可維護的 LINE Bot。

基礎概念

Webhook是事件入口

LINE Webhook 可以理解成官方帳號和你的系統之間的通知入口。當使用者加入好友、傳訊息、點選互動內容或解除好友時，LINE 平台會把相關事件送到你設定的 Webhook URL。你的伺服器收到事件後，再決定要回覆文字、圖片、選單，或把資料交給客服系統處理。沒有 Webhook，Bot 就很難知道使用者剛剛做了什麼。

Bot不是只有聊天機器人

很多人提到 LINE Bot，就以為一定是能自由聊天的 AI 機器人。實際上，Bot 可以很簡單，也可以很複雜。簡單版本可能只是關鍵字自動回覆，例如輸入「地址」回門市地址；進階版本則能查訂單、預約、分眾、推播、串接會員資料或轉人工客服。新手不必一開始做大型系統，先把事件接收與固定回覆打通，會更穩。

官方帳號是使用者入口

使用者不是直接操作你的程式，而是在 LINE 官方帳號聊天室中傳訊息、點圖文選單或接收通知。因此，Webhook 和 Bot 的設計要回到官方帳號使用體驗。若官方帳號名稱、歡迎訊息、圖文選單與客服流程都不清楚，即使技術串接成功，使用者仍可能不知道怎麼使用。若你還在建立帳號基礎，可先參考 LINE官方帳號入門教學。

建置準備

先準備開發者後台

建立 LINE Webhook 前，需要進入 LINE Developers 後台建立 Provider 與 Messaging API Channel。Provider 可以理解為公司或開發者單位，Channel 則是實際應用設定。你需要在 Channel 裡取得 Channel Secret、Channel Access Token，並設定 Webhook URL。新手可以先閱讀 LINE Messaging API官方總覽，理解整體架構再操作。

準備可連線伺服器

Webhook URL 需要是外部能存取的 HTTPS 網址，這代表你的程式不能只在本機端完全封閉執行。測試時可以使用雲端主機、Serverless 平台或暫時測試工具；正式上線則建議用穩定伺服器。若伺服器不穩，LINE 送來的事件就可能收不到，使用者傳訊息後也得不到回覆。Webhook 的可靠性，直接影響客服體驗。

確認官方帳號模式設定

官方帳號若同時有手動聊天、自動回覆、Bot 回覆等設定，可能會影響使用者看到的回應。開發前請先確認目前回覆方式，是要完全交給 Bot，還是 Bot 先分流、人工客服再接手。若設定混亂，可能出現同一則訊息被自動回覆和人工回覆重複處理，或使用者輸入後完全沒有反應。技術串接前，營運規則要先說清楚。

Webhook設定

填入Webhook網址

在 LINE Developers Console 中，你需要把自己的 Webhook URL 填入 Messaging API Channel 設定裡。網址必須能被 LINE 平台公開存取，且通常需要 HTTPS。填入後可以使用後台驗證功能測試是否可連線。若驗證失敗，不要只改程式碼，先確認網址是否正確、伺服器是否啟動、SSL 憑證是否正常、防火牆是否阻擋，以及路由是否能接收 POST 請求。

啟用Webhook接收事件

填入 URL 之後，還要確認 Webhook 功能本身已啟用。若沒有啟用，即使網址填對，使用者傳訊息時事件也不會送到你的伺服器。新手常見錯誤是設定了 URL、驗證也通過，卻忘記開啟 Use webhook。建議設定後用自己的 LINE 帳號加入官方帳號，傳送一則測試訊息，再查看伺服器日誌是否收到事件。

驗證失敗先看日誌

Webhook 驗證失敗時，伺服器日誌是最重要的排查工具。若日誌完全沒有請求，表示 LINE 的請求沒有打到你的伺服器，問題可能在網址、DNS、HTTPS 或防火牆；若有請求但回應錯誤，才是程式邏輯或回應格式問題。LINE 官方提供 Webhook URL驗證說明，新手可以依照官方流程逐層排查。

事件接收

訊息事件最常見

最常見的 Webhook 事件，是使用者傳送文字、圖片、貼圖、位置或其他訊息。對新手來說，建議先處理文字訊息，因為最容易理解與測試。當使用者輸入「營業時間」，系統回覆時間；輸入「地址」，系統回覆地圖連結；輸入「客服」，系統回覆人工服務時段。等文字事件穩定後，再處理圖片、檔案與其他複雜內容。

加入好友事件可做導覽

使用者加入官方帳號好友時，LINE 也可能送出相關事件。這個時機很適合回傳歡迎訊息、圖文選單導覽、常見問題入口或新好友優惠。不要浪費第一次互動，因為使用者剛加入時最願意了解帳號能做什麼。歡迎流程應簡短清楚，告訴他可以查詢、預約、領取資料或聯絡客服，而不是只說一句謝謝加入。

取消好友也能做觀察

使用者封鎖或取消官方帳號時，系統也可能收到相關事件。雖然你不應該打擾已離開的使用者，但這類事件可以作為營運觀察。若某次推播後大量取消好友，代表內容可能太頻繁、太廣告或不符合需求。Webhook 事件不只是技術資料，也是官方帳號經營的反饋。把技術事件和營運數據結合，才能持續優化內容。

回覆邏輯

Reply適合即時回覆

Reply Message 適合在使用者傳訊息後立即回應。例如使用者問地址、價格、預約方式、客服時間，系統可以根據關鍵字回覆對應內容。Reply 的重點是回應當下的使用者需求，因此內容要簡短、準確、可行動。LINE 官方的 傳送訊息官方說明 整理了回覆與主動發送等訊息方式，適合新手查閱。

Push適合主動通知

Push Message 適合主動發送通知，例如訂單狀態、預約提醒、課程通知、付款成功、售後進度。不過主動通知要非常謹慎，因為它直接出現在使用者 LINE 裡，若內容不相關或頻率太高，很容易造成封鎖。建議只發真正與使用者有關的訊息，而不是把 Push 當成無限制廣告工具。主動訊息越精準，使用者接受度越高。

預設回覆不能省略

使用者不一定會按照你設計的關鍵字輸入，可能打錯字、傳貼圖、輸入長句或問完全不同的問題。因此 Bot 必須設計預設回覆，例如「目前我可以協助查詢營業時間、地址、預約與客服，請點下方選單」。如果沒有預設回覆，使用者輸入非關鍵字時就會覺得系統壞掉。好的 Bot 不是只回答標準問題，也要處理不標準輸入。

關鍵字回覆

從高頻問題開始做

新手建立 Bot 時，不需要一開始處理所有問題。先整理客服最常被問的五到十個問題，例如地址、營業時間、價格、預約、付款、退換、課程資訊。這些問題最適合用關鍵字回覆解決。若每天都有相同問題被問十幾次，自動回覆就能節省客服時間，也讓使用者更快取得答案。低頻複雜問題則保留人工處理。

關鍵字要包含同義詞

使用者不一定輸入你預設的詞。有人會打「地址」，有人打「在哪」「位置」「怎麼去」；有人打「價格」，有人打「多少錢」「費用」「報價」。若只設定一個關鍵字，Bot 很容易判斷不到。建議針對每個問題整理常見同義詞，或設計選單讓使用者點選。文字輸入越自由，就越需要考慮不同說法。

回答要保留人工入口

關鍵字回覆可以解決基本問題，但不應完全取代真人客服。每則自動回覆中可以放一句簡短提示，例如「若需要人工協助，請輸入客服」。這樣使用者遇到特殊情況時，不會被困在自動回覆裡。對商家來說，Bot 的角色是分流，不是拒絕服務。自動化越完善，人工越應該集中處理真正需要判斷的問題。

選單設計

圖文選單放常用入口

Rich Menu 是 LINE Bot 很重要的操作入口，可以把常用功能放在聊天室底部。新手可以先放六個以內按鈕，例如預約、查詢、客服、活動、網站、常見問題。按鈕越清楚，使用者越容易使用。若你正在做商家官方帳號曝光與承接，也可以參考 LINE官方帳號提升曝光教學，把導流和選單一起規劃。

選單按下後要有結果

圖文選單的每個按鈕都應該有明確結果。使用者點「預約」後應看到預約入口，點「客服」後應知道人工服務時間，點「常見問題」後應看到問題清單。不要讓按鈕只是漂亮圖片，點下去卻沒有回應或連到錯誤頁面。選單是使用者和 Bot 互動的導航，如果導航失效，整個官方帳號體驗會變差。

不同角色可設不同選單

進階應用中，可以根據使用者狀態顯示不同選單。新客看到品牌介紹與常見問題，會員看到點數和回購入口，已預約者看到改期與取消選項，售後中的顧客看到進度查詢。這需要後端資料、標籤或使用者狀態配合。新手可以先做通用選單，等資料穩定後再逐步分眾，避免一開始流程過度複雜。

客服分流

Bot先處理簡單問題

客服分流的基本思路，是讓 Bot 處理重複且明確的問題，把人工客服留給需要判斷的情境。像地址、營業時間、價格範圍、預約入口、退換規則，都適合自動回覆；而客訴、特殊折扣、複雜售後、個案協調，則應轉人工。若所有問題都交給人工，客服壓力大；若所有問題都交給 Bot，使用者可能覺得被冷落。

人工客服入口要明顯

很多 Bot 體驗差，不是因為自動回覆太少，而是找不到人工入口。使用者已經試了幾次，仍然只收到固定答案，就會失去耐心。建議在常見問題回覆中保留「轉人工客服」選項，並說明服務時間。若非服務時間，也要回覆何時會處理。讓使用者知道有人會接手，比一直收到無法解決的自動回覆更好。

客服接手要看到前文

當人工客服接手時，最好能看到使用者剛剛點了什麼選單、輸入了什麼問題、系統回了什麼內容。若客服完全不知道前文，就會重複詢問，讓使用者覺得浪費時間。設計 Bot 時，可以把關鍵事件記錄到後台，或在對話中保留清楚脈絡。自動化和人工不是分開的兩套流程，而應該彼此銜接。

商家應用

預約服務適合Bot流程

美容、健身、診所、課程、餐廳都很適合用 LINE Bot 做預約流程。使用者可以點選服務項目、選擇時間、留下聯絡資料，再收到確認訊息。新手不一定要一開始串接完整排班系統，可以先用表單或固定回覆方式收集需求。等預約量增加後，再接日曆、資料庫或內部系統。預約流程要簡單，否則使用者仍會回頭找人工。

訂單通知提升信任

電商或服務型商家可以透過 Bot 發送訂單成立、付款成功、出貨通知、取貨提醒、售後進度等訊息。這類訊息和使用者需求高度相關，比一般促銷更容易被接受。通知內容要簡潔明確，包含訂單狀態、下一步和客服入口。不要把每則訂單通知都塞滿廣告，否則使用者會覺得官方帳號不專業。

活動報名可自動確認

活動、講座、課程、展覽或試用體驗，都可以用 LINE Bot 協助報名與確認。使用者填寫資料後，系統自動回覆報名成功、活動時間、地點、注意事項與提醒。活動前一天再發提醒，可以降低忘記出席的情況。若活動人數較多，自動化能大幅減少人工確認成本，也能讓參加者覺得流程更清楚。

資料記錄

記錄使用者意圖

Webhook 事件不只是用來回覆，也能用來記錄使用者意圖。例如使用者輸入價格、點預約、查看某類商品，就代表他對特定內容有興趣。這些資料可以用於後續分眾、客服跟進與內容優化。若你只是回覆完就丟掉事件資料，就浪費了 Bot 的經營價值。當然，資料記錄要符合實際需要，不要收集過多無用資訊。

搭配標籤做分眾

Bot 可以根據使用者行為加上標籤，例如點過課程選單、詢問售後、提交預約、查看優惠。這些標籤日後能幫助推播更精準。若你還沒建立標籤架構，可以先閱讀 LINE分眾標籤經營教學，再把 Bot 行為和標籤邏輯接起來。標籤越準，後續訊息越不容易打擾。

避免保存過多敏感資料

LINE Bot 可能會接觸使用者訊息、電話、訂單、預約、地址或其他資料，但不代表全部都應永久保存。資料保存要有明確目的，只保留服務需要的資訊。若涉及付款、醫療、身分、合約或個資，應使用更安全的資料流程，不要只放在聊天紀錄或未加密資料庫裡。Bot 越深入業務，資料安全責任越高。

安全驗證

Webhook請求要驗證來源

正式上線時，Webhook 不能只要收到請求就處理，應驗證請求是否真的來自 LINE。LINE 官方提供 Webhook signature 驗證機制，要求伺服器在處理事件前確認請求標頭與簽章是否正確。可參考 LINE Webhook簽章驗證說明。若不驗證來源，可能被惡意請求污染資料或觸發錯誤流程。

Access Token不要外洩

Channel Access Token 是呼叫 LINE API 的重要憑證，不應放在前端程式、公開 GitHub、截圖、文章或群組訊息中。正式專案應使用環境變數、密鑰管理或後端安全配置保存。若 Token 外洩，應立即重新產生並更新伺服器。很多安全事故不是程式碼錯，而是密鑰管理不當造成。新手開發時要從一開始養成正確習慣。

錯誤訊息不要暴露機密

Webhook 或 API 出錯時，伺服器不應直接把完整錯誤、Token、資料庫資訊或系統路徑回傳給使用者。錯誤訊息要對外簡潔，內部詳細資訊則放在日誌中。比如使用者看到「目前系統忙碌，請稍後再試」，管理者後台則看到真正錯誤原因。這樣既能保護系統資訊，也不會讓使用者看到難懂的技術內容。

測試流程

先用測試Channel驗證

正式品牌帳號上線前，建議先用測試 Channel 驗證流程。你可以建立測試官方帳號，測試加入好友、傳訊息、點選單、轉人工、錯誤回覆與伺服器重啟。不要一開始就在正式帳號上測試未完成流程，否則真正顧客可能收到奇怪回覆。測試環境能讓開發者放心調整，也能讓客服和行銷一起確認內容是否合理。

測試不只看成功案例

測試 Bot 時，不要只輸入標準關鍵字看成功回覆，也要測試錯字、空訊息、貼圖、圖片、長句、無關問題、重複點選、連續快速傳訊息等情況。真實使用者不會完全照你的腳本操作。若 Bot 只能處理標準輸入，正式上線後會出現很多無回應情況。把例外情境測過，使用者體驗會穩定很多。

上線後持續看日誌

Bot 上線後仍然要看日誌，觀察是否有大量錯誤、某些事件沒有處理、某個關鍵字常出現但沒有對應回覆。日誌能反映真實使用者怎麼和你的官方帳號互動。每週整理一次高頻問題，可以把它們加進自動回覆或圖文選單。Webhook 不是寫完就不管，持續觀察才能讓 Bot 越來越好用。

常見錯誤

Webhook驗證通過但沒回覆

Webhook 驗證通過，只代表 LINE 能連到你的伺服器，不代表你的程式已正確處理使用者訊息。若使用者傳訊息沒有回覆，可能是事件沒有解析、reply token 沒使用、Access Token 錯誤、回覆 API 呼叫失敗，或程式邏輯沒有匹配到關鍵字。排查時要看完整流程：事件是否收到、程式是否判斷、API 是否成功送出。

只做關鍵字沒有選單

只靠關鍵字回覆，使用者不一定知道該輸入什麼。建議搭配圖文選單、快速回覆或常見問題入口，讓使用者用點選方式開始互動。關鍵字適合補充，但選單能降低學習成本。若你只告訴使用者「請輸入關鍵字」，很多人會不知道從哪裡開始。好用的 Bot 通常是選單與文字輸入一起設計，而不是只靠其中一種。

沒有轉人工造成卡關

Bot 若沒有人工客服入口，使用者遇到複雜問題時就會卡住。常見情況是使用者連續問幾次，系統都回覆相同內容，最後直接封鎖官方帳號。任何 Bot 都應該設計「無法解決時的下一步」，例如輸入客服、留下問題、工作時間人工回覆。自動化的目標是提升效率，不是把使用者困在機器流程裡。

上線維護

版本更新要先測試

每次修改 Webhook 程式、圖文選單、回覆內容或 API 設定，都應先測試再上線。尤其是涉及訂單、預約、付款或會員資料的功能，更不能直接在正式環境試。建議建立測試環境、測試帳號和基本檢查清單。小改動也可能造成大影響，例如回覆格式錯誤、連結失效、Token 設定錯誤，都可能讓使用者無法完成流程。

活動結束要更新回覆

Bot 常會配合活動使用，例如輸入活動關鍵字取得報名連結、領取優惠或查看規則。活動結束後，相關回覆要及時更新，避免使用者點到過期頁面。圖文選單、關鍵字回覆、歡迎訊息和推播連結都要檢查。很多官方帳號體驗變差，不是因為技術壞了，而是舊活動內容沒有清理，導致使用者看到過期資訊。

客服回饋要反向優化

客服人員每天最清楚使用者卡在哪裡。若很多人問同一件事，表示 Bot 回覆、圖文選單或網站內容需要優化。開發者不應只看程式是否正常，也要定期和客服確認常見問題。把客服回饋加入 Bot 迭代，能讓自動回覆越來越貼近真實需求。LINE Bot 維護不是工程師單獨完成，而是營運和開發一起做。

應用進階

會員系統可串接資料庫

當基礎 Webhook 和回覆流程穩定後，可以考慮串接會員系統。使用者透過 LINE 查詢點數、訂單、課程、預約或售後狀態，系統根據 user ID 找到對應資料，再回傳結果。這類功能價值很高，但也需要更嚴謹的資料安全、身份驗證與錯誤處理。不要把敏感會員資料直接暴露在簡單回覆裡，必須確認使用者身份與權限。

Flex Message提升呈現效果

Flex Message 可以讓訊息呈現更像卡片，例如商品列表、課程選項、訂單摘要、活動資訊。相比純文字，它更適合展示結構化內容。不過 Flex Message 設計要簡潔，按鈕和資訊不要太多，否則手機畫面會很擠。建議先用純文字與簡單按鈕驗證流程，再把最常用、最有商業價值的內容升級成 Flex Message。

分眾推播串接行為資料

進階 Bot 可以根據使用者點選選單、查看內容、提交表單或購買行為，更新標籤和分眾資料。這樣後續推播就能更精準，例如只對看過課程的人發開課通知，只對購買過的人發回購提醒。這類應用能提高官方帳號經營效率，但前提是資料來源準確、標籤規則清楚。若標籤混亂，分眾推播反而可能發錯內容。

重點整理

LINE Webhook先打通主流程

LINE Webhook 新手入門，最重要的是先打通主流程：官方帳號收到使用者訊息，LINE 把事件送到 Webhook，伺服器解析事件，再用 Reply Message 回覆。這個流程穩定後，再加上關鍵字、圖文選單、Push Message、Flex Message 和分眾標籤。先從小功能開始成功，比一開始做複雜 Bot 更可靠。

Bot設計要回到客服需求

LINE Bot 不是為了展示技術，而是為了解決使用者和客服的實際問題。最適合先自動化的，是高頻、明確、重複的問題；最不適合完全自動化的，是需要情緒理解、判斷或個案處理的問題。好的 Bot 能先分流，再讓人工客服接住複雜問題。技術和客服流程一起設計，官方帳號才會真正好用。

安全與維護不能省略

正式上線後，請務必做好 Webhook 簽章驗證、Access Token 保護、日誌監控、錯誤處理、資料最小化保存與版本測試。LINE Webhook 直接連接使用者訊息和你的系統，安全與穩定性都很重要。Bot 不是寫完一次就結束，而是隨著活動、客服問題、使用者行為和業務流程持續更新。