เชื่อม Yeastar Cloud PBX API กับ CRM

เริ่มจาก Workflow ทางธุรกิจ ไม่ใช่เริ่มจาก API

โครงการเชื่อมต่อระบบโทรศัพท์ส่วนใหญ่มักเริ่มด้วยคำขอสั้นๆ ว่า "เราต้องการใช้ Yeastar API" ซึ่งกว้างเกินกว่าจะนำไปออกแบบได้จริง ในทางปฏิบัติ องค์กรเชื่อมต่อระบบโทรศัพท์เพื่อให้ได้ผลลัพธ์ทางธุรกิจที่ชัดเจนเพียงไม่กี่อย่าง และแต่ละผลลัพธ์ใช้ช่องทาง ทิศทางของข้อมูล และข้อจำกัดด้านเวลาที่แตกต่างกัน

ก่อนเขียนโค้ดบรรทัดแรก ให้อธิบายแต่ละ Workflow เป็นสามส่วน ได้แก่ เหตุการณ์ที่เป็นตัวเริ่มต้น (สิ่งที่เกิดขึ้นในระบบโทรศัพท์หรือในแอปพลิเคชันธุรกิจ) ข้อมูลที่ต้องส่งระหว่างระบบ และอุปกรณ์หรือโปรแกรมที่ทำหน้าที่รับส่งเสียงสนทนาจริง เมื่อเขียนคำตอบทั้งสามข้อไว้ชัดเจน การเลือกระหว่าง Integration สำเร็จรูป การตั้งค่าแบบ Template หรือการพัฒนา Middleware เองจะกลายเป็นการตัดสินใจทางวิศวกรรมที่มีเหตุผล ไม่ใช่การเดา

Yeastar P-Series Cloud Edition มี Developer API สำหรับส่งคำสั่งและดึงข้อมูล และมีการส่ง Event ผ่าน WebSocket หรือ Webhook ตัว PBX ทำหน้าที่เป็นชิ้นส่วนพื้นฐาน ส่วนแอปพลิเคชันหรือ Middleware ขององค์กรรับผิดชอบกฎทางธุรกิจ สิทธิ์ของผู้ใช้ การจับคู่ข้อมูลใน CRM และการเก็บบันทึกตรวจสอบ การแบ่งหน้าที่ให้ชัดตั้งแต่ต้นช่วยลดงานแก้ไขซ้ำที่เราพบบ่อยในโครงการเชื่อมต่อระบบ

• Click-to-call: พนักงานคลิกเบอร์ลูกค้าใน CRM แล้ว PBX โทรออกผ่าน Extension ของพนักงานคนนั้น
• Screen pop: สายเรียกเข้าทำให้ระบบค้นหาข้อมูลใน CRM เพื่อให้พนักงานเห็นประวัติลูกค้าระหว่างที่โทรศัพท์กำลังดัง
• งานติดตามผลอัตโนมัติ: สายที่ไม่มีผู้รับหรือถูกวางสายในคิวสร้าง Task หรือ Ticket โทรกลับ หนึ่งครั้งต่อหนึ่งสาย ไม่ใช่หนึ่งครั้งต่อการดังหนึ่งรอบ
• รายงานและการวิเคราะห์: ข้อมูล CDR ส่งเข้า Dashboard รายงานระดับการให้บริการ และการวิเคราะห์ขั้นต่อไปตามต้องการ

ตรวจสอบ Edition, Plan และ Firmware ก่อนออกแบบ

Yeastar P-Series มีมากกว่าหนึ่ง Edition และผู้ให้บริการ Hosting มักเรียกหลาย Edition รวมกันว่า "Cloud PBX" บทความนี้เขียนสำหรับ P-Series Cloud Edition และอ้างอิง Developer Guide ของ Cloud Edition บน help.yeastar.com หากระบบของคุณเป็น Edition อื่น ให้ใช้ Developer Guide ที่ตรงกับ Edition นั้น เพราะเงื่อนไขและช่องทางที่ใช้ได้อาจแตกต่างกัน

การที่ช่องทางใดใช้งานได้หรือไม่ ขึ้นกับสามปัจจัยพร้อมกัน คือ Edition, Firmware ที่ติดตั้งอยู่ และ Plan ที่สมัครไว้ หน้าสรุป Interface ของ Cloud Edition ระบุความสามารถอย่างการดึง CDR, URL สำหรับดาวน์โหลดไฟล์บันทึกเสียง, การสมัครรับ Event และการตั้งค่า WebSocket Audio Streaming แต่รายการนั้นอธิบายตัวผลิตภัณฑ์ ไม่ได้ยืนยันสิทธิ์ของ Tenant ของคุณ อย่าสันนิษฐานว่าทุก Tenant เรียกใช้ได้ทุก Endpoint

บางฟีเจอร์มีเงื่อนไขเฉพาะของตัวเอง ตัวอย่างเช่น Yeastar ระบุว่า Linkus SDK for Web บน Cloud Edition ต้องใช้ Ultimate Plan และ Firmware 84.12.0.32 ขึ้นไป Linkus SDK เป็นผลิตภัณฑ์แยกจาก Developer API พื้นฐาน ดังนั้นการผ่านเงื่อนไขของ SDK ไม่ได้บอกอะไรเกี่ยวกับ Endpoint อื่น และในทางกลับกันก็เช่นกัน

วิธีที่ปลอดภัยที่สุดคือจัดทำรายการตรวจสอบก่อนประชุมออกแบบ ได้แก่ Edition, เวอร์ชัน Firmware, Plan, สถานะการเปิดใช้ API ของ Tenant และฟีเจอร์ที่ผู้ให้บริการ Hosting อนุญาตให้ใช้ จากนั้นตรวจสอบแต่ละช่องทางที่วางแผนไว้กับหน้าเอกสารทางการฉบับปัจจุบันของช่องทางนั้น

เลือกวิธีเชื่อมต่อให้เหมาะกับงาน

การเชื่อม Yeastar P-Series กับซอฟต์แวร์ธุรกิจทำได้หลายวิธี และวิธีที่เหมาะสมขึ้นกับว่า Workflow ต้องการตรรกะเฉพาะมากแค่ไหน การเลือกวิธีที่เบาที่สุดที่ยังตอบโจทย์ได้ ช่วยให้ระบบดูแลและอัปเกรดง่ายกว่าในระยะยาว

ให้พิจารณา Integration ที่มีอยู่แล้วเป็นอันดับแรก Yeastar เผยแพร่คู่มือการเชื่อมต่อกับแอปพลิเคชันภายนอกจำนวนหนึ่ง หากมีรายการที่ครอบคลุม CRM หรือ Helpdesk ของคุณ ให้ทดสอบกับ Workflow จริง รวมถึงฟิลด์ที่กำหนดเอง กฎความเป็นเจ้าของข้อมูล และการสร้าง Ticket ก่อนตัดสินใจสร้างระบบใหม่

Middleware ที่พัฒนาเองเป็นคำตอบที่ถูกต้องเมื่อ Workflow ต้องการตรรกะทางธุรกิจที่ PBX ทำเองไม่ได้ เช่น การจับคู่ผู้โทรข้ามหลายฐานข้อมูล การป้องกัน Task ติดตามผลซ้ำ การบังคับสิทธิ์รายทีม หรือการเก็บบันทึกตรวจสอบ Middleware จะรับ Event จาก PBX เรียก PBX API เมื่อต้องสั่งงาน และคุยกับระบบปลายทางผ่าน API ของระบบนั้นๆ

โปรแกรมโทรศัพท์ที่ฝังในแอปพลิเคชันเป็นการตัดสินใจอีกเรื่องหนึ่ง หากพนักงานต้องคุยสายภายในเว็บแอปพลิเคชันโดยไม่มีโทรศัพท์ตั้งโต๊ะหรือ Softphone แยก ให้พิจารณา Linkus SDK ซึ่งดังที่กล่าวข้างต้น Linkus SDK for Web บน Cloud Edition มีเงื่อนไขด้าน Plan และ Firmware ของตัวเอง ควรตรวจสอบก่อนเลือกแนวทางนี้

จับคู่ความต้องการทางธุรกิจกับกลไกของ PBX

เมื่อเขียน Workflow ครบแล้ว ให้จับคู่แต่ละความต้องการกับกลไกของ PBX และกับตรรกะที่ซอฟต์แวร์ขององค์กรต้องเพิ่มเอง PBX มีคำสั่ง Event และบันทึกข้อมูลให้ แต่ไม่รู้ว่าผู้ใช้ CRM คนใดดูแลลูกค้ารายใด สายใดควรเปิด Ticket หรือใครมีสิทธิ์ฟังไฟล์บันทึกเสียง

ตารางด้านล่างเป็นเครื่องมือช่วยวางแผน ไม่ใช่รายการ Endpoint ที่รับประกันว่ามีอยู่ ให้ยืนยันช่องทางที่แน่นอนของแต่ละแถวกับ Cloud Edition Developer Guide ที่ตรงกับ Firmware และ Plan ของคุณ

แยกเส้นทางคำสั่ง Event และเสียงออกจากกัน

การเชื่อมต่อระบบโทรศัพท์ใช้เส้นทางสามแบบที่ต่างกัน และบั๊กที่สับสนที่สุดส่วนใหญ่เกิดจากการปนเส้นทางเหล่านี้เข้าด้วยกัน

คำสั่งและการดึงข้อมูลเดินทางผ่าน API แบบ REST โดย Backend ส่งคำขอ เช่น ขอข้อมูล CDR หรือสั่งให้ PBX โทรออกในกรณีที่เอกสารระบุว่ารองรับ แล้วได้รับคำตอบกลับมา คำตอบที่สำเร็จหมายความว่า PBX รับคำขอแล้ว ไม่ได้บอกว่าหลังจากนั้นเกิดอะไรขึ้นกับสาย

Event เดินทางจาก PBX มายังซอฟต์แวร์ขององค์กร Yeastar ระบุช่องทางส่ง Event สำหรับ Cloud Edition ไว้สองแบบ คือ การเชื่อมต่อ WebSocket ที่ซอฟต์แวร์เปิดค้างไว้ และ Webhook ที่ PBX ส่งคำขอ HTTP มายัง Endpoint ที่องค์กรเปิดไว้ Event อธิบายการเปลี่ยนสถานะ และเป็นวิธีที่ซอฟต์แวร์รู้ว่าสายกำลังดัง ถูกรับ หรือจบแล้ว

เสียงเดินทางแยกออกไปอีกเส้นหนึ่ง เสียงสนทนาไหลระหว่างผู้ให้บริการโทรคมนาคมซึ่งเชื่อมกับ PBX ผ่าน SIP Trunk ตัว PBX และอุปกรณ์ที่พนักงานใช้ เช่น IP Phone, แอป Linkus หรือโปรแกรมที่ฝังในเว็บ ช่องทาง API และ Event รับส่งข้อมูลแบบข้อความ ไม่ได้รับส่งเสียงสนทนาสด

การแยกเส้นทางช่วยให้แก้ปัญหาได้เร็วขึ้น หากปุ่มใน CRM เริ่มสายได้แต่พนักงานไม่ได้ยินเสียง แสดงว่าคำสั่ง API ทำงานแล้ว และควรตรวจสอบที่การกำหนดเส้นทางของ SIP Trunk, NAT หรือกฎ Firewall สำหรับสัญญาณเสียง

• เส้นทางคำสั่ง: Backend ไปยัง PBX API แบบคำขอและคำตอบ
• เส้นทาง Event: PBX ไปยัง Backend ผ่าน WebSocket หรือ Webhook
• เส้นทางเสียง: ผู้ให้บริการโทรคมนาคม, SIP Trunk, PBX และอุปกรณ์โทรศัพท์
• ข้อมูลหลังจบสาย: CDR และไฟล์บันทึกเสียง ดึงผ่านช่องทางของแต่ละประเภท

ตัวอย่างการออกแบบ Workflow ที่ใช้งานจริงสามแบบ

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

แบบที่ 1: Click-to-call จาก CRM

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

ขึ้นกับอุปกรณ์และการตั้งค่า PBX โดยทั่วไปอุปกรณ์ของพนักงานจะดังหรือรับสายก่อน จากนั้น PBX จึงโทรหาลูกค้าผ่านเส้นทางโทรออก ซึ่งมักเป็น SIP Trunk Backend เก็บเลขอ้างอิงสายที่ PBX ส่งกลับมา เพื่อจับคู่ Event ที่ตามมากับกิจกรรมใน CRM

ให้ถือว่าคำตอบของ API หมายถึง "รับคำขอแล้ว" ไม่ใช่ "ลูกค้ารับสายแล้ว" บันทึกกิจกรรมว่าเชื่อมต่อสำเร็จเมื่อมี Event ยืนยันสถานะสายเท่านั้น และห้ามส่งคำสั่งโทรซ้ำโดยอัตโนมัติหลัง Timeout เพราะคำขอแรกอาจถึง PBX แล้วและโทรศัพท์ของลูกค้าอาจกำลังดังอยู่ ให้ตรวจสอบสถานะสายหรือบันทึกคำขอของระบบก่อนส่งคำขอใหม่

แบบที่ 2: Screen pop เมื่อมีสายเรียกเข้า

เมื่อมีสายเข้าที่เบอร์ DID ขององค์กร PBX จะกำหนดเส้นทางตามกฎสายเข้าที่ตั้งไว้และส่ง Event ของสาย Middleware ที่สมัครรับ Event จะได้รับเบอร์ผู้โทรและปลายทางของสาย

Middleware ปรับรูปแบบเบอร์ให้เป็นมาตรฐานเดียวกัน เช่น จัดการรหัสประเทศและ Prefix ของ Trunk อย่างสม่ำเสมอ ค้นหาใน CRM แล้วส่งผลลัพธ์ไปยังเบราว์เซอร์ของพนักงานที่โทรศัพท์กำลังดัง ระบบควรรองรับเบอร์ที่ถูกซ่อน เบอร์ที่ไม่รู้จัก และเบอร์ที่ตรงกับหลายรายการ ซึ่งการแสดงรายการสั้นๆ ให้เลือกดีกว่าการเดาเลือกให้

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

จากต้นแบบสู่ระบบใช้งานจริง

ต้นแบบที่ทำงานได้บนเครื่องของนักพัฒนายังไม่ใช่ระบบเชื่อมต่อที่พร้อมใช้งาน ความพร้อมสำหรับ Production ส่วนใหญ่ขึ้นกับการยืนยันตัวตน ความน่าเชื่อถือของ Event และการจัดการความผิดพลาด

CDR ไฟล์บันทึกเสียง และการวิเคราะห์ข้อมูล

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

หน้าสรุป Interface ของ Cloud Edition ระบุทั้งการดึงข้อมูล CDR และช่องทาง URL ดาวน์โหลดไฟล์บันทึกเสียง ฟิลด์ เวอร์ชัน และตัวกรองอาจต่างกันตาม Firmware จึงควรตรวจสอบหน้าเอกสาร CDR ที่ตรงกับเวอร์ชันของคุณก่อนออกแบบรายงาน และเผื่อไว้ว่าข้อมูลที่สร้างบน Firmware รุ่นเก่าอาจไม่มีฟิลด์ใหม่ทุกฟิลด์

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

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

ความปลอดภัยและขอบเขตการเข้าถึง

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

เก็บ Credential ของ PBX, Access Token และ Secret ของ Webhook ไว้ที่ Backend เท่านั้น เบราว์เซอร์ควรคุยกับ Backend ขององค์กร ซึ่งตรวจสอบว่าผู้ใช้เป็นใครและทำอะไรได้บ้างก่อนเรียก PBX ใช้ HTTPS และ WSS พร้อมใบรับรองที่ถูกต้องสำหรับทราฟฟิกการเชื่อมต่อทั้งหมด

แยกสิทธิ์ตามบทบาท หน้าจอของพนักงานต้องการเพียงการโทรออกจาก Extension ของพนักงานคนนั้น ไม่ควรดาวน์โหลดไฟล์บันทึกเสียงใดๆ ได้ตามใจ หรือแก้ไขการตั้งค่า PBX ได้ เครื่องมือรายงานควรอ่านข้อมูลได้อย่างเดียว ไม่ควรส่งคำสั่งควบคุมสาย

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

• Secret อยู่ที่ Backend เท่านั้น และเปลี่ยนใหม่เมื่อพนักงานหรือผู้รับจ้างเปลี่ยน
• ทุกคำสั่งที่ส่งถึง PBX ผ่านการตรวจสิทธิ์และบันทึกรายผู้ใช้
• คำขอ Webhook ผ่านการตรวจสอบ X-Signature ตามที่เอกสารระบุ
• ไฟล์บันทึกเสียงถูกดึงและแชร์ผ่านพื้นที่จัดเก็บที่ควบคุมได้เท่านั้น
• ระบบโทรออกอัตโนมัติมีการจำกัดอัตราและการแจ้งเตือน

วางแผนการเชื่อมต่อ Yeastar ร่วมกับ SIPPER

SIPPER ให้บริการ SIP Trunk และเลขหมาย DID สำหรับองค์กรในประเทศไทย ในการออกแบบทั่วไป SIPPER ให้การเชื่อมต่อกับเครือข่ายโทรศัพท์สาธารณะ Yeastar P-Series ดูแล Extension การกำหนดเส้นทางสาย และฟีเจอร์ของ PBX, CRM เก็บข้อมูลลูกค้า และ Middleware ทำหน้าที่ตามกฎทางธุรกิจขององค์กร

ก่อนเริ่มโครงการ ควรตกลงให้ชัดเรื่อง Edition, Firmware, Plan, Workflow ที่อยู่ในขอบเขต ผู้พัฒนา Middleware และผู้ดูแลระบบหลังเปิดใช้งาน คำตอบเหล่านี้มักกำหนดต้นทุนและระยะเวลามากกว่าตัวโค้ดเอง

หากต้องการปรึกษาการเชื่อมต่อ Yeastar หรือการออกแบบ SIP Trunk โทร 02-098-9500 หรืออีเมล sales@sipper.co.th แจ้ง CRM หรือแอปพลิเคชันที่ใช้ Workflow ที่ต้องการ จำนวนผู้ใช้ และปริมาณสายโดยประมาณ กรุณาอย่าส่ง API Secret หรือรหัสผ่านในการติดต่อครั้งแรก