หน้านี้มีแนวทางปฏิบัติแนะนำสำหรับการสร้างประสบการณ์การใช้งาน RCS for Business ที่มีประสิทธิภาพและน่าสนใจ ซึ่งครอบคลุมทั้งการติดตั้งใช้งานทางเทคนิคและการออกแบบเชิงสนทนา
หลักเกณฑ์ทางเทคนิค
ตรวจสอบความสามารถของอุปกรณ์
ก่อนเริ่มการสนทนากับผู้ใช้ ให้ตรวจสอบว่าอุปกรณ์ของผู้ใช้รับข้อความ RCS ได้ หากต้องการระบุความสามารถของผู้ใช้ ให้ส่งการตรวจสอบความสามารถ และปรับการโต้ตอบของเอเจนต์ตามนั้น โต้ตอบกับผู้ใช้ในวิธีที่อุปกรณ์ของผู้ใช้รองรับเท่านั้น หากอุปกรณ์ของผู้ใช้ไม่ได้เปิดใช้ RCS ให้ตั้งค่า วิธีการสื่อสารสำรองกับช่องทางอื่น เช่น SMS
เคารพขนาดข้อความสูงสุด
มีการจำกัดขนาดสูงสุดของข้อความ RCS สำหรับธุรกิจและไฟล์สื่อที่ข้อความนั้นมีได้ ดูรายละเอียดได้ที่ ขนาดข้อความสูงสุด
ป้องกันการส่งข้อความที่ซ้ำกัน
หากต้องการหลีกเลี่ยงการส่งข้อความซ้ำให้ผู้ใช้ ระบบของคุณต้องยืนยันก่อนว่า ข้อความไม่ได้นำส่งก่อนที่จะพยายามเปลี่ยนไปใช้ SMS
ทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อปรับปรุงความน่าเชื่อถือของระบบและป้องกัน ข้อความที่ซ้ำกัน
- ตั้งค่าอายุการใช้งานของ Connection Pool ให้ตรงกับ Time to Live (TTL) ของ DNS: ใช้ Connection Pool และ Client Object Pool เพื่อนำการเชื่อมต่อและออบเจ็กต์ไคลเอ็นต์ที่มีอยู่กลับมาใช้ซ้ำ หากต้องการหลีกเลี่ยงการใช้ที่อยู่ IP ที่ล้าสมัยหลังจากอัปเดต DNS ให้ตั้งค่าเวลาสูงสุดที่การเชื่อมต่อหรือออบเจ็กต์จะยังคงอยู่ในพูลให้ตรงกับเวลา DNS ของ API ที่จะใช้งาน
- อย่าคิดว่าการเชื่อมต่อหมดเวลาหมายถึงความล้มเหลว: อย่าคิดว่าการเชื่อมต่อหมดเวลาหมายความว่าระบบไม่ได้ส่งข้อความ RCS สำหรับธุรกิจ ข้อความอาจ ยังคงประมวลผลในฝั่งเซิร์ฟเวอร์
- ตรวจสอบใบตอบรับการนำส่ง: ตรวจสอบใบตอบรับการนำส่งทุกครั้งก่อน เรียกใช้ข้อความสำรอง
- ตั้งค่า TTL ให้ตรงกับระยะหมดเวลาของการเชื่อมต่อ: ตั้งค่า TTL ของข้อความให้ตรงกับระยะหมดเวลาของการเชื่อมต่อทุกครั้งที่ทำได้
- เพิกถอนข้อความก่อนเปลี่ยนไปใช้ SMS: พยายามเพิกถอนข้อความต้นฉบับก่อนส่ง 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 หรือ 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 และข้อผิดพลาดอื่นๆ หากต้องการกู้คืนจากการเรียก API ที่ล้มเหลวอย่างราบรื่น ให้ใช้การลองใหม่ด้วย Exponential Backoff
การใช้การลองใหม่ด้วย Exponential Backoff จะทำให้โครงสร้างพื้นฐานทำสิ่งต่อไปนี้โดยอัตโนมัติ
- ระบุการเรียก API ที่ล้มเหลว
- ตั้งค่าระยะเวลารอเริ่มต้นและจำนวนการลองใหม่สูงสุด
- หยุดชั่วคราวตามระยะเวลารอ
- ลองเรียก API อีกครั้ง
ประเมินการตอบกลับของการเรียก API
- หากสำเร็จ ให้ดำเนินการตามขั้นตอนถัดไปในเวิร์กโฟลว์
- หากไม่สำเร็จ ให้เพิ่มระยะเวลารอและกลับไปที่ขั้นตอนที่ 3
- หากล้มเหลวหลังจากลองใหม่ครบจำนวนครั้งสูงสุด ระบบจะเข้าสู่สถานะล้มเหลว
ระยะเวลารอที่เหมาะสมและจำนวนการลองใหม่สูงสุดที่เหมาะสมจะแตกต่างกันไปตามกรณีการใช้งาน กำหนดตัวเลขเหล่านี้ตามข้อกำหนดด้านเวลาในการตอบสนองของโครงสร้างพื้นฐานและเวิร์กโฟลว์
เพิ่มประสิทธิภาพ API ด้วยปลายทางระดับภูมิภาค
วิธีเพิ่มประสิทธิภาพ API เพื่อลดเวลาในการตอบสนอง
ใช้ปลายทางที่ใกล้กับภูมิภาคของผู้ใช้มากที่สุด
ตารางต่อไปนี้แสดงคำแนะนำเกี่ยวกับปลายทาง RBM ระดับภูมิภาค ที่จะใช้โดยขึ้นอยู่กับหมายเลขโทรศัพท์ของผู้ใช้
คำนำหน้าหมายเลขโทรศัพท์ ปลายทางที่แนะนำ ภูมิภาค +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 อเมริกา พิจารณาตั้งเซิร์ฟเวอร์ใกล้กับปลายทางที่เลือก
ดูศูนย์ข้อมูลของ Google ได้ที่ https://www.google.com/about/datacenters/locations/
ดูข้อมูลเพิ่มเติมเกี่ยวกับการระบุภูมิภาคของเอเจนต์ได้ในเอกสารประกอบสร้างเอเจนต์
UI แบบสนทนาและประสบการณ์ของผู้ใช้
UI แบบสนทนา ไม่ใช่ UI ของแอป
ตัวแทน RCS สำหรับธุรกิจเหมาะอย่างยิ่งสำหรับการมอบหมายงานที่มีประสิทธิภาพและเฉพาะเจาะจง ให้แก่ผู้ใช้ในอินเทอร์เฟซผู้ใช้แบบสนทนา เอเจนต์ที่ออกแบบมาอย่างดีจะทำให้การโต้ตอบ มุ่งเน้น ชัดเจน และมีโครงสร้างเหมือนการสนทนาที่เป็น ธรรมชาติ
ตัวแทนไม่สามารถพึ่งพา UI ที่มองเห็นได้ของแอปหรือหน้าเว็บ และไม่ควร พยายามเลียนแบบ แต่เอเจนต์ต้องอาศัยการสนทนาที่สร้างขึ้นอย่างพิถีพิถัน ซึ่งตอบสนองความต้องการของผู้ใช้ด้วยการแนะนำผ่านคิวแบบวาจา คำแนะนำ และการจัดการข้อผิดพลาดที่ดี
นอกจากนี้ ตัวแทนไม่ควรเลียนแบบระบบโทรศัพท์อัตโนมัติหรืออินเทอร์เฟซที่ต้องอาศัยการตอบกลับของผู้ใช้ด้วยหมายเลขที่แสดงถึงการดำเนินการที่กำหนด ผู้ใช้ควรสื่อสารกับตัวแทนได้อย่างเป็นธรรมชาติ เหมือนกับที่สื่อสารกับบุคคลอื่นในการสนทนา
เริ่มการสนทนา
การเริ่มต้นการสนทนาจะกำหนดความคาดหวังของผู้ใช้เกี่ยวกับสิ่งที่ตัวแทนทำได้ เริ่มการสนทนาอย่างมีประสิทธิภาพโดยแสดงบุคลิกของตัวแทน ให้ข้อมูลที่ผู้ใช้สนใจเป็นอันดับแรก และแชร์สิ่งที่ตัวแทนทำได้ ให้ตัวเลือกที่ชัดเจนแก่ผู้ใช้ในการโต้ตอบกับเอเจนต์และ สนทนาต่อ
แสดงบุคลิกของเอเจนต์: กำหนดโทนโดยทักทายผู้ใช้และ แนะนำแบรนด์ หากสร้างตัวตนสำหรับเอเจนต์ เช่น ผู้ช่วยเสมือนหรือเจ้าหน้าที่อำนวยความสะดวกดิจิทัล โปรดระบุให้ชัดเจนว่าเป็นแชทบอทและไม่ใช่ บุคคลจริง คุณตั้งชื่อเอเจนต์ให้ตรงกับลักษณะตัวตนได้ อวาตาร์เป็น วิธีที่ยอดเยี่ยมในการเสริมสร้างภาพลักษณ์ของคุณ อาจเป็นโลโก้ของคุณ แต่ตัวการ์ตูน สไตล์กราฟิกก็ใช้ได้ดีเช่นกัน
แชร์สิ่งที่ตัวแทนของคุณทำได้: ข้อความทักทายที่ดีจะช่วยให้ผู้ใช้ทราบว่าการสนทนาจะช่วยอะไรได้บ้าง โดยจะอธิบายความสามารถของเอเจนต์ในระดับสูง นอกจากนี้ยังมีคำตอบที่แนะนำ และการดำเนินการ เพื่อนำผู้ใช้ไปตามเส้นทางที่เฉพาะเจาะจง ใช้คำแนะนำเหล่านี้เพื่อช่วยให้ผู้ใช้ ไปยังส่วนต่างๆ ของการสนทนาและเข้าใจงานที่ Agent ช่วยได้
เขียนข้อความที่ชัดเจนและสอดคล้องกัน
ส่งข้อความที่ผู้ใช้เข้าใจและตอบกลับได้ง่าย สร้าง ข้อความที่กระตุ้นให้ผู้ใช้ตอบกลับ รักษาสไตล์ รูปแบบ และจังหวะให้สอดคล้องกันเพื่อสร้างความน่าเชื่อถือกับผู้ใช้
โปรดคำนึงถึงแนวทางปฏิบัติแนะนำเพิ่มเติมต่อไปนี้เมื่อสร้างข้อความ
อย่าสร้างทางตัน แต่ละข้อความควรนำไปสู่ขั้นตอนถัดไปที่มีความหมาย
- หากเส้นทางของผู้ใช้มีงานที่มีหลายขั้นตอน ให้ใช้เครื่องหมายแสดงความสัมพันธ์ของข้อความ เพื่อแนะนําผู้ใช้ตลอดกระบวนการ
เช่น ตอนนี้… และ… รับทราบ จัดให้เลย…
- ใช้คำที่กระชับเนื่องจาก คำตอบที่แนะนำ และการดำเนินการ มีอักขระได้สูงสุด 25 ตัว
- หากการสนทนามีการส่งต่อ การรับทราบอย่างรวดเร็วจะช่วยให้การเปลี่ยนผ่านเป็นไปอย่างราบรื่น
เช่น "โอเค ผู้จัดการฝ่ายดูแลลูกค้าจะรับช่วงต่อจากตรงนี้"
เช่น "เยี่ยมไปเลย เราคิดว่าเรารู้ว่าคุณกำลังมองหาอะไร" และ ระบุลิงก์ไปยังเว็บไซต์ของคุณ
รับทราบข้อความของผู้ใช้ด้วยคำหรือวลีที่แสดงการรับรู้
เช่น "ยอดเยี่ยมมาก" "ตกลง" "ได้" หรือ "รับทราบ"
กล่าวถึงผู้ใช้โดยตรงโดยใช้ชื่อ (หากทราบ) หรือคำสรรพนาม "คุณ" หลีกเลี่ยงการอ้างอิงถึงผู้ใช้เป็น "ฉัน" หรือ "เรา" เนื่องจากอาจทำให้เกิดความสับสนได้
สำหรับชื่อและป้ายกำกับ ให้ใช้รูปแบบตัวพิมพ์ของประโยค ไม่ใช่รูปแบบตัวพิมพ์ของหัวข้อ
เช่น "Account statement" ไม่ใช่ "Account Statement"
ใช้คำย่อ ซึ่งเหมาะสมแม้แต่สำหรับตัวแทนที่มีน้ำเสียงจริงจังหรือ เป็นทางการ
เช่น "it's" จะดูเป็นบทสนทนามากกว่า "it is"
ใช้เครื่องหมายอัศเจรีย์เท่าที่จำเป็น
ใช้คอมมาอนุกรม เช่น "A, B และ C" ไม่ใช่ "A, B และ C"
เขียนตัวเลขเป็นตัวเลข
เช่น "1, 2, 3" ไม่ใช่ "หนึ่ง สอง สาม"
เมื่อใช้อีโมจิ ให้ตรวจสอบว่าโทนที่ขี้เล่นเหมาะกับกรณีการใช้งาน
เช่น ผู้ใช้ที่จองรถลากหรือค้นหาผลการตรวจสุขภาพอาจไม่มีอารมณ์
เก็บข้อความไว้ตามลำดับ
หากคุณส่งข้อความหลายรายการตามลำดับ สิ่งสำคัญคือผู้ใช้ต้องได้รับข้อความเหล่านั้นตามลำดับ ข้อความที่มีสื่อจะใช้เวลาประมวลผลนานกว่าข้อความที่มีเฉพาะข้อความ โปรดรอจนกว่าจะได้รับคำตอบ 200 OK สำหรับข้อความก่อนที่จะส่งข้อความถัดไปในลำดับ เพื่อให้มั่นใจว่าผู้ใช้จะได้รับข้อความตามลำดับที่ถูกต้อง
สร้างการสนทนาที่น่าสนใจด้วยคำตอบและการดำเนินการที่แนะนำ
คำตอบที่แนะนำ และการดำเนินการ เป็นเครื่องมือที่มีประสิทธิภาพในการแนะนำและปรับปรุงการสนทนาของผู้ใช้ โดยสามารถติดตาม ข้อความหรือริชการ์ด และเสนอตัวเลือกในการสนทนาต่อหรือเปลี่ยนหัวข้อ การสนทนา
คำตอบที่แนะนำ: ช่วยให้ผู้ใช้ตอบกลับตัวแทนได้อย่างรวดเร็วโดยแสดงตัวเลือกที่กำหนดไว้ล่วงหน้า ใช้การตอบกลับที่แนะนำทุกครั้งที่เป็นไปได้ โดยเฉพาะ เมื่อคาดหวังการตอบกลับที่เฉพาะเจาะจง
การดำเนินการที่แนะนำ: อนุญาตให้เอเจนต์ผสานรวมกับฟีเจอร์ของอุปกรณ์ เพื่อเพิ่มประสิทธิภาพงานต่างๆ เช่น การโทรหาฝ่ายสนับสนุนหรือการค้นหาสถานที่
โปรดพิจารณาประเด็นสำคัญต่อไปนี้เพื่อสร้างการสนทนาที่มีส่วนร่วมและมีประสิทธิภาพมากขึ้น
- ความเกี่ยวข้อง: ตรวจสอบว่าคำแนะนำสอดคล้องกับการสนทนาปัจจุบัน
- ความกระชับ: จำกัดจำนวนคำแนะนำเพื่อไม่ให้ผู้ใช้รู้สึกว่ามีคำแนะนำมากเกินไป
- ความชัดเจน: ใช้ภาษาที่ชัดเจนและกระชับสำหรับข้อความคำแนะนำ
ช่วยเหลือผู้ใช้
ตัวแทนของคุณควรตอบกลับข้อความ HELP จากผู้ใช้และให้ความรู้แก่ผู้ใช้เกี่ยวกับความสามารถของตัวแทน รายการคำตอบที่แนะนำซึ่งปรับให้เหมาะกับความสามารถของตัวแทน จะเปลี่ยนประสบการณ์ของผู้ใช้ที่แย่ให้กลายเป็นประสบการณ์ที่มีประโยชน์ได้
ตรวจสอบว่าโลโก้และภาพฮีโร่แสดงผลได้ดี
- เว้นพื้นที่รอบโลโก้ให้เพียงพอสำหรับการครอบตัดและรักษาความสมบูรณ์ของภาพ
- หลีกเลี่ยงการยืดหรือบิดเบือนโลโก้หรือรูปภาพฮีโร่ เพราะอาจส่งผลเสียต่อการรับรู้แบรนด์
- ทดสอบโลโก้ และภาพฮีโร่ในทั้งโหมดสว่างและโหมดมืดเพื่อให้มองเห็นได้ชัดเจนที่สุดและ สวยงาม
ดูแหล่งข้อมูลเพิ่มเติมที่จะช่วยคุณออกแบบโลโก้หรือแก้ปัญหาได้ที่หลักเกณฑ์การออกแบบโลโก้
โลโก้
- ออกแบบโลโก้โดยคำนึงถึงการครอบตัดแบบวงกลม เพื่อรักษาความสมดุลและความชัดเจน
- วางโลโก้ไว้ตรงกลางรูปภาพเพื่อหลีกเลี่ยงปัญหาการครอบตัด
- สำหรับโลโก้ที่มีพื้นหลังโปร่งใส โปรดตรวจสอบว่ามีคอนทราสต์เพียงพอ กับทั้งพื้นหลังสีอ่อนและสีเข้มเพื่อให้รองรับดาร์กโหมด หากไม่แน่ใจ ให้ใช้พื้นหลังสีขาวทึบ
ภาพแสดงภาพรวมเนื้อหา
- ใช้สัดส่วนภาพ 45:14 เพื่อป้องกันการครอบตัดที่ไม่ต้องการ
โปรดพิจารณาการทับซ้อนของโลโก้เมื่อออกแบบภาพฮีโร่เพื่อไม่ให้องค์ประกอบสำคัญถูกบดบัง
เคารพเมื่อผู้ใช้ไม่ต้องการรับข้อความ
การรักษาความไว้วางใจของผู้ใช้หมายถึงการเคารพค่ากำหนดการสื่อสารของผู้ใช้ เมื่อผู้ใช้ระบุว่าต้องการหยุดรับข้อความ ตัวแทนของคุณต้อง เคารพตัวเลือกของผู้ใช้ ซึ่งรวมถึงการทำความเข้าใจและตอบสนองต่อการแสดงเจตจำนงในการเลือกไม่รับต่างๆ อย่างเหมาะสม เช่น "STOP" ในภาษาที่เกี่ยวข้องทั้งหมด
โปรดศึกษากฎหมายและแนวทางปฏิบัติแนะนำสำหรับประเทศที่คุณดำเนินการเกี่ยวกับวิธีการตอบกลับข้อความ "หยุด" และคำสั่งอื่นๆ ที่ต้องปฏิบัติตาม
เช่น ดูแนวทางปฏิบัติแนะนำของ CTIA
จัดการเหตุการณ์การยกเลิกการสมัครรับอีเมลและการสมัครรับอีเมล
Google Messages มีฟีเจอร์ยกเลิกการติดตามและติดตามในตัว
ซึ่งช่วยให้ผู้ใช้ควบคุมการสนทนาได้ เมื่อผู้ใช้เลือกที่จะ
ยกเลิกการสมัครรับอีเมล ตัวแทนของคุณจะได้รับUNSUBSCRIBEเหตุการณ์ Webhook SUBSCRIBE เหตุการณ์แสดงถึงความตั้งใจของผู้ใช้ที่จะกลับมามีส่วนร่วมกับตัวแทนของคุณ
ดูข้อมูลโดยละเอียดเกี่ยวกับการจัดการเหตุการณ์ ยกเลิกการติดตาม และติดตามอีกครั้ง รวมถึงรายละเอียดเพย์โหลด กฎทางธุรกิจ และตัวอย่างได้ที่ เอกสารประกอบเกี่ยวกับ เหตุการณ์ที่ผู้ใช้สร้างขึ้น
จัดการการเลือกไม่ใช้
แพลตฟอร์ม RCS สำหรับธุรกิจไม่มีวิธีจัดการรายการเลือกไม่รับของผู้ใช้โดยตรง คุณมีหน้าที่รับผิดชอบในการดูแลฐานข้อมูลผู้ใช้ของคุณเอง ที่เลือกหยุดรับข้อความผ่านการยกเลิกการติดตามหรือรูปแบบอื่นๆ ของการเลือกไม่รับ
สนทนาต่อ
หากผู้ใช้ลบการสนทนากับตัวแทนของคุณ ผู้ใช้จะต้องเริ่มการติดต่ออีกครั้งผ่านช่องทางอื่น เช่น การเลือกใช้เว็บไซต์ รหัสย่อ SMS หรือกลไกความยินยอมอื่นๆ การโต้ตอบใหม่นี้แสดงให้เห็นว่าผู้ใช้มีความสนใจที่จะรับข้อความอีกครั้ง