WhatsApp: ปิดเสียงหรือบล็อก ควรใช้แบบไหนในกล่องข้อความร่วม

หากต้องการลดการแจ้งเตือน WhatsApp ให้ปิดเสียงการสนทนา แต่หากต้องการหยุดบุคคลหนึ่งไม่ให้ส่งข้อความถึงบัญชี จึงค่อยพิจารณาบล็อกผู้ติดต่อ ทั้งสองอย่างไม่ใช่คำสั่ง “พักการตอบกลับอัตโนมัติ” หรือ “ปิดงานบริการลูกค้า” ภายในระบบ กล่องข้อความร่วมควรแยกการตัดสินใจเหล่านี้ เพื่อไม่ให้การลดเสียงแจ้งเตือนกลายเป็นการตัดช่องทางติดต่อกับลูกค้า หรือปล่อยให้ AI ตอบต่อทั้งที่ทีมคิดว่าหยุดแล้ว

สามการควบคุม สามจุดประสงค์

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

จุดประสงค์	การควบคุมที่เหมาะสม	สิ่งที่สรุปไม่ได้
ลดการรบกวนจากการแจ้งเตือน	ปิดเสียงการสนทนา	งานถูกแก้ไขแล้ว หรือหยุดรับ webhook แล้ว
หยุดการติดต่อจากบุคคลหนึ่ง	บล็อกหลังผู้มีสิทธิ์อนุมัติ	ข้อมูลเดิมถูกลบ หรือข้อความจะกลับมาหลังเลิกบล็อก
หยุด AI ตอบข้อความ	สถานะพักระบบอัตโนมัติที่แอปดูแลเอง	การปิดเสียงหรือบล็อกจะยกเลิกงานในคิวของแอป
เก็บงานไว้ติดตาม	สถานะงานในระบบ และอาจใช้เครื่องหมายยังไม่อ่าน	ยังไม่อ่านเท่ากับปิดเสียง

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

UnifyPort มีคำสั่งอะไรบ้าง

อินเทอร์เฟซที่ไม่เป็นทางการของ UnifyPort แยกคำสั่งระดับการสนทนาออกจากคำสั่งระดับผู้ติดต่อ ตารางนี้เป็นสัญญา API ของ UnifyPort ไม่ใช่เส้นทาง Meta Cloud API

คำสั่ง	ข้อมูลและขอบเขตตามเอกสาร	อ้างอิง
ปิดเสียง	conversation_id พร้อม duration หน่วยวินาที หรือ mute_until แบบ RFC3339 ที่เป็นเวลาในอนาคต ห้ามส่งทั้งสองค่า	ปิดเสียงการสนทนา
เปิดเสียง	conversation_id	เลิกปิดเสียง
บล็อกหรือเลิกบล็อก	contact_id ต้องเป็น WhatsApp LID มาตรฐานในรูป digits@lid	บล็อกผู้ติดต่อ และ เลิกบล็อก
ตรวจรายการบล็อก	ผลตอบกลับมี data.blocklist และลายนิ้วมือของรายการ data.dhash	รับรายการบล็อก

duration: 0 หมายถึงปิดเสียงถาวร ไม่ใช่ยกเลิกการปิดเสียง ต้องใช้คำสั่งเลิกปิดเสียงโดยตรง

ก่อนแสดงปุ่ม ให้ตรวจตารางความสามารถรายแพลตฟอร์ม เอกสารปัจจุบันระบุการบล็อก เลิกบล็อก และอ่านรายการบล็อกสำหรับ WhatsApp ส่วนการปิดเสียงรองรับ WhatsApp และรองรับ LINE บางส่วน การเลิกปิดเสียงก็รองรับ LINE ด้วย แม้ทีมจะรวม LINE กับ WhatsApp ในกล่องเดียวกัน เส้นทางร่วมไม่ได้หมายความว่าทุกแพลตฟอร์มทำงานเหมือนกัน คำสั่งที่แพลตฟอร์มไม่รองรับจะคืน 501 unsupported_by_provider

อย่าสร้างตัวระบุสำหรับบล็อกขึ้นเอง

คำสั่งบล็อกและเลิกบล็อก WhatsApp ไม่รับเบอร์โทรหรือ JID แบบ @s.whatsapp.net แทน LID มาตรฐาน ให้รับตัวระบุจริงผ่านขั้นตอนผู้ติดต่อตามเอกสาร อย่าเติม @lid ต่อท้ายเบอร์โทรแล้วถือว่าเป็นคนเดียวกัน

ผลตอบกลับผู้ติดต่ออาจมี id, provider_user_id และ conversation_id ที่ต่างกัน ควรเก็บความหมายของแต่ละค่าไว้ คู่มือ Contact API กับ vCardอธิบายด้วยว่าการแก้สมุดรายชื่อกับการส่งข้อมูลผู้ติดต่อเป็นคนละคำสั่ง บทความนี้ไม่ได้กำหนดว่าคุณต้องเพิ่มบุคคลนั้นเป็นผู้ติดต่อก่อนจึงจะบล็อกได้

ออกแบบการตัดสินใจก่อนเรียก API

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

ขั้นตอนที่แนะนำสำหรับแอป:

1. ตั้งชื่อปุ่มแยกกัน ใช้ “ปิดเสียงแจ้งเตือน”, “บล็อกผู้ติดต่อ” และ “พักตอบกลับอัตโนมัติ” โดยระบุบัญชีรับส่งข้อความและเป้าหมายที่เลือก
2. ยืนยันเป้าหมาย ใช้ LID มาตรฐานที่ตรวจสอบแล้วและสัมพันธ์กับบัญชีนั้น หากไม่แน่ใจให้หยุดส่งต่อให้คนตรวจ ไม่คาดเดา
3. บันทึกเจตนาในระบบ เก็บผู้ดำเนินการ เหตุผล เป้าหมาย และคำสั่งที่ขอ ข้อมูลเหล่านี้เป็นบันทึกตรวจสอบของแอป ไม่ใช่ฟิลด์เพิ่มเติมในคำขอ API
4. ตรวจผลลัพธ์ ผลตอบกลับการเปลี่ยนแปลงมี data.ok อย่าแสดงว่าสำเร็จเพียงเพราะกดปุ่ม เก็บข้อผิดพลาดที่ปิดบังข้อมูลอ่อนไหวแล้วและ request_id สำหรับตรวจสอบ
5. ตรวจสอบเมื่อผลไม่ชัดเจน หากคำขอบล็อกหรือเลิกบล็อกหมดเวลา ให้อ่านรายการบล็อกก่อนส่งการเปลี่ยนแปลงอีกครั้ง เปรียบเทียบตัวระบุอย่างสม่ำเสมอ dhash บอกได้ว่ารายการเปลี่ยน แต่ไม่ได้บอกว่าใครเปลี่ยนหรือเพราะอะไร
6. จัดการคิวอัตโนมัติแยกต่างหาก งานที่สร้างก่อนการตัดสินใจอาจยังอยู่ในฐานข้อมูล ให้ worker ตรวจนโยบายพักในแอปก่อนส่ง อย่าถือว่าการตั้งค่าฝั่งแพลตฟอร์มยกเลิกคิวของคุณแล้ว

สำหรับการเปลี่ยนสถานะปิดเสียง เอกสารเหตุการณ์ระบุ conversation.updated พร้อมค่าเช่น muted และ mute_until ใช้เหตุการณ์ที่ได้รับเป็นข้อมูลสังเกตสถานะ ไม่ใช่คำรับประกันว่าทุกคำสั่งจะมีเหตุการณ์ยืนยัน แค็ตตาล็อกสาธารณะไม่ได้ระบุเหตุการณ์ผู้ติดต่อถูกบล็อก จึงควรใช้รายการบล็อกที่มีเอกสารแทนการสมมติเหตุการณ์ขึ้นมา

การตรวจรับและข้อจำกัด

ทดสอบด้วยบัญชีที่คุณควบคุม ตรวจว่า UI แยกคำสั่งล้มเหลวกับคำสั่งที่มีผลแล้ว การเปิดเสียงไม่เรียกเลิกบล็อก และการเลิกบล็อกไม่ปล่อยงานตอบกลับเก่าโดยอัตโนมัติ ทดสอบตัวระบุที่ถูกปฏิเสธและคำขอหมดเวลาที่ไม่ทราบผลด้วย ทั้งหมดนี้เป็นข้อเสนอการทดสอบ ไม่ใช่ผลที่รายงานว่าทำแล้ว

อย่าใช้การปิดเสียงเพื่อควบคุมการไหลของ webhook เอกสารระบุว่าเปลี่ยนสถานะการสนทนา ไม่ได้ระบุว่าปิดการส่งเหตุการณ์ และบทความนี้ไม่ได้รับประกันว่าการบล็อกจะลบข้อความที่เก็บไว้ จัดการสมาชิกในกลุ่มร่วม หรือยกเลิกงานใน CRM ต้องกำหนดพฤติกรรมเหล่านั้นต่างหาก

หากเจ้าหน้าที่ใช้แอป WhatsApp โดยตรงก็เพียงพอ ให้ใช้การควบคุมในแอปนั้น หากต้องการการเชื่อมต่อธุรกิจอย่างเป็นทางการ ให้ประเมินสัญญาของช่องทางนั้นแยกกัน อย่าถือว่าเส้นทาง UnifyPort เหล่านี้คือ endpoint ทางการของ WhatsApp

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

ปิดเสียงแล้วระบบจะหยุดตอบอัตโนมัติหรือไม่?

อย่าสรุปเช่นนั้น ต้องมีสถานะพักในแอปให้ worker ตรวจ เอกสารไม่ได้กำหนดการปิดเสียงเป็นคำสั่งยกเลิกงาน

ใช้ JID จากเบอร์โทรบล็อกได้หรือไม่?

ไม่ได้สำหรับคำสั่ง WhatsApp ที่ UnifyPort ระบุ ต้องใช้ digits@lid มาตรฐาน ไม่ใช่เบอร์โทรหรือค่า @s.whatsapp.net

เลิกบล็อกแล้วจะได้รับข้อความช่วงที่บล็อกหรือไม่?

ไม่ คู่มือ WhatsApp ระบุว่าจะไม่ได้รับข้อความเหล่านั้น จึงไม่ควรเสนอการบล็อกเป็นที่พักข้อความที่กู้คืนได้

dhash เปลี่ยนแปลว่าคำสั่งของฉันสำเร็จหรือไม่?

ค่านั้นอย่างเดียวพิสูจน์ไม่ได้ เพราะเป็นลายนิ้วมือของทั้งรายการ ต้องตรวจว่าเป้าหมายอยู่หรือไม่อยู่ในรายการ และเก็บผลคำสั่งแยกไว้

ขั้นตอนถัดไปและแหล่งข้อมูล

เริ่มจากเอกสารบล็อกผู้ติดต่อ แล้วตรวจการจับคู่ตัวระบุก่อนเปิดปุ่มในกล่องข้อความร่วม

ตรวจสอบเมื่อ 2026-09-25:

• WhatsApp: ปิดเสียงและเปิดเสียงการแจ้งเตือนแชต
• WhatsApp: บล็อกและรายงานบุคคล
• UnifyPort: ความสามารถรายแพลตฟอร์ม
• UnifyPort: ผลตอบกลับรายการบล็อก