หน้านี้มีแนวทางปฏิบัติแนะนำสำหรับการสร้างประสบการณ์การใช้งาน RCS สำหรับธุรกิจที่มีประสิทธิภาพและน่าสนใจ ซึ่งครอบคลุมทั้ง การติดตั้งใช้งานทางเทคนิค และ การออกแบบการสนทนา
หลักเกณฑ์ทางเทคนิค
ตรวจสอบความสามารถของอุปกรณ์
ก่อนเริ่มการสนทนากับผู้ใช้ ให้ตรวจสอบว่าอุปกรณ์ของผู้ใช้รับข้อความ RCS ได้ หากต้องการระบุความสามารถของผู้ใช้ ให้ส่ง การตรวจสอบความสามารถ, และปรับแต่งการโต้ตอบของตัวแทนตามความเหมาะสม โต้ตอบกับผู้ใช้ในรูปแบบที่อุปกรณ์ของผู้ใช้รองรับเท่านั้น หากอุปกรณ์ของผู้ใช้ไม่ได้เปิดใช้ RCS ให้ตั้งค่าวิธีการสื่อสารสำรองด้วยช่องทางอื่น เช่น SMS
ปฏิบัติตามขนาดข้อความสูงสุด
ข้อความ RCS สำหรับธุรกิจและไฟล์สื่อที่ข้อความดังกล่าวมีได้จะมีขนาดสูงสุด ดูรายละเอียดได้ที่ ขนาดข้อความสูงสุด
ป้องกันการส่งข้อความที่ซ้ำ
ระบบต้องยืนยันก่อนว่าข้อความไม่ได้ส่งถึงผู้ใช้ก่อนที่จะลองส่งข้อความ SMS สำรอง เพื่อหลีกเลี่ยงการส่งข้อความที่ซ้ำถึงผู้ใช้
ทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อปรับปรุงความน่าเชื่อถือของระบบและป้องกันข้อความที่ซ้ำ
- ตั้งค่าอายุการใช้งานของ Connection Pool ให้ตรงกับ TTL (Time to Live) ของ DNS: ใช้ Connection Pool และ Client Object Pool เพื่อนำการเชื่อมต่อและออบเจ็กต์ไคลเอ็นต์ที่มีอยู่กลับมาใช้ซ้ำ หากต้องการหลีกเลี่ยงการใช้ที่อยู่ IP ที่ล้าสมัยหลังจากอัปเดต DNS ให้ตั้งค่าเวลาสูงสุดที่การเชื่อมต่อหรือออบเจ็กต์จะอยู่ในพูลให้ตรงกับ Time to Live (TTL) ของ DNS ของ API
- อย่าคิดว่าการหมดเวลาการเชื่อมต่อหมายถึงการส่งไม่สำเร็จ: อย่าคิดว่าการหมดเวลาการเชื่อมต่อหมายความว่าข้อความ RCS สำหรับธุรกิจไม่ได้ส่ง ข้อความอาจยังคงอยู่ระหว่างการประมวลผลในฝั่งเซิร์ฟเวอร์
- ยืนยันใบตอบรับการส่ง: ตรวจสอบใบตอบรับการส่งทุกครั้งก่อนที่จะทริกเกอร์ข้อความสำรอง
- ตั้งค่า TTL ให้ตรงกับการหมดเวลาการเชื่อมต่อ: ตั้งค่า TTL ของข้อความให้ตรงกับการหมดเวลาการเชื่อมต่อทุกครั้งที่ทำได้
- เพิกถอนข้อความก่อนส่งข้อความสำรอง: พยายามเพิกถอนข้อความเดิมทุกครั้งก่อนส่งข้อความ SMS สำรอง หากเพิกถอนไม่สำเร็จ ให้จัดการกับความล้มเหลว เนื่องจากอาจบ่งบอกว่าข้อความส่งถึงผู้ใช้แล้ว
- ลองส่งข้อความอีกครั้ง: หากข้อความส่งไม่สำเร็จเนื่องจากข้อผิดพลาดที่ลองใหม่ได้หรือ
การหมดเวลาการเชื่อมต่อ ให้ลองดำเนินการส่งอีกครั้ง ใช้
messageIDเริ่มต้นเพื่อ ป้องกันข้อความที่ซ้ำ และ ใช้ Exponential Backoff เพื่อเว้นระยะการลองใหม่
ตรวจสอบข้อความขาเข้าที่ซ้ำ
เมื่อตรวจสอบและตอบกลับข้อความขาเข้าจากผู้ใช้ ให้ตรวจสอบ messageId และยืนยันว่าคุณยังไม่ได้รับและตอบกลับข้อความดังกล่าว
ระบบแบบกระจายมีวิธีส่งข้อความ 2 วิธี ดังนี้
- อย่างมาก 1 ครั้ง: ระบบจะส่งข้อความ 1 ครั้ง แต่หากมีข้อผิดพลาดเกี่ยวกับเครือข่าย หรือการสื่อสารระหว่างทาง ผู้รับอาจไม่ได้รับข้อความ
- อย่างน้อย 1 ครั้ง: ระบบอาจส่งข้อความหลายครั้ง แต่ ผู้รับจะได้รับข้อความแม้ว่าจะมีข้อผิดพลาดเกี่ยวกับเครือข่ายหรือการสื่อสาร
Google Cloud Pub/Sub ใช้ระบบอย่างน้อย 1 ครั้ง แม้ว่าระบบนี้อาจทำให้เกิดข้อความขาเข้าที่ซ้ำ แต่คุณก็สามารถนำข้อความที่ซ้ำออกได้อย่างง่ายดายโดยการติดตามสตริง messageId หากได้รับข้อความแล้ว คุณสามารถละเว้นข้อความเพิ่มเติมที่ได้รับซึ่งมี messageId เดียวกันได้
ใช้รหัสที่ไม่ซ้ำกันสำหรับข้อความขาออกทั้งหมด
เมื่อตัวแทนส่งข้อความถึงผู้ใช้ messageId ที่คุณใส่ในการเรียก API ต้องไม่ซ้ำกันสำหรับทุกข้อความ
ดูข้อมูลเพิ่มเติมเกี่ยวกับการรับข้อความได้ที่ หัวข้อจัดการเหตุการณ์ขาเข้า
อย่าใช้ที่อยู่ IP ที่ล้าสมัย
ระบบต้องใช้ที่อยู่ IP ที่ถูกต้องและเป็นปัจจุบันเสมอเมื่อเชื่อมต่อกับ RBM API แพลตฟอร์มการเขียนโปรแกรมต่างๆ ใช้การหมดเวลาแคช DNS เริ่มต้นซึ่งอาจนานกว่าการตั้งค่า TTL ของ DNS ของ Google อย่างมาก ซึ่งอาจทำให้ระบบพยายามเชื่อมต่อกับที่อยู่ IP ที่หมดอายุแล้วและทำให้เกิดการหมดเวลา TTL ของแคช DNS ของโดเมน RBM คือ 300 วินาที
ทำตามขั้นตอนต่อไปนี้เพื่อให้แน่ใจว่าตรรกะการเชื่อมต่อเป็นไปตาม TTL 300 วินาที
- ตั้งค่าการหมดเวลาของ Connection Pool ให้ตรงกับ TTL: หากคุณใช้ Connection Pool หรือ Client Object Pool ให้ตั้งค่าอายุการใช้งานสูงสุดเป็น 300 วินาที (หรือน้อยกว่า) การดำเนินการนี้จะบังคับให้ระบบดึงที่อยู่ IP ใหม่เมื่อออบเจ็กต์ได้รับการรีเฟรช
- ตรวจสอบการรีเฟรช DNS: ยืนยันว่าแพลตฟอร์มหรือไลบรารีของไคลเอ็นต์ HTTP ของคุณตั้งค่าให้รีเฟรชแคช DNS ทุกๆ 300 วินาทีหรือน้อยกว่า
- ตรวจสอบ TTL ปัจจุบัน: เราขอแนะนำให้ตรวจสอบ TTL ของโดเมน RBM API แบบเป็นโปรแกรมเพื่อให้แน่ใจว่าคุณใช้ค่าสูงสุดที่ถูกต้อง คุณต้องตรวจสอบโดเมนที่สอดคล้องกับภูมิภาคการติดตั้งใช้งาน
dig +nocmd +noall +answer +ttlid A us-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A asia-rcsbusinessmessaging.googleapis.com | sort
dig +nocmd +noall +answer +ttlid A europe-rcsbusinessmessaging.googleapis.com | sort
ใช้การลองใหม่ด้วย Exponential Backoff
เมื่อเรียก API ใดก็ตาม การเรียกอาจล้มเหลวเนื่องจากปัญหาเกี่ยวกับโครงสร้างพื้นฐาน การโอเวอร์โหลดบริการ ขีดจำกัด QPS และข้อผิดพลาดอื่นๆ ใช้การลองใหม่ด้วย Exponential Backoff เพื่อกู้คืนจากการเรียก API ที่ล้มเหลวอย่างราบรื่น
เมื่อใช้การลองใหม่ด้วย Exponential Backoff โครงสร้างพื้นฐานจะดำเนินการต่อไปนี้โดยอัตโนมัติ
- ระบุการเรียก API ที่ล้มเหลว
- ตั้งค่าระยะเวลารอเริ่มต้นและจำนวนการลองใหม่สูงสุด
- หยุดชั่วคราวตามระยะเวลารอ
- ลองเรียก API อีกครั้ง
ประเมินการตอบกลับของการเรียก API
- หากสำเร็จ ให้ดำเนินการตามขั้นตอนถัดไปในเวิร์กโฟลว์
- หากล้มเหลว ให้เพิ่มระยะเวลารอและกลับไปที่ขั้นตอนที่ 3
- หากล้มเหลวหลังจากลองใหม่ครบจำนวนครั้งสูงสุด ให้เข้าสู่สถานะล้มเหลว
ระยะเวลารอที่เหมาะสมและจำนวนการลองใหม่สูงสุดที่เหมาะสมจะแตกต่างกันไปตามกรณีการใช้งาน กำหนดตัวเลขเหล่านี้ตามข้อกำหนดด้านเวลาในการตอบสนองของโครงสร้างพื้นฐานและเวิร์กโฟลว์
เพิ่มประสิทธิภาพ API ด้วยปลายทางระดับภูมิภาค
หากต้องการเพิ่มประสิทธิภาพ API เพื่อลดเวลาในการตอบสนอง ให้ใช้ปลายทางที่อยู่ใกล้กับภูมิภาคของผู้ใช้มากที่สุด
ตารางต่อไปนี้แสดงคำแนะนำเกี่ยวกับปลายทาง RCS สำหรับธุรกิจระดับภูมิภาคที่จะใช้โดยขึ้นอยู่กับหมายเลขโทรศัพท์ของผู้ใช้
| คำนำหน้าหมายเลขโทรศัพท์ | ปลายทางที่แนะนำ | ภูมิภาคทางภูมิศาสตร์ |
|---|---|---|
| +1 | us-rcsbusinessmessaging.googleapis.com | อเมริกา |
| +2 | europe-rcsbusinessmessaging.googleapis.com | ยุโรป |
| +3 | europe-rcsbusinessmessaging.googleapis.com | ยุโรป |
| +4 | europe-rcsbusinessmessaging.googleapis.com | ยุโรป |
| +5 | us-rcsbusinessmessaging.googleapis.com | อเมริกา |
| +6 | asia-rcsbusinessmessaging.googleapis.com | เอเชีย |
| +7 | europe-rcsbusinessmessaging.googleapis.com | ยุโรป |
| +8 | asia-rcsbusinessmessaging.googleapis.com | เอเชีย |
| +9 | asia-rcsbusinessmessaging.googleapis.com | เอเชีย |
| ค่าเริ่มต้น | us-rcsbusinessmessaging.googleapis.com | อเมริกา |
หลังจากระบุปลายทางเป้าหมายแล้ว ให้พยายามวางเซิร์ฟเวอร์ไว้ใกล้กับปลายทางดังกล่าวมากที่สุด คุณดูรายการสถานที่ที่พร้อมให้บริการได้ในหน้า https://www.google.com/about/datacenters/locations/
ดูข้อมูลเพิ่มเติมเกี่ยวกับการระบุภูมิภาคของตัวแทนได้ในเอกสารประกอบเรื่อง สร้างตัวแทน
UI การสนทนาและประสบการณ์ของผู้ใช้
UI การสนทนา ไม่ใช่ UI ของแอป
ตัวแทน RCS สำหรับธุรกิจเหมาะอย่างยิ่งสำหรับการมอบหมายงานที่มีประสิทธิภาพและเฉพาะเจาะจงให้กับผู้ใช้ในอินเทอร์เฟซผู้ใช้แบบการสนทนา ตัวแทนที่ออกแบบมาอย่างดีจะทำให้การโต้ตอบมุ่งเน้น ชัดเจน และมีโครงสร้างเหมือนการสนทนาตามธรรมชาติ
ตัวแทนไม่สามารถอาศัย UI แบบภาพของแอปหรือหน้าเว็บ และไม่ควรพยายามเลียนแบบ UI ดังกล่าว แต่ตัวแทนต้องอาศัยการสนทนาที่สร้างขึ้นอย่างรอบคอบซึ่งตอบสนองความต้องการของผู้ใช้โดยการแนะนำด้วยคำพูด คำแนะนำ และการจัดการข้อผิดพลาดที่ดี
นอกจากนี้ ตัวแทนไม่ควรเลียนแบบระบบโทรศัพท์อัตโนมัติหรืออินเทอร์เฟซที่อาศัยการตอบกลับของผู้ใช้ด้วยตัวเลขที่แสดงถึงการดำเนินการที่กำหนด ผู้ใช้ควรสื่อสารกับตัวแทนได้อย่างเป็นธรรมชาติ เช่นเดียวกับการสื่อสารกับบุคคลอื่นในการสนทนา
เริ่มการสนทนา
การเริ่มต้นการสนทนาจะกำหนดความคาดหวังของผู้ใช้เกี่ยวกับสิ่งที่ตัวแทนทำได้ เริ่มการสนทนาด้วยข้อความที่น่าสนใจ แสดงบุคลิกของตัวแทน ใส่ข้อมูลที่ผู้ใช้สนใจไว้ด้านหน้า และแชร์สิ่งที่ตัวแทนทำได้ ให้ตัวเลือกที่ชัดเจนแก่ผู้ใช้ในการโต้ตอบกับตัวแทนและสนทนาต่อ
แสดงบุคลิกของตัวแทน: กำหนดน้ำเสียงโดยทักทายผู้ใช้และ แนะนำแบรนด์ หากคุณสร้างบุคลิกสมมติให้ตัวแทน เช่น ผู้ช่วยเสมือนหรือเจ้าหน้าที่อำนวยความสะดวกดิจิทัล ให้ระบุอย่างชัดเจนว่าเป็นแชทบ็อต ไม่ใช่คนจริง คุณสามารถตั้งชื่อตัวแทนให้ตรงกับบุคลิกสมมติได้ อวาตาร์เป็นวิธีที่ยอดเยี่ยมในการเสริมสร้างภาพลักษณ์ อวาตาร์อาจเป็นโลโก้ของคุณ แต่ตัวการ์ตูนกราฟิกก็ใช้ได้เช่นกัน
แชร์สิ่งที่ตัวแทนทำได้: ข้อความทักทายที่ดีจะระบุสิ่งที่การสนทนาเสนอได้อย่างชัดเจน อธิบายความสามารถของตัวแทนในระดับสูง นอกจากนี้ ยังรวมถึง คำตอบ และการดำเนินการ ที่แนะนำเพื่อนำผู้ใช้ไปตามเส้นทางที่เฉพาะเจาะจง ใช้คำแนะนำเหล่านี้เพื่อช่วยให้ผู้ใช้ไปยังส่วนต่างๆ ของการสนทนาและเข้าใจงานที่ตัวแทนช่วยเหลือได้
เขียนข้อความที่ชัดเจนและสอดคล้องกัน
ส่งข้อความที่ผู้ใช้เข้าใจและตอบกลับได้ง่าย สร้างข้อความที่แจ้งให้ผู้ใช้ตอบกลับ รักษาสไตล์ รูปแบบ และจังหวะที่สอดคล้องกันเพื่อสร้างความเชื่อมั่นกับผู้ใช้
โปรดคำนึงถึงแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้เมื่อสร้างข้อความ
อย่าสร้างทางตัน ข้อความแต่ละข้อความควรนำไปสู่ขั้นตอนถัดไปที่มีความหมาย
- หากเส้นทางของผู้ใช้มีงานที่มีหลายขั้นตอน ให้ใช้เครื่องหมายวาทกรรมเพื่อแนะนำผู้ใช้ตลอดกระบวนการ
เช่น ตอนนี้… และ… เข้าใจแล้ว! นี่ครับ/ค่ะ…
- เขียนข้อความให้กระชับ เนื่องจาก คำตอบที่แนะนำ และ การดำเนินการ มีความยาวสูงสุด 25 ตัวอักษร
- หากการสนทนามีการโอนสาย การรับทราบอย่างรวดเร็วจะช่วยให้การเปลี่ยนผ่านราบรื่นขึ้น
เช่น "ตกลงครับ/ค่ะ ผู้จัดการบัญชีของคุณจะดูแลต่อจากนี้"
เช่น "เยี่ยมเลยครับ/ค่ะ! ผม/คิดว่าผม/ทราบแล้วว่าคุณกำลังมองหาอะไร" แล้ว ใส่ลิงก์ไปยังเว็บไซต์
รับทราบข้อความของผู้ใช้ด้วยคำหรือวลีที่แสดงการรับรู้
เช่น "เลือกได้ดีมาก!", "ตกลง", "ได้เลย" หรือ "เข้าใจแล้ว"
พูดคุยกับผู้ใช้โดยตรงโดยใช้ชื่อของผู้ใช้ (หากทราบ) หรือคำสรรพนาม "คุณ" หลีกเลี่ยงการอ้างถึงผู้ใช้ด้วยคำว่า "ฉัน" หรือ "ผม/ดิฉัน" เพราะอาจทำให้เกิดความสับสนได้
ใช้ตัวพิมพ์ใหญ่เฉพาะอักษรตัวแรกของคำในชื่อและป้ายกำกับ ไม่ใช่ตัวพิมพ์ใหญ่เฉพาะอักษรตัวแรกของคำสำคัญ
เช่น "รายการเคลื่อนไหวของบัญชี" ไม่ใช่ "รายการเคลื่อนไหวของบัญชี"
ใช้คำย่อ ซึ่งเหมาะสมแม้แต่กับตัวแทนที่มีน้ำเสียงจริงจังหรือเป็นทางการ
เช่น "it's" เป็นกันเองมากกว่า "it is"
ใช้เครื่องหมายอัศเจรีย์เท่าที่จำเป็น
ใช้คอมมาอนุกรม เช่น "A, B และ C" ไม่ใช่ "A, B และ C"
เขียนตัวเลขเป็นตัวเลข
เช่น "1, 2, 3" ไม่ใช่ "หนึ่ง สอง สาม"
เมื่อใช้อิโมจิ ให้ตรวจสอบว่าน้ำเสียงขี้เล่นเหมาะกับกรณีการใช้งาน
เช่น ผู้ใช้ที่จองรถลากหรือดูผลการตรวจสุขภาพอาจไม่รู้สึกสนุก
เก็บข้อความไว้ตามลำดับ
หากคุณส่งข้อความหลายข้อความตามลำดับ ผู้ใช้ต้องได้รับข้อความเหล่านั้นตามลำดับ ข้อความที่มีสื่อจะใช้เวลาประมวลผลนานกว่าข้อความที่เป็นข้อความอย่างเดียว หากต้องการให้ผู้ใช้ได้รับข้อความตามลำดับที่ถูกต้อง ให้รอจนกว่าคุณจะได้รับการตอบกลับ 200 OK สำหรับข้อความหนึ่งก่อนที่จะส่งข้อความถัดไปในลำดับ
สร้างการสนทนาที่น่าสนใจด้วยคำตอบและการดำเนินการที่แนะนำ
คำตอบที่แนะนำ และ การดำเนินการ เป็นเครื่องมือที่มีประสิทธิภาพในการแนะนำและปรับปรุงการสนทนาของผู้ใช้ คำตอบและการดำเนินการที่แนะนำสามารถแสดงหลังข้อความหรือการ์ดริชมีเดีย และเสนอตัวเลือกในการสนทนาต่อหรือเปลี่ยนหัวข้อการสนทนา
คำตอบที่แนะนำ: ช่วยให้ผู้ใช้ตอบกลับตัวแทนได้อย่างรวดเร็วโดยแสดง ตัวเลือกที่กำหนดไว้ล่วงหน้า ใช้คำตอบที่แนะนำทุกครั้งที่ทำได้ โดยเฉพาะอย่างยิ่งเมื่อคาดหวังการตอบกลับที่เฉพาะเจาะจง
การดำเนินการที่แนะนำ: อนุญาตให้ตัวแทนผสานรวมกับฟีเจอร์ของอุปกรณ์ ซึ่งจะช่วยให้งานต่างๆ ง่ายขึ้น เช่น การโทรหาทีมสนับสนุนหรือการค้นหาสถานที่
คำนึงถึงข้อควรพิจารณาที่สำคัญต่อไปนี้เพื่อสร้างการสนทนาที่มีประสิทธิภาพและน่าสนใจยิ่งขึ้น
- ความเกี่ยวข้อง: ตรวจสอบว่าคำแนะนำสอดคล้องกับการสนทนาปัจจุบัน
- ความกระชับ: จำกัดจำนวนคำแนะนำเพื่อไม่ให้ผู้ใช้รู้สึกว่ามีตัวเลือกมากเกินไป
- ความชัดเจน: ใช้ภาษาที่ชัดเจนและกระชับสำหรับข้อความคำแนะนำ
ช่วยเหลือผู้ใช้
ตัวแทนควรตอบกลับข้อความ HELP จากผู้ใช้และให้ข้อมูลเกี่ยวกับความสามารถของตัวแทน รายการคำตอบที่แนะนำซึ่งปรับให้เหมาะกับความสามารถของตัวแทนสามารถเปลี่ยนประสบการณ์ของผู้ใช้ที่ไม่ดีให้กลายเป็นประสบการณ์ที่เป็นประโยชน์ได้
ตรวจสอบว่าโลโก้และรูปภาพหลักแสดงผลได้ดี
- เว้นพื้นที่รอบโลโก้ให้เพียงพอเพื่อรองรับการครอบตัดและรักษาความสมบูรณ์ของภาพ
- หลีกเลี่ยงการยืดหรือบิดเบือนโลโก้หรือรูปภาพหลัก เพราะอาจส่งผลเสียต่อการรับรู้แบรนด์
- ทดสอบโลโก้ และรูปภาพหลักในทั้งโหมดสว่างและโหมดมืดเพื่อให้มองเห็นได้ชัดเจนและ สวยงามที่สุด
ดูแหล่งข้อมูลเพิ่มเติมที่จะช่วยคุณออกแบบโลโก้หรือแก้ปัญหาได้ที่ หลักเกณฑ์การออกแบบโลโก้
โลโก้
- ออกแบบโดยคำนึงถึงการแสดงผลเป็นสี่เหลี่ยมจัตุรัสที่มีมุมโค้งมน โลโก้ RCS สำหรับธุรกิจจะแสดงเป็น "สี่เหลี่ยมจัตุรัสที่มีมุมโค้งมน" ในรายการการสนทนา หน้าจอการสนทนา และรายละเอียดการสนทนาเพื่อให้สอดคล้องกับมาตรฐานของ Google และอุตสาหกรรม
- วางโลโก้ไว้ตรงกลางรูปภาพเพื่อให้องค์ประกอบของแบรนด์ยังคงชัดเจนหลังการครอบตัด
- ตัวแทนที่ได้รับการยืนยันจะมีเครื่องหมายถูกสำหรับการยืนยันปรากฏอยู่ข้างชื่อตัวแทนโดยอัตโนมัติ เครื่องหมายนี้ได้รับการปกป้องจากการแอบอ้างเป็นผู้อื่นและเพิ่มด้วยตนเองไม่ได้
- สำหรับโลโก้ที่มีพื้นหลังโปร่งใส ให้ตรวจสอบว่ามีคอนทราสต์เพียงพอกับทั้งพื้นหลังสีอ่อนและสีเข้มเพื่อรองรับโหมดมืด หากไม่แน่ใจ ให้ใช้พื้นหลังสีขาว
รูปภาพหลัก
- ใช้สัดส่วนภาพ 45:14 เพื่อป้องกันการครอบตัดที่ไม่ต้องการ
พิจารณาการซ้อนทับของโลโก้เมื่อออกแบบรูปภาพหลัก เพื่อไม่ให้องค์ประกอบสำคัญถูกบดบัง
เคารพเมื่อผู้ใช้ไม่ต้องการรับข้อความ
การรักษาความเชื่อมั่นของผู้ใช้หมายถึงการเคารพค่ากำหนดการสื่อสารของผู้ใช้ เมื่อผู้ใช้ระบุว่าต้องการหยุดรับข้อความ ตัวแทนต้องปฏิบัติตามตัวเลือกของผู้ใช้ ซึ่งรวมถึงการทำความเข้าใจและตอบสนองต่อการแสดงเจตจำนงที่จะไม่รับข้อความต่างๆ อย่างเหมาะสม เช่น "STOP" ในทุกภาษาที่เกี่ยวข้อง
โปรดศึกษากฎหมายและแนวทางปฏิบัติแนะนำสำหรับประเทศที่คุณดำเนินการเกี่ยวกับวิธีการตอบกลับข้อความ "STOP" และคำสั่งอื่นๆ ที่ต้องปฏิบัติตาม
เช่น โปรดดูแนวทางปฏิบัติแนะนำของ CTIA
จัดการเหตุการณ์ยกเลิกการสมัครรับข้อมูลและสมัครรับข้อมูล
Google Messages มีฟีเจอร์ยกเลิกการสมัครรับข้อมูล และสมัครรับข้อมูล ในตัว ซึ่งช่วยให้ผู้ใช้ควบคุมการสนทนาได้ เมื่อผู้ใช้เลือกยกเลิกการสมัครรับข้อมูล ตัวแทนจะได้รับเหตุการณ์ Webhook UNSUBSCRIBE เหตุการณ์ SUBSCRIBE แสดงถึงความตั้งใจของผู้ใช้ที่จะกลับมามีส่วนร่วมกับตัวแทน
ดูข้อมูลโดยละเอียดเกี่ยวกับการจัดการ เหตุการณ์ยกเลิกการสมัครรับข้อมูล และ สมัครรับข้อมูลอีกครั้ง รวมถึงรายละเอียดเพย์โหลด กฎธุรกิจ และตัวอย่างได้ใน เอกสารประกอบเกี่ยวกับ เหตุการณ์ที่ผู้ใช้สร้างขึ้น
จัดการการเลือกไม่รับ
แพลตฟอร์ม RCS สำหรับธุรกิจไม่มีวิธีจัดการรายการผู้ใช้ที่เลือกไม่รับโดยตรง คุณมีหน้าที่รับผิดชอบในการดูแลฐานข้อมูลของผู้ใช้ที่เลือกหยุดรับข้อความผ่านการยกเลิกการสมัครรับข้อมูลหรือการเลือกไม่รับรูปแบบอื่นๆ
สนทนาต่อ
หากผู้ใช้ลบการสนทนากับตัวแทน ผู้ใช้ต้องเริ่มการติดต่ออีกครั้งผ่านช่องทางอื่น เช่น การเลือกรับในเว็บไซต์ รหัสสั้น SMS หรือกลไกการขอความยินยอมอื่นๆ การโต้ตอบใหม่นี้แสดงถึงความสนใจที่กลับมาอีกครั้งในการรับข้อความ