ค่าบริการ OA ใหม่ของ Zalo มิถุนายน 2026: ทีมข้ามพรมแดนทีมหนึ่งรับข้อความ Zalo ต่อได้อย่างไรโดยไม่ต้องวิ่งตามลู่ OA — UnifyPort

วันที่ 1 มิถุนายน 2026 ค่าบริการ Official Account (OA) ใหม่ของ Zalo เริ่มมีผล สำหรับทีมข้ามพรมแดนห้าคนที่ขายสกินแคร์จากออฟฟิศเล็ก ๆ ในโฮจิมินห์ อีเมลฉบับนั้นมาถึงในจังหวะที่แย่ที่สุด: กลางช่วงแคมเปญ ทั้งที่มีพนักงานสองคนนั่งตอบลูกค้าในแชต Zalo และ WhatsApp แทบทั้งวันอยู่แล้ว ประกาศค่าบริการบีบให้พวกเขาต้องเผชิญคำถามที่ผัดผ่อนมานาน: จะทำสิ่งที่ทำอยู่ต่อไป จริง ๆ แล้วต้องจ่ายเท่าไหร่?

สิ่งที่พวกเขาทำอยู่นั้นง่ายมาก ลูกค้าทักร้านมาทาง Zalo มีคนตอบ จบ ไม่มีจดหมายข่าว ไม่มีการยิงข้อความการตลาด ไม่มีลำดับข้อความอัตโนมัติ แต่เส้นทางที่ Zalo วางไว้สำหรับ “ธุรกิจที่อยากรับข้อความแบบเขียนโปรแกรม” กลับต้องผ่านกลไก Official Account ทั้งชุด — และกลไกนั้นถูกสร้างมาเพื่อคนที่ยิงข้อความออกจำนวนมาก ไม่ใช่เพื่อทีมที่แค่อยากตอบคนที่ทักมาก่อน

ลู่วิ่ง OA และเหตุผลที่มันไม่เหมาะ

การรับข้อความ Zalo ผ่านช่องทางทางการหมายถึงต้องตั้ง Official Account ผ่านการยืนยันตัวตน แล้วใช้ชีวิตอยู่ภายใต้กฎของ OA ที่เจ็บที่สุดคือหน้าต่างการโต้ตอบ: OA ส่งข้อความถึงผู้ใช้ได้อย่างอิสระเฉพาะภายในช่วงเวลาจำกัดหลังจากผู้ใช้คนนั้นติดต่อเข้ามาเท่านั้น ก้าวพ้นช่วงนั้นไป — ตามต่อเช้าวันรุ่งขึ้น ส่งอัปเดตคำสั่งซื้อในอีกสองวัน — คุณก็เข้าสู่อาณาเขตของ Zalo Notification Service (ZNS) ที่แต่ละข้อความต้องขี่อยู่บนเทมเพลตที่อนุมัติไว้ล่วงหน้าและคิดค่าบริการเป็นรายข้อความ

สำหรับคนที่ยิงบรอดแคสต์ นั่นเป็นข้อแลกเปลี่ยนที่สมเหตุสมผล แต่สำหรับร้านห้าคน มันคือลู่วิ่ง เทมเพลตทุกอันต้องเขียน ส่งตรวจ และรออนุมัติก่อนถึงจะใช้ได้ การเปลี่ยนค่าบริการวันที่ 1 มิถุนายนจัดระดับแพ็กเกจ OA ใหม่ และขยับเส้นแบ่งว่าอะไรอยู่ในโควตาฟรีกับอะไรที่คิดเงิน — และทีมอ่านออกมาว่าการใช้งานแบบปริมาณน้อยจริง ๆ และเป็นบทสนทนาของพวกเขากำลังจะทั้งแพงขึ้นและมีขั้นตอนมากขึ้นพร้อมกัน พวกเขาไม่ได้ยิงข้อความการตลาดเป็นพัน ๆ ข้อความ พวกเขาแค่ตอบคำถาม แต่กลับถูกขอให้รับเอาโครงสร้างต้นทุนและกระบวนการอนุมัติของบริษัทที่ทำสิ่งที่พวกเขาไม่ได้ทำเลย

แล้ว Zalo ก็เป็นแค่กล่องเดียว พนักงานสองคนเดิมนั้นทั้งวันยังอยู่ใน WhatsApp ซึ่งมีกลไกของตัวเอง — การยืนยันธุรกิจ คิดเงินรายข้อความ การอนุมัติเทมเพลตแบบของมันเอง สองแพลตฟอร์ม กฎสองชุดที่ต่างกันสิ้นเชิง สองการเชื่อมต่อถ้าวันหนึ่งอยากทำอัตโนมัติ ราคาไม่ได้วัดแค่เป็นเงิน แต่อยู่ที่ทุกช่องทางบังคับให้ทีมเรียนรู้ระบบที่ต่างกันก่อนจะทำสิ่งเดียวที่อยากทำจริง ๆ ได้ นั่นคือเห็นข้อความเข้ามา แล้วตอบ

นิยามปัญหาใหม่: พวกเขาต้องการข้อความขาเข้า ไม่ใช่ Official Account

สิ่งที่ปลดล็อกได้คือการแยก สิ่งที่พวกเขาต้องการ ออกจาก สิ่งที่เส้นทางทางการพ่วงมาด้วย กลไกบรอดแคสต์ของ OA — เทมเพลต, ZNS, หน้าต่างการโต้ตอบ, ระดับโควตา — มีอยู่เพื่อให้ธุรกิจ เริ่ม ติดต่อในระดับใหญ่ได้ ทีมนี้ไม่เคยเป็นฝ่ายเริ่ม ทุกบทสนทนาเริ่มจากลูกค้า สิ่งที่ต้องการมีเพียง รับ ข้อความขาเข้าอย่างเชื่อถือได้ และตอบกลับภายในบทสนทนาที่ลูกค้าเปิดไว้แล้ว

นั่นเป็นปัญหาที่เล็กกว่า “ดำเนินการ Official Account” มาก การใช้งานแบบรับอย่างเดียว ตอบในเซสชันเท่านั้น ไม่ต้องใช้เครื่องมือบรอดแคสต์เลย พอมองเห็นแบบนั้น คำถามก็เลิกเป็น “ควรซื้อแพ็กเกจ OA ไหน” แล้วกลายเป็น “วิธีที่ง่ายที่สุดในการพาข้อความ Zalo ขาเข้ามาถึง backend ของเรา แล้วส่งคำตอบกลับเข้าแชตเดิมคืออะไร”

webhook เดียวสำหรับทั้ง Zalo และ WhatsApp

พวกเขาเชื่อมทั้งสองบัญชีผ่านอินเทอร์เฟซรับข้อความแบบไม่เป็นทางการของ UnifyPort ซึ่งวางทุกช่องทางไว้หลัง webhook ที่ถูกทำให้เป็นมาตรฐานเดียว แทนที่จะเชื่อมต่อทีละแพลตฟอร์ม ข้อความ Zalo กับข้อความ WhatsApp มาถึงในรูปแบบเดียวกันเป๊ะ ต่างกันแค่ฟิลด์ provider:

{
  "event": "message.received",
  "account_id": "acct_7Hm2pX",
  "provider": "zalo",
  "from": "user_9a3f21",
  "text": "Sản phẩm này còn hàng không ạ?",
  "timestamp": 1749513600,
  "message_id": "zalo_msg_4c8e1d"
}

backend ของพวกเขาสมัครรับแค่อีเวนต์เดียวคือ message.received แล้วจัดเส้นทางตามฟิลด์เดียว โค้ดที่ประมวลผลข้อความ Zalo คือโค้ดเดียวกับที่ประมวลผลข้อความ WhatsApp — ฝั่งรับไม่มีการแยกสาขาตามแพลตฟอร์มเลย:

app.post("/webhook", (req, res) => {
  if (!verifySignature(req)) return res.sendStatus(401);

  const evt = req.body;
  if (evt.event === "message.received") {
    // evt.provider จะเป็น "zalo" หรือ "whatsapp" — จัดเส้นทางเหมือนกันทุกประการ
    queue.add({
      channel: evt.provider,
      customer: evt.from,
      text: evt.text,
      accountId: evt.account_id,
    });
  }
  res.sendStatus(200);
});

ทุกการส่งถูกเซ็นลายเซ็น ทีมจึงตรวจความถูกต้องด้วย HMAC-SHA256 เทียบกับ signing_secret ที่ตั้งไว้บน webhook ก่อนจะเชื่อ payload ใด ๆ — เป็นขั้น verifySignature เดียวกันไม่ว่าข้อความมาจากแพลตฟอร์มไหน การตอบกลับเป็นภาพสะท้อน: เรียก POST /v1/messages ครั้งเดียวโดยระบุบัญชีและผู้รับ เพราะลูกค้าทักมาก่อน ทุกคำตอบจึงตกลงในบทสนทนาที่ลูกค้าเปิดไว้ — ตรงกับการโต้ตอบในเซสชันที่ทีมทำด้วยมืออยู่แล้ว ตอนนี้เขียนเป็นสคริปต์ได้ และไม่ต้องอนุมัติเทมเพลตล่วงหน้าเลย

ผลในทางปฏิบัติคือ ประกาศค่าบริการวันที่ 1 มิถุนายนเลิกเป็นวิกฤตงบประมาณ ทีมไม่ต้องไต่ซื้อระดับ OA ที่สูงขึ้นเพื่อจะตอบแชตปริมาณน้อยที่ลูกค้าเป็นฝ่ายเริ่มต่อไป พนักงานซัปพอร์ตสองคนยังทำงานในสองกล่องเดิม เพียงแต่ตอนนี้ทั้งสองกล่องไหลเข้าคิวเดียว สคีมาเดียว เส้นทางตอบกลับเดียว — และภายหลังการเพิ่ม LINE สำหรับซัปพลายเออร์ไทยก็เป็นเพียง handler message.received ตัวเดิมทำงานอีกครั้ง ไม่ใช่โปรเจกต์เชื่อมต่อตัวที่สาม ในไทยที่ LINE เป็นช่องทางหลัก นี่คือก้าวถัดไปที่ใช้ได้จริง ไม่ใช่แค่ทฤษฎี

สิ่งที่หยิบกลับไปได้

บทเรียนไม่ใช่ “หลีกเลี่ยง Official Account ของ Zalo” — ถ้าคุณรันแคมเปญบรอดแคสต์ในปริมาณมาก OA และ ZNS ถูกสร้างมาเพื่อสิ่งนั้นโดยตรง และคุณควรใช้มัน บทเรียนคือให้ตรวจสอบว่าเส้นทางทางการกำลังแก้ปัญหา ของคุณ หรือ ปัญหาที่ใหญ่กว่า ที่คุณไม่ได้มี การเปลี่ยนค่าบริการที่เล็งไปที่คนยิงบรอดแคสต์ปริมาณมาก อาจดันต้นทุนของการแค่ “ตอบลูกค้า” ขึ้นอย่างเงียบ ๆ เพราะเส้นทางทางการมัดสองพฤติกรรมนี้ไว้ในบัญชีเดียวกัน

ถ้าสิ่งที่ต้องการมีเพียงรับข้อความขาเข้าและตอบในเซสชัน นั่นเป็นปัญหาที่แยกออกมาได้และถูกกว่ามาก ชี้ backend ของคุณไปที่ webhook ขาเข้าแบบมาตรฐาน สมัครรับ message.received แล้วข้อความ Zalo จะเข้าคิวของคุณโดยไม่ต้องวิ่งลู่ OA — ส่วนอีกห้าช่องทางที่เหลือ จะมาถึงผ่าน handler ตัวเดียวกันในวันที่คุณต้องการ