ข้อความเสียงหรือสาย WhatsApp: เลือกวิธีให้บริการลูกค้า

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

บทความนี้เปรียบเทียบข้อความเสียง UnifyPort กับสายขาออกแบบตัวต่อตัวที่มนุษย์เริ่มผ่านอินเทอร์เฟซไม่เป็นทางการในรุ่นทดสอบแบบปิด ไม่ใช่คำแนะนำ Meta WhatsApp Business Calling API ดูการตั้งค่าแบบครบถ้วนได้ที่บทสอนการเชื่อมต่อสายเสียง

1. เลือกตามเวลาที่ลูกค้าสะดวก

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

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

2. ใช้โครงสร้างคำขอแยกกัน

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

สำหรับข้อความเสียง ส่งเนื้อหานี้ไปที่ POST /v1/messages:

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "message": {
    "type": "audio",
    "url": "https://cdn.example.com/support/explanation.ogg"
  }
}

แทน URL ตัวอย่างด้วยทรัพยากรเสียงที่เข้าถึงได้ ข้อกำหนดข้อความสื่อต้องมีแหล่งข้อมูลที่ไม่ว่างอย่างน้อยหนึ่งรายการใน message.url, message.file_url หรือ message.file_key และ URL ต้องเป็น HTTP(S) แบบสัมบูรณ์ ตัวอย่างนี้ส่งไฟล์ที่มีอยู่ ไม่ใช่ให้ API บันทึกไมโครโฟน นามสกุลไฟล์อย่างเดียวไม่ยืนยันว่าการเข้ารหัสเหมาะสม และคำขอนี้ไม่รับรองรูปแบบฟองข้อความเสียงดั้งเดิมแบบใดแบบหนึ่งหรือผลถอดเสียง

สำหรับสายเสียงสด ส่งเนื้อหาอีกแบบไปที่ POST /v1/calls:

{
  "account_id": "acc_example",
  "to": { "id": "<conversation_id>", "type": "user" },
  "media_type": "voice"
}

ข้อกำหนดการสร้างสายต้องได้รับสิทธิ์ทดสอบระดับเวิร์กสเปซจากฝ่ายสนับสนุน โดย is_beta เป็นแฟล็กแบบอ่านอย่างเดียว การตอบกลับสำเร็จ 201 ที่มี state: preparing หมายถึงลิงก์ส่วนตัวแบบใช้ครั้งเดียว join_url พร้อมแล้ว เจ้าหน้าที่ต้องเปิดและกด Start call ก่อน expires_at การเปิดหน้าอย่างเดียวไม่เริ่มโทร ช่วงเตรียมมีค่าเริ่มต้นสองนาทีนับจากสร้าง เซิร์ฟเวอร์ปรับได้ และไม่จำกัดความยาวของสายที่เชื่อมต่อแล้ว ต้องอนุญาตไมโครโฟน ส่วนกล้องเป็นตัวเลือก

3. เก็บหลักฐานผลลัพธ์ของแต่ละวิธีแยกกัน

สิ่งที่สังเกตได้	ข้อมูลที่ควรเก็บ	สิ่งที่ยังพิสูจน์ไม่ได้
ข้อความตอบกลับมี status: accepted	message_id ที่ได้และบัญชี	ส่งถึงแล้ว เล่นเสียงแล้ว หรือแก้ปัญหาแล้ว
ได้เหตุการณ์ส่งถึงหรืออ่านที่ตรงกัน	ขอบเขตใบตอบรับและรหัสข้อความที่เกี่ยวข้อง	ลูกค้าฟังเสียงแล้ว
สร้างสายแล้วได้ลิงก์ที่เตรียมพร้อม	call_id ที่ได้และงานบริการที่มอบหมาย	เริ่มโทรหรือเชื่อมต่อแล้ว
ได้รับ call.answered	หลักฐานเชื่อมต่อของ data.call.id	แก้ปัญหาแล้ว
ได้รับ call.ended	เหตุผลที่สิ้นสุดและ duration_seconds	ศูนย์วินาทีพิสูจน์ว่าไม่เคยเชื่อมต่อ

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

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

4. ทำให้เจ้าหน้าที่เห็นการกระทำชัดเจน

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

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

5. เปลี่ยนวิธีติดต่อ ต้องตัดสินใจใหม่

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

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

6. เริ่มจากงานบริการที่ชัดเจนหนึ่งงาน

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

ขอบเขตการโทรปัจจุบันไม่รวมสายเข้า โทรกลุ่ม บันทึกเสียง ถอดเสียง SIP/PBX หรือ AI โทรออกเอง หากต้องการหารือสิทธิ์และสถานการณ์บริการเฉพาะ ให้ติดต่อฝ่ายสนับสนุนด้านเทคนิคโดยไม่แชร์ API key หรือลิงก์สายส่วนตัว