LINE Bot 是什麼？跟官方帳號差在哪、四種做法怎麼選

作者｜瞻新資訊　張安邦執行長（台大醫工背景・十年以上IT服務公司創辦人）

「我想做一個 LINE 客服機器人。」

這句話我們大概聽過上百次。接下來的對話通常是這樣：問對方希望機器人幫忙處理什麼，答案是「就……回答客戶問題啊」；再問是哪些問題，對方會停頓幾秒，然後說「我要回去看一下」。

這不是客戶的問題，是 LINE Bot 這個詞本身太模糊造成的。它同時被用來指「後台設定的關鍵字自動回覆」、「別人家的月租客服工具」，還有「串接自家訂單系統的客製程式」——這三件事的成本差了幾十倍，能做的事也完全不同。

這篇文章的目的很單純：先把 LINE Bot 到底是什麼講清楚，再把四種做法攤開來比，讓你在找廠商報價之前，就知道自己該問哪一種。

LINE Bot 是什麼？官方帳號是門面，Bot 是背後的大腦

先講結論：LINE Bot 不是一個獨立的產品，它是建立在 LINE 官方帳號之上的自動化程式。

用實體店面來想會比較清楚。LINE 官方帳號是你的店面——有招牌、有門牌號碼（也就是那個帳號 ID）、客人可以走進來跟你說話。而 LINE Bot 是店裡那位服務生：客人開口問什麼，它負責判斷、去後面查資料、再回來回答。

沒有店面，服務生沒地方站。所以要做 LINE Bot，第一步一定是先有 LINE 官方帳號，這兩者不是二選一的關係。

技術上，讓官方帳號長出「大腦」的那條通道叫做 Messaging API。依 LINE Developers 官方文件說明，當使用者做了某件事——傳訊息、加好友、點選單——LINE 平台會把這個「事件」用 HTTPS POST 送到你設定的網址（webhook URL），你的程式收到之後判斷該怎麼處理，再透過 API 把回覆送回去。

這一來一回就是 LINE Bot 的全部運作原理。至於憑證怎麼申請、事件怎麼解析這些技術細節，我們在LINE Messaging API 的專篇裡拆得更細，這裡先把重點放在商業判斷上。

LINE Bot 跟 LINE 官方帳號，到底差在哪

這是最常被搞混的一組概念，直接用表格對照：

比較項目	LINE 官方帳號	LINE Bot
本質	企業在 LINE 上的帳號實體	掛在該帳號背後的自動化程式
能不能單獨存在	可以，不做任何自動化也能用	不行，必須依附在官方帳號上
誰在回覆訊息	真人小編，或後台預設的固定回覆	程式判斷後動態產生回覆
能不能查資料庫	不行	可以，這是它最大的價值
建立方式	官方後台申請、填資料	需要開發（或使用第三方工具）
費用來源	方案月費＋超額訊息費	開發或工具費用，另計

看完表格，有一個判準可以立刻拿來用：如果你要的功能需要「查東西」，那就一定要 Bot；如果只是「講固定的話」，官方帳號後台就夠了。

「客戶問營業時間，自動回一段文字」——這是固定的話，後台就能做。 「客戶問我的訂單到哪了，自動去訂單系統查出狀態回覆」——這要查東西，非 Bot 不可。

很多企業花錢做了 Bot，最後只拿來回覆固定文字，那筆開發費其實是白花的。

LINE Bot 能接手哪些工作

把 Bot 想成一位不會累、不會下班、但只會做你教過的事的員工，比較容易抓到它的能力邊界。

實務上比較常見、也真的有效益的應用有這幾類：

• 重複問題的自動應答：營業時間、地址、退換貨政策、常見規格問題。這類問題佔掉客服大量時間，但答案永遠一樣。
• 自助查詢：訂單進度、會員點數、預約時段、報名狀態。這是 Bot 相對於後台自動回覆的關鍵差異——它能接上你自己的系統，把答案「查」出來。
• 表單與流程收集：報名、預約、叫修申請。用對話一步步問完，比丟一個網頁表單連結給客戶的完成率高。
• 狀態通知：訂單出貨、預約提醒、繳費期限。這類是主動推播，成本結構跟前面三種不一樣，下一節會講。
• 選單導引：搭配圖文選單把常用功能做成按鈕，減少客戶打字。

反過來，有幾件事 Bot 做不好，不要硬塞給它：需要判斷語氣、安撫情緒的客訴處理；規格複雜、要來回釐清需求的售前諮詢；還有任何「答錯了會出事」的情境——例如報價、醫療建議、法律說明。這些場合 Bot 頂多做到把人接到真人手上，不該讓它自己回答。

費用怎麼算？關鍵是「計費看人數，不是看則數」

這一節是全篇最值得慢慢看的部分，因為多數企業高估了 LINE Bot 的訊息成本，原因是把計費規則想錯了。

先看方案本身

LINE 官方帳號在台灣目前分三種方案，依 LINE Biz-Solutions 官方 FAQ 公告：

方案	月費	每月免費訊息則數	超額加購
輕用量	0 元	200 則	不可加購
中用量	800 元	3,000 則	不可加購，須升級方案
高用量	1,200 元	6,000 則	可加購，每則 0.2 元起

以上為 LINE 官方公告的方案架構，實際金額與額度會隨官方調整而變動，規劃前請以 LINE 官方當下公告為準，本文數字僅供理解計價結構之用。

另外要注意：中用量方案額度用完不能加購，只能升級。如果推播量抓不準，卡在中用量會很尷尬。

再看哪些訊息會計費

這才是重點。依 LINE Developers 官方計費文件說明：

• 會計入額度的：push（單發推播）、multicast（多人推播）、broadcast（全體群發）、narrowcast（分眾推播）
• 完全不計入額度的：reply message，也就是使用者先開口、Bot 回覆的那一則

還有兩個容易被忽略的細節：

第一，計算單位是「送達了幾個人」，不是「發了幾則訊息」。官方文件講得很直接：同一次請求裡塞四個訊息物件、發給五個人，計為五則，不是二十則。所以一次回覆裡放文字＋圖片＋按鈕，成本跟只放一句話一樣。

第二，送給已封鎖你的帳號、或不存在的 user ID，不計入額度。收不到的訊息不算數。

這件事會反過來決定你的系統怎麼設計

把上面兩段合起來看，會得到一個對成本影響極大的結論：

LINE Bot 的訊息成本，不是由「你有幾個好友」決定的，是由「你主動找他們幾次」決定的。

同樣一套功能，設計成「等使用者問、Bot 回答」，訊息成本趨近於零；設計成「定期主動推播提醒」，成本就隨名單規模線性上升。這是架構決策，不是預算問題。

舉個實際的例子。假設你有一萬名好友，想讓他們能查訂單狀態。兩種做法：

• 做法一：客戶想查的時候自己在 LINE 裡問，Bot 回覆。這是 reply，一毛錢額度都不佔，一萬人查十次也一樣。
• 做法二：每天主動推播一次「您的訂單狀態更新」。一萬人一次就是一萬則，高用量方案的 6,000 則額度當天就爆掉。

功能看起來一樣，成本差距是無限大跟零的差別。

想更細看報價單怎麼拆，我們另外寫過一篇LINE Bot 開發費用怎麼算，把開發端的帳單拆成四層。

四種做法怎麼選

回到最初那個問題：「我想做一個 LINE 客服機器人」，到底該怎麼做？實務上有四條路，成本與能力差距非常大。

	A 官方後台自動回應	B 第三方 SaaS 平台	C 低程式碼串接	D 客製開發
要不要寫程式	完全不用	不用	少量設定	要
能不能查自家系統	不行	多半不行	有限度	可以
前期成本	0	低	低	高
長期成本	0	月租持續累加	月租＋維護	維護為主
資料放在哪	LINE	平台商	平台商	自己
彈性	極低	受平台限制	中等	完全自由
適合誰	問題固定、量不大	想先試水溫	流程單純的自動化	要接內部系統

A. 官方後台自動回應：先把這條路走完再說

LINE 官方帳號後台本身就有「自動回應訊息」與「關鍵字回覆」功能，不用寫任何程式、不用額外付費。

我們的建議是，絕大多數企業都應該先把這條路走滿再考慮其他選項。原因很現實：如果你連「客戶最常問的十個問題」都還沒整理出來，做再貴的 Bot 也只是把空白腳本包在昂貴的殼裡。先用後台功能跑三個月，你會很清楚哪些問題真的重複、哪些其實沒人問。

限制也很明確：它只能做固定文字對應，沒辦法查任何東西，也沒辦法根據客戶身分給不同答案。

B. 第三方 SaaS 平台：試水溫可以，長期要算總帳

市面上有不少現成的 LINE Bot 工具，用拖拉方式就能設定對話流程，月租計費。

適合的情境是：功能需求落在平台既有能力範圍內、想快速上線看效果、暫時不想投入開發成本。

要注意兩件事。第一，月租是持續支出，三年累積下來的總額往往超過一次客製開發的費用，決定前請把時間拉長算一次。第二，客戶資料與對話紀錄放在平台商手上，未來要換工具或自建，遷移成本會比想像中高。

C. 低程式碼串接：流程單純時很划算

用 Zapier 這類自動化工具把 LINE 跟其他服務接起來，例如「有人在 LINE 填完表單就寫進 Google 試算表並寄通知信」。

適合流程單純、串接對象是常見雲端服務的情境。但只要流程開始有分支判斷、需要查詢自家資料庫，這條路的維護難度會迅速超過直接寫程式。

D. 客製開發：要接自己的系統，就只有這條路

透過 Messaging API 自己開發，是唯一能完整接上內部系統的做法——訂單資料庫、CRM、預約系統、ERP，只要有介接方式就能串。

前期成本最高，但它是唯一「資料在自己手上、想改什麼都改得動」的選項。當 Bot 要處理的是核心業務流程而不只是客服應答時，通常也只剩這條路可走。

導入之前，先回答這三個問題

在找任何廠商報價之前，先把這三題想清楚，會省掉大量來回：

第一，這個 Bot 要接手誰的哪一段工作？ 不是「提升客戶體驗」這種說法，是具體到「客服每天花兩小時回答訂單進度，這段給 Bot」。答不出來就先不要做——這也是我們接到 LINE Bot 需求時，第一個會跟客戶一起釐清的問題。十多年下來，需求模糊是常態，不是問題；把模糊的想法拆解清楚，本來就是專案的第一步。

第二，它要查的資料現在在哪裡？ 如果訂單狀態還記在紙本或某個沒有介接能力的舊系統裡，Bot 再厲害也查不到，得先解決資料的問題。這一題常常才是專案真正的成本所在。

第三，對話腳本誰負責維護？ Bot 上線只是開始。答錯的問題要修、新增的服務要補、季節性活動要調整，這些都得有人固定看。沒有指定負責人的 Bot，半年後通常就沒人管了。

三個實務上最常卡住的地方

後台自動回應會跟 Bot 搶事件。 這是最常見的技術坑：官方帳號後台的「自動回應訊息」開著的時候，會跟你的 webhook 互相干擾，出現「明明程式寫對了卻沒反應」或「回了兩次」的狀況。串接 Messaging API 之前，記得先到後台把自動回應功能關掉。

訊息額度是帳號層級共用的。 行銷推播跟系統通知吃的是同一份額度。如果行銷檔期把額度用光，出貨通知就發不出去了，而這通常是更不能漏掉的訊息。有主動推播需求的話，一開始就要把兩類訊息分開估算。

綁定會員涉及個資，不能只想著技術怎麼做。 讓客戶用 LINE 查自己的訂單，前提是把 LINE 的 user ID 跟你的會員資料綁在一起。這個綁定動作屬於個資蒐集，要有明確的告知與同意流程，不是寫完程式就結束。這一點在規劃階段就要納入，事後補會很麻煩。

從「它要幫我做什麼」這一句話開始

回到開頭那個場景。當客戶說「我想做一個 LINE 客服機器人」時，真正該接下去的問題不是「你預算多少」，而是「你希望它幫你處理掉哪一件現在很煩的事」。

把那件事寫成一句話，四種做法要選哪一種，答案通常就浮出來了：只是想少回幾次重複問題，官方後台就夠；想讓客戶自己查得到訂單，那就得走客製，因為只有它接得上你的系統。

會不會做得起來，跟預算的關係沒有想像中大，跟「有沒有人真的在維護它」關係比較大。腳本沒人修的 Bot，功能再完整也會在半年內變成沒人點的殘骸。

瞻新資訊在協助客戶規劃 LINE 相關的自動化與系統串接時，第一步做的一直都是這件事——先把模糊的需求拆解成具體要解決的問題，再決定用什麼方式做。有相關的專案在評估，歡迎聊聊你目前卡在哪一段。

常見問題