WhatsApp Coexistence ใช้ Business App กับ Cloud API พร้อมกันได้แล้ว — แต่คุณจำเป็นต้องใช้ทั้งสองจริงๆ หรือ?
ฟีเจอร์ WhatsApp Coexistence ของ Meta — เปิดให้ใช้กว้างขวางในปี 2026 ใน 14+ ประเทศ — แก้ปัญหาที่ผู้ใช้ WhatsApp Business หงุดหงิดมาหลายปี: เดิมต้องเลือกระหว่าง Business App (แมนวล ใช้บนมือถือ) กับ Cloud API (อัตโนมัติ ขับเคลื่อนด้วย webhook) ใช้อันหนึ่งก็เสียอีกอัน Coexistence ให้คุณรันทั้งสองบนเบอร์เดียวกัน ข้อความซิงค์แบบเรียลไทม์
เป็นการปรับปรุงที่มีความหมายจริงๆ แต่ก็คุ้มค่าที่จะถาม: ทีมของคุณต้องการทั้งสองฝั่งจริงๆ หรือเปล่า?
Coexistence ให้อะไร
Coexistence มิเรอร์ทุกแชท 1-1 ระหว่าง WhatsApp Business App กับ Cloud API ลูกค้าส่งข้อความมาที่เบอร์คุณ — ข้อความปรากฏพร้อมกันทั้งบน Business App ในมือถือและ webhook event ของ Cloud API ตอบกลับจากฝั่งไหนก็ซิงค์ไปอีกฝั่งภายในไม่กี่วินาที
สถานการณ์จริง: ทีมเซลส์ตอบจากมือถือ คิวซัพพอร์ตวิ่งผ่านระบบอัตโนมัติ ทั้งสองฝ่ายเห็นแชทเดียวกัน ไม่ต้องฟอร์เวิร์ด ไม่ต้องเบอร์สำรอง ไม่ต้อง “ไปเช็คอีกช่องทางหน่อย”
Meta ยัง backfill ประวัติแชท 1-1 ย้อนหลังสูงสุด 6 เดือนตอนเปิด Coexistence — ฝั่ง API ไม่ได้เริ่มจาก inbox ว่างเปล่า
Coexistence ต้องการอะไรบ้าง
รายการเงื่อนไขบ่งบอกกลุ่มเป้าหมายชัดเจน:
1. Cloud API ที่ได้รับอนุมัติแล้ว WhatsApp Business Account ต้องเชื่อมต่อ Cloud API ผ่านกระบวนการ onboarding ของ Meta — ตรงหรือผ่าน BSP (Business Solution Provider) ต้องผ่านการยืนยันธุรกิจ ตั้งค่า Meta Business Portfolio และกำหนดค่า webhook endpoint ใน Meta Developer Console
2. เวอร์ชัน Business App ที่ถูกต้อง WhatsApp Business App เวอร์ชัน 2.24.17 ขึ้นไป เวอร์ชันเก่าไม่รองรับโปรโตคอลซิงค์
3. ช่วงวอร์มอัพ เบอร์โทรต้องใช้งานอยู่บน Business App อย่างน้อย 7 วันก่อนเปิด Coexistence Meta แนะนำ 1-2 เดือนของการใช้งานต่อเนื่องเพื่อให้ซิงค์เสถียร ลงทะเบียนเบอร์ใหม่แล้วเปิดทั้งสองทันทีไม่ได้
4. Heartbeat 14 วัน หลังเปิด Coexistence ต้องเปิด Business App อย่างน้อยทุก 14 วัน ถ้าแอปหลับ การซิงค์จะหยุดเงียบๆ — ข้อความ API ยังมาถึงแต่ฝั่งแอปดับ ทีมเซลส์ไม่เห็นข้อความจนกว่าจะมีคนเปิดแอปอีกครั้ง
5. โครงสร้าง BSP (ส่วนใหญ่) ถ้าไม่ได้เชื่อมต่อ Cloud API ของ Meta โดยตรง (ทีมเล็กส่วนใหญ่ไม่ทำ) คุณจะผ่าน BSP หมายถึงค่าแพลตฟอร์ม ($29–$500+/เดือน) ค่า markup ต่อข้อความ (ปกติ 15–20%) และค่าใช้จ่ายจัดการ template
สามประเภททีมที่ Coexistence เหมาะกับ
ไม่ใช่ทุกการตั้งค่า WhatsApp จะได้ประโยชน์จากการรันสองฝั่ง Coexistence เหมาะกับโปรไฟล์เฉพาะ:
ทีม A: เซลส์ใช้มือถือ ซัพพอร์ตอัตโนมัติ เซลส์ภาคสนามตอบจาก Business App ระบบ backend จัดการยืนยันคำสั่งซื้อและ routing ทั้งสองต้องเห็นแชทเดียวกัน Coexistence แก้ปัญหานี้โดยตรง
ทีม B: กำลังย้ายจาก Business App ไป Cloud API ทีมเริ่มต้นด้วย Business App และกำลังเพิ่ม API automation ทีละน้อย Coexistence ให้รันทั้งสองในช่วงเปลี่ยนผ่านโดยไม่ต้องย้ายเบอร์หรือเสีย workflow ฝั่งแอป
ทีม C: กฎหมายกำหนดให้มีคนตรวจสอบ ข้อกำหนดบังคับให้คนรีวิวข้อความอัตโนมัติก่อนส่ง ฝั่งแอปเป็นหน้าจอรีวิว ฝั่ง API เป็นระบบอัตโนมัติ
ประเภททีมที่ไม่เหมาะ
มีประเภทที่สี่ที่ไม่มีในเอกสาร Coexistence ของ Meta: ทีมที่รับข้อความอย่างเดียว
ทีมเหล่านี้ไม่ส่ง broadcast การตลาด ไม่ใช้ template message ไม่ต้องการหน้าจอตอบแมนวลของ Business App — เพราะคิวซัพพอร์ตจัดการโดยระบบ ticket, CRM หรือ AI agent pipeline แล้ว สิ่งเดียวที่ต้องการจาก WhatsApp คือข้อความขาเข้า — ส่งมาเป็น structured event เพื่อ routing, logging และประมวลผล
สำหรับทีมนี้ Coexistence เพิ่มโครงสร้างพื้นฐานทั้งสองด้านของฟีเจอร์ที่ไม่ได้ใช้:
- ฝั่ง Cloud API: ยืนยันธุรกิจ, Meta Developer Console, กำหนดค่า webhook, สัญญา BSP, คิดค่าต่อข้อความ (แม้ service conversation ฟรี แต่ตอบช้าจะกลายเป็นค่า template — ดู วิเคราะห์อัตราค่าบริการเดือน ก.ค.)
- ฝั่ง Business App: ข้อกำหนด heartbeat 14 วัน, จัดการเวอร์ชันแอป, ช่วงวอร์มอัพ, ต้องมีคนในทีมเปิดมือถือ
การซิงค์ระหว่างสองฝั่งคือหัวใจของฟีเจอร์ ถ้าไม่ต้องการฝั่งไหนเลย การซิงค์ก็เป็นภาระ
เส้นทางที่ข้ามทั้งสองฝั่ง
อินเทอร์เฟซไม่เป็นทางการของ UnifyPort เชื่อมต่อบัญชี WhatsApp ธรรมดา — ไม่ต้องยืนยันธุรกิจ ไม่ต้อง Cloud API ไม่ต้อง BSP — ส่งทุกข้อความขาเข้าเป็น webhook event มาตรฐาน:
{
"event": "message.received",
"account_id": "acct_7kQnWx",
"provider": "whatsapp",
"from": "user_d4f29a",
"text": "ส่งของไปสิงคโปร์ได้ไหมครับ",
"timestamp": 1751270400,
"message_id": "wa_msg_8b3e71"
}
Backend ตรวจสอบลายเซ็น HMAC-SHA256 ด้วย signing_secret แล้ว route ข้อความเข้าคิวที่มีอยู่ ไม่ต้องเปิด Business App ไม่ต้องตั้งค่า Cloud API ไม่ต้องรักษา heartbeat 14 วัน ไม่มี BSP markup ทบต้นบนค่า template ที่ไม่ตั้งใจ
ตอบกลับผ่าน POST /v1/messages — endpoint เดียว ไม่มีการจำแนก template ไม่มีค่าตาม conversation window Webhook endpoint เดียวกันรับข้อความจาก Telegram, LINE, TikTok, Zalo และ X ด้วย schema message.received เดียวกัน สำหรับทีมในไทยที่ LINE เป็นช่องทางหลัก การเพิ่ม WhatsApp เข้าระบบหลายแพลตฟอร์มที่มี LINE อยู่แล้วไม่ได้เพิ่มโมเดลคิดเงินใหม่ — แค่เพิ่มค่า provider ใน payload
ตารางตัดสินใจ
| เงื่อนไข | Coexistence | UnifyPort |
|---|---|---|
| ยืนยันธุรกิจ | จำเป็น | ไม่ต้อง |
| สัญญา BSP | ปกติต้อง | ไม่ต้อง |
| แอปมือถือเปิดทุก 14 วัน | จำเป็น | ไม่ต้อง |
| Template การตลาดขาออก | รองรับ | ไม่ใช่ use case |
| Webhook ข้อความขาเข้า | ใช่ (ฝั่ง Cloud API) | ใช่ |
| หลายแพลตฟอร์ม (Telegram, LINE ฯลฯ) | แยกเชื่อมต่อ | Webhook เดียว |
| คิดค่าต่อข้อความ | อัตรา Meta + markup BSP | ไม่มี |
| เวลาติดตั้ง | หลายวันถึงหลายสัปดาห์ (ยืนยัน) | ไม่กี่ชั่วโมง |
สถานการณ์ไหนเป็นของคุณ
ถ้าทีมส่งแคมเปญขาออก ต้องการ Business App ให้เซลส์ภาคสนาม หรือกำลังย้าย workflow Business App ที่มีอยู่ไปยัง API automation — Coexistence คือฟีเจอร์ที่คุณรอคอย มันแก้ช่องว่างจริงในโครงสร้างพื้นฐาน WhatsApp
ถ้าทีมแค่รับข้อความ route เข้าคิว ตอบผ่านระบบที่มีอยู่ — คำถามไม่ใช่ “ควรเปิด Coexistence ไหม” แต่เป็น “เราต้องการโครงสร้างพื้นฐานที่ Coexistence เชื่อมต่อหรือเปล่า” สำหรับ workflow ขาเข้าล้วนๆ คำตอบอาจเป็น: ไม่ต้องการทั้งสองฝั่ง
เอกสาร API และ webhook ฉบับสมบูรณ์: unifyport.ai/docs