← บทความทั้งหมด
บทช่วยสอน

วิธีติดตามค่าบริการ WhatsApp service message ก่อน 1 ตุลาคม 2026

หากต้องการติดตามค่าบริการ WhatsApp service message ก่อน 1 ตุลาคม 2026 ให้ตรวจจำนวน SERVICE message ที่ delivery แล้วผ่าน Meta Pricing Analytics API และเก็บ object pricing จาก message status webhook แยกผลตาม phone number และตลาด คุณเริ่มสร้าง baseline ของ volume ได้ตั้งแต่ตอนนี้ แต่ควรอัปเดต forecast อีกครั้งหลัง Meta ประกาศอัตราค่าบริการเดือนตุลาคมภายใน 1 กันยายน

ประเด็นสำคัญ

  • Meta จะคิดค่าบริการต่อ service message ที่ delivery แล้วตั้งแต่ 1 ตุลาคม 2026 โดย customer-service conversation จะไม่ใช่หน่วยคิดเงินอีกต่อไป
  • Pricing Analytics ระบุ record เหล่านี้ด้วย pricing_type: REGULAR และ pricing_category: SERVICE
  • Status webhook ที่มีการคิดเงินจะแสดง billable: true, type: regular และ category: service ใน object pricing
  • อัตรา service แตกต่างกันตามตลาด เท่ากับอัตรา utility และ authentication ของตลาดนั้น และไม่มี volume tier
  • Free entry point 72 ชั่วโมงจากโฆษณา Click-to-WhatsApp และ Facebook call-to-action button ยังคงไม่คิดค่า delivery จึงต้องแยก model ออกมาต่างหาก

สิ่งที่จะเปลี่ยนในวันที่ 1 ตุลาคม 2026

อัปเดตราคาอย่างเป็นทางการของ Meta ระบุว่า non-template message ส่งได้เฉพาะเมื่อ customer service window 24 ชั่วโมงเปิดอยู่ ตั้งแต่ 1 ตุลาคม non-template message ทุกข้อความที่ส่งโดยคนหรือ AI ของบุคคลที่สามซึ่งไม่ได้ทำงานด้วย Meta Business Agent จะถูกคิดเงินเป็น service message

การเปลี่ยนแปลงนี้สร้างขอบเขตสามส่วนที่แผนวัดผลต้องแยกให้ชัด:

ขอบเขตการจัดประเภทของ Metaสิ่งที่ต้องติดตาม
คนหรือ AI ของบุคคลที่สามตอบใน window ที่เปิดอยู่Service messageจำนวน message ที่ delivery แล้วแยกตามตลาด
Meta Business Agent ตอบMeta Business Agent messageCategory แยกและค่าใช้จ่ายแบบ token
Message ใน free entry point window 72 ชั่วโมงDelivery ยังคงฟรีEntry point และสถานะของ window

หนึ่ง message จะถูกคิดเงินเพียง category เดียว อย่ารวมค่าบริการ service message และ Meta Business Agent เข้ากับ non-template reply เดียวกัน และอย่าสรุปว่าอัตราเดือนตุลาคมเป็นตัวเลขสุดท้ายแล้ว Meta ระบุว่าจะประกาศอัตราที่มีผลวันที่ 1 ตุลาคมภายใน 1 กันยายน 2026 และอาจปรับอัตราได้ทุกไตรมาส

บทเปรียบเทียบราคา Meta Business Agent อธิบายการตัดสินใจด้านสถาปัตยกรรม ส่วน คู่มือ rate card เดือนกรกฎาคม 2026 อธิบายบริบทของอัตราตามตลาด บทความนี้เริ่มหลังจากตัดสินใจเรื่องนั้นแล้ว โดยเน้นว่าทีมควรวัดอะไรบ้างก่อนเริ่มคิดค่าบริการ

วิธีติดตามค่าบริการ WhatsApp service message

1. สร้าง baseline ของ message ที่ delivery แล้ว

เลือกช่วงเวลาที่เป็นตัวแทน โดยทั่วไปคือสี่สัปดาห์เต็ม แล้ว query Pricing Analytics สำหรับ service category ผลลัพธ์ตามเอกสารของ Meta มี field เหล่านี้:

Fieldวิธีใช้ใน baseline
start / endล็อก reporting window
phone_numberแยกแต่ละหมายเลขที่ส่ง
countryจับคู่ volume กับอัตราของตลาดที่ถูกต้อง
pricing_type: REGULARตัด pricing type อื่นออก
pricing_category: SERVICEนับเฉพาะ service message
volumeวัดจำนวน service message ที่ delivery แล้ว
costกระทบยอดค่าใช้จ่ายเมื่อ billing เริ่มใช้

เก็บผลลัพธ์แยกตามวัน, phone number และ country อย่ารวมเป็น “conversation” เพราะตั้งแต่เดือนตุลาคม Meta จะวัด business message ที่ delivery แล้วแต่ละข้อความ ดังนั้นการคุย support ที่ตอบห้าครั้งจะเกิดหน่วยวัดห้าหน่วย ไม่ใช่หนึ่ง conversation

2. เก็บ object pricing จาก status webhook

Meta ระบุว่า category และค่าใช้จ่ายจะปรากฏใน message status webhook ด้วย record ของ service message ที่คิดเงินมีโครงสร้างดังนี้:

{
  "pricing": {
    "billable": true,
    "pricing_model": "PMP",
    "type": "regular",
    "category": "service"
  }
}

เก็บ object pricing พร้อม message record ของคุณก่อน aggregate สิ่งสำคัญไม่ใช่ agent คิดว่า reply นั้นเป็น “support” หรือไม่ แต่คือ Meta รายงาน message ที่ delivery แล้วว่าเป็น category: service และ billable หรือไม่

3. กระทบยอด webhook กับ Pricing Analytics

ทำ daily reconciliation ด้วยสองจำนวน:

  1. Status-webhook record ที่ delivery แล้วและ pricing.category เป็น service
  2. volume ใน Pricing Analytics ที่ pricing_category เป็น SERVICE สำหรับ phone number, country และ date window เดียวกัน

ตรวจสอบความต่างแทนการเฉลี่ยทิ้งไป ขอบเขตที่พบบ่อย ได้แก่ status event มาถึงช้า, time zone ไม่ตรงกัน, reporting window ไม่รวมวันสุดท้าย หรือ message ถูกจัดเป็น Meta Business Agent แทน service

4. สร้าง forecast โดยไม่ตั้งอัตราเดือนตุลาคมขึ้นเอง

ใช้สูตรที่แยก volume ออกจาก rate:

forecasted service-message cost
  = delivered SERVICE volume by market
  × published service rate for that market

สำหรับการวางแผนก่อน 1 กันยายน Meta ระบุว่าอัตรา service จะเท่ากับอัตรา utility และ authentication ตามตลาด ใช้อัตราปัจจุบันเป็น planning input ไม่ใช่คำรับรอง อัปเดต model เมื่อมีการประกาศอัตราเดือนตุลาคมอย่างเป็นทางการ และอย่านำ volume-tier discount ของ utility/authentication มาใช้กับ service message เพราะ Meta ระบุว่า service message ไม่มี volume tier

ถ้า Business Solution Provider คิด platform fee หรือ service fee เพิ่ม ให้แยกรายการนั้นออกมา บทตรวจสอบบิล BSP อธิบายว่าการรวม Meta usage กับ provider fee จะซ่อนการตัดสินใจที่ทีมต้องทำอย่างไร

5. ทดสอบข้อยกเว้นก่อนวันเริ่มใช้

สร้าง acceptance matrix ขนาดเล็กก่อน 1 ตุลาคม:

  • human reply ปกติภายใน customer service window 24 ชั่วโมง
  • reply ที่สร้างโดย AI ของบุคคลที่สามภายใน window เดียวกัน
  • Meta Business Agent reply
  • reply ภายใน free entry point window 72 ชั่วโมงที่ยังใช้ได้
  • scenario เดียวกันในสองตลาดผู้รับ

ในแต่ละกรณี ให้บันทึก category ที่ status webhook ส่งกลับและ row ที่ตรงกันใน Pricing Analytics วิธีนี้ทำให้ finance, support และ engineering ใช้คำจำกัดความเดียวกันก่อนบิลแรกมาถึง

UnifyPort อยู่ตรงไหน

การวัดผลข้างต้นใช้กับ traffic ที่ส่งผ่าน WhatsApp Business Platform อย่างเป็นทางการ ทีมที่ใช้ unofficial interface ของ UnifyPort เพื่อรับ ordinary-account inbound message จะมี control plane ต่างออกไป โดย category จาก Meta Pricing Analytics ไม่ใช่ source of truth ของเส้นทางนั้น

UnifyPort ส่ง WhatsApp inbound message เป็น envelope มาตรฐาน message.received แบบเดียวกับ Telegram, LINE, TikTok, Zalo และ X:

{
  "id": "evt_7c41f0b2a9",
  "type": "message.received",
  "provider": "whatsapp",
  "account_id": "acc_8c21d0",
  "occurred_at": "2026-07-14T02:15:00Z",
  "data": {
    "conversation": { "id": "84901234567", "type": "user" },
    "sender": { "id": "84901234567", "type": "user", "name": "Minh Tran" },
    "message": {
      "id": "wamid.HBgM",
      "type": "text",
      "text": "Can you check my delivery window?",
      "direction": "inbound",
      "sent_at": "2026-07-14T02:14:58Z"
    }
  }
}

เมื่อเปิด signing ให้ตรวจ X-Device-Signature กับ raw body ที่ตรงกันทุก byte โดยใช้ signing_secret และ X-Device-Timestamp ก่อนประมวลผล event เอกสาร webhook delivery อธิบาย input ของ HMAC-SHA256 และพฤติกรรม delivery

นี่ไม่ใช่วิธีทำให้ค่าบริการของ official platform หายไปในขณะที่ยังส่งผ่าน Meta แต่เป็นทางเลือก integration แยกต่างหากสำหรับทีมที่ต้องการ ordinary-account inbound access หรือ normalized queue ข้ามหลาย messaging channel สำหรับทีมไทยที่ดู WhatsApp ควบคู่กับ LINE การแยก ledger ตาม outbound path ช่วยให้ต้นทุนของ WhatsApp และ routing ข้ามช่องทางไม่ปะปนกัน

ข้อจำกัดและสิ่งที่ต้องแลก

WhatsApp Business Platform อย่างเป็นทางการเหมาะกว่าเมื่อคุณต้องใช้ approved template, official campaign tooling, Meta-native analytics, Click-to-WhatsApp attribution หรือ managed support ของ Business Solution Provider ให้คงแผนวัดผลแบบ official ไว้หากส่วนใดของ workflow ยังใช้ platform นี้

UnifyPort ไม่ได้แทนที่การปฏิบัติตามนโยบาย WhatsApp, official marketing capability หรือ billing record ของ Meta และ unofficial interface ก็ไม่มี category ของ Meta Pricing Analytics สำหรับสถาปัตยกรรมแบบผสม ให้แยก ledger และติด label ทุก outbound path อย่างชัดเจน

คำถามที่พบบ่อย

หลัง 1 ตุลาคม 2026 WhatsApp service message จะคิดเงินต่อ conversation หรือไม่

ไม่ Meta ระบุว่าคิดค่าบริการต่อ service message ที่ delivery แล้ว ให้นับ business-sent reply แต่ละข้อความที่จัดเป็น service ไม่ใช่ customer service window 24 ชั่วโมงแต่ละช่วง

Pricing Analytics category ใดใช้ติดตาม service message

ใช้ pricing_type: REGULAR และ pricing_category: SERVICE แยก volume และ cost ที่ได้ตาม phone number, country และ reporting window

สามารถคำนวณค่าใช้จ่ายเดือนตุลาคมขั้นสุดท้ายได้ในเดือนกรกฎาคม 2026 หรือไม่

คุณวัด volume และสร้าง model ได้ แต่ rate input ขั้นสุดท้ายยังไม่ล็อก Meta ระบุว่าจะประกาศอัตราที่มีผลวันที่ 1 ตุลาคมภายใน 1 กันยายน 2026

Service message ได้ WhatsApp volume-tier discount หรือไม่

ไม่ได้ อัปเดตของ Meta ระบุว่า service message ไม่มี volume tier แม้ utility และ authentication message ยังมีอยู่

Free entry point window 72 ชั่วโมงยังฟรีหรือไม่

ฟรีสำหรับ message delivery Meta ระบุว่า message ภายใน free entry point window 72 ชั่วโมงที่ยังใช้ได้จะไม่คิดค่า delivery แต่ token usage ของ Meta Business Agent อาจถูกคิดแยกต่างหาก

ขั้นตอนถัดไป

หากกำลังประเมิน normalized inbound path ควบคู่กับ official billing model ให้ทำตาม UnifyPort Quickstart และทดสอบ event message.received ที่ลงนามแล้วก่อนเปลี่ยน production routing

แหล่งข้อมูล