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 冇需要更新嘅費率表。