WhatsApp 2026年7月費率更新生效——只做接收的團隊需要注意什麼 — UnifyPort
Meta 在6月10日發布了 WhatsApp Business API 的費率更新，將隨2026年7月帳單週期生效。如果你透過 WhatsApp 發送行銷推廣訊息，這是一個需要關注的定價事件——多個市場的費用正在上漲，費率結構也在調整。但如果你的團隊主要是接收客戶訊息、在對話視窗內回覆，這件事的性質完全不同：它更像是一個提醒，你關注的計費表可能本就與你無關。
以下是具體的變化、費用明細，以及不同使用模式下的實際影響。
2026年7月費率變動，逐市場拆解
Meta 的費率更新涉及三類變動：
四個市場的行銷類訊息費率上調：
| 市場 | 變動 |
|---|---|
| 義大利 | 行銷費率上調 |
| 沙烏地阿拉伯 | 行銷費率上調 |
| 西班牙 | 行銷費率上調 |
| 英國 | 行銷費率上調 |
這些調整影響的是分類為「行銷」的範本訊息——促銷推播、召回廣播、在24小時對話視窗之外發送的產品公告。如果你的團隊不發送行銷範本，這些漲幅與你無關。
兩個市場的工具類訊息費率變動：
| 市場 | 變動 |
|---|---|
| 巴基斯坦 | 工具類費率上調（+84%） |
| 土耳其 | 工具類費率下調（-84%） |
工具類範本是交易性訊息——訂單確認、物流通知、預約提醒。巴基斯坦的漲幅相當大，土耳其的降幅同樣顯著。
六個市場從區域費率轉為專屬費率：
| 市場 | 說明 |
|---|---|
| 香港 | 新增專屬費率 |
| 新加坡 | 新增專屬費率 |
| 匈牙利 | 新增專屬費率 |
| 波蘭 | 行銷費率較此前區域費率下降57% |
| 羅馬尼亞 | 新增專屬費率 |
| 卡達 | 新增專屬費率 |
對於面向東南亞市場、收件人在香港或新加坡的團隊來說，從區域費率轉為專屬費率會改變單則訊息的成本計算。波蘭是個例外：其行銷費率比此前適用的區域費率下降了57%。
沒有變的那一行
在費率更新的細節中，有一行維持不變：所有市場的服務對話依然免費。
服務對話在客戶主動發訊息給你的 WhatsApp Business 號碼、且你在24小時對話視窗內回覆時觸發。無需範本，不做分類，Meta 不收取單則費用。這從2025年7月 Meta 轉向單則計費模式以來就沒變過，這次更新也沒有改變。
對於日常工作就是「客戶發訊息過來、我們回覆」的團隊——售後佇列、售前諮詢、訂單查詢——整個費率更新都與核心互動無關。上漲的費用針對的是你主動發送的訊息，按範本類型分類，在對話視窗之外投遞。如果你不做這些，費率表是別人的事。
只做接收的團隊在哪裡還在花錢
「服務對話免費」這句話沒錯，但不完整。以下是只做接收的團隊仍然會產生費用的地方：
遲到的回覆會變成範本訊息。 如果客戶下午2點發訊息，你的客服在隔天下午跟進——間隔25小時——這則跟進訊息就超出了24小時視窗。WhatsApp 會將其重新歸類為範本訊息，按收件人所在國家的工具類或行銷類費率單則計費。團隊裡沒人提交過範本，也沒人覺得這是一次廣播推送。但從計費角度看，一則稍晚的回覆和一次行銷活動走的是同一個計費通道。
BSP 加價會在意外費用上疊加。 如果你透過 BSP（商業解決方案提供商）接入，BSP 的利潤加成——通常15–20%——會加在 Meta 收取的所有費用之上。$0的服務對話帶來$0的加價。但一旦回覆滑出視窗變成範本計費，BSP 就會在上面疊加百分比。2026年7月在義大利、西班牙、沙烏地和英國的費率上調意味著這種疊加在這些市場更貴了。
平台費與訊息量無關。 BSP 平台費——通常$29–$500+/月——不隨費率變化。這是取得基礎設施存取權限的固定費用：範本管理、廣播工具、收件匣介面。即使你的團隊從未打開過這些工具，費用照收。
在受影響市場，一個只做接收的團隊要花多少錢
以英國市場為例——七月行銷費率上調的四個市場之一，假設一個四人客服團隊在接收 WhatsApp 訊息：
| 場景 | 2026年7月費率下的月度費用 |
|---|---|
| 100%回覆在24小時視窗內 | $0（Meta）+ BSP 平台費 |
| 95%在視窗內，5%超時（重歸類為工具類） | 約$12–18（Meta）+ BSP 加價 + 平台費 |
| 同一團隊，無 BSP，無範本系統 | $0 |
第三行值得仔細看。如果一個團隊的工作流程確實不需要外發範本——不做廣播、不做召回、不發主動通知——那麼2026年7月費率調整所涉及的整個計費面，都是這個團隊用不到的基礎設施。
沒有費率表的路徑
UnifyPort 的非官方介面可以接入普通的 WhatsApp 帳號——客戶通訊錄裡已有的那個號碼——並將每則入站訊息以標準化的 message.received webhook 事件投遞：
{
"event": "message.received",
"account_id": "acct_3qPmRz",
"provider": "whatsapp",
"from": "user_88c1ae",
"text": "你好，英國倉的庫存補上了嗎？",
"timestamp": 1751241600,
"message_id": "wa_msg_4d8e2f"
}你的後端透過 signing_secret 驗證 HMAC-SHA256 簽章，然後將訊息路由到現有佇列。回覆透過一個 POST /v1/messages 呼叫發出——沒有範本分類，沒有按類別定價，沒有每季更新的費率表。
這裡沒有行銷層級，因為沒有範本系統。沒有工具類費率，因為沒有訊息分類引擎。沒有 BSP 加價，因為沒有 BSP。2026年7月的費率變動——以及 Meta 已經預告的10月變動——在這個架構裡不產生任何行項目，因為它們調整的計費面在這裡根本不存在。
同一個 webhook 端點也接收來自 Telegram、LINE、TikTok、Zalo 和 X 的訊息，使用相同的 message.received 事件格式。增減通道不改變計費模型——只改變 payload 中的 provider 欄位值。
這週該做什麼
2026年7月費率將在下一個帳單週期生效。在此之前，三件事值得檢查：
-
拉出你的範本訊息明細。 你有多少「回覆」實際上因為超出24小時視窗而被計為範本訊息？如果答案不是零，7月的費率上調適用於那些訊息。
-
確認你的 BSP 加成比例。 如果你的 BSP 按百分比加價，費率上調會透過加價傳導。20%的 BSP 加成意味著你承擔的是漲幅的120%，不是100%。
-
問一下費率表是否和你有關。 如果你的工作流程純粹是入站——客戶先發訊息、團隊在視窗內回覆、不做外發活動——那麼費率表調整的計費面可能根本不是你的計費面。一個標準化入站 webhook 沒有需要更新的費率表。