ข้อกำหนดสิทธิ์ TCPA และ CASL ก่อนเริ่มส่งข้อความ Production

ข้อกำหนดสิทธิ์ TCPA และ CASL ก่อนเริ่มส่งข้อความ Production.

หลักฐานความยินยอมเป็นเงื่อนไขเด็ดขาดก่อนขึ้นระบบจริง

การปฏิบัติต่อการตรวจสอบการยินยอม (Opt-in) และกลไกการยกเลิก (Opt-out) เป็นเพียงเมตริกการส่งข้อความถือเป็นข้อผิดพลาดทางสถาปัตยกรรมที่ร้ายแรง ภายใต้กฎหมายโทรคมนาคมของอเมริกาเหนือ ความยินยอมไม่ใช่คะแนนการปรับแต่ง แต่เป็นเงื่อนไขบังคับแบบทวิภาคก่อนส่ง การเปิดตัวแคมเปญ SMS โดยไม่มีบันทึกความยินยอมที่ตรวจสอบได้ทางเทคนิคจะทำให้แพลตฟอร์มของคุณเผชิญกับบทลงโทษตามกฎหมาย TCPA ของสหรัฐฯ และ CASL ของแคนาดา

ความแตกต่างทางกฎหมาย: ความยินยอมเป็นลายลักษณ์อักษรของ TCPA กับ CASL

TCPA กำหนดให้ต้องมีความยินยอมเป็นลายลักษณ์อักษรอย่างชัดเจนล่วงหน้าสำหรับการรับ SMS ส่งเสริมการขายแบบอัตโนมัติทั้งหมด โดยต้องมีข้อตกลงที่ชัดเจนระบุหมายเลขปลายทาง ส่วน CASL แบ่งความยินยอมออกเป็นแบบชัดแจ้ง (ไม่มีวันหมดอายุจนกว่าจะถูกเพิกถอน) และความยินยอมโดยนัยจากความสัมพันธ์ทางธุรกิจที่มีอยู่ (EBR) ซึ่งจะหมดอายุภายในระยะเวลา 6 เดือนหรือ 24 เดือนตามเกณฑ์ที่เข้มงวด

การประมวลผลคำสั่ง STOP ขาเข้าในระดับแพลตฟอร์มและการส่ง Webhook

การปฏิบัติตามคำขอยกเลิกต้องได้รับการบังคับใช้ที่ระดับแพลตฟอร์มหลัก แทนที่จะปล่อยให้เป็นหน้าที่ของระบบลูกค้า เมื่อมี SMS ขาเข้าที่มีคำสำคัญมาตรฐาน เช่น STOP, UNSUBSCRIBE, CANCEL, QUIT หรือ ARRET เข้ามายังเส้นทาง E.164 แพลตฟอร์มหลักจะทำเครื่องหมายผู้รับในบัญชีระงับทันที IOSOR จะส่งข้อความยืนยัน 'Verify OK' กลับไปยังผู้ใช้บริการโดยอัตโนมัติ พร้อมทั้งส่ง Webhook แบบเรียลไทม์ไปยัง Endpoint การทำงานของคุณ

การแยกผู้เช่าและการควบคุมบัญชีแยกประเภทในระดับสเกล

การป้องกันไม่ให้สถานะการระงับรั่วไหลข้ามผู้เช่าพร้อมกับรักษาการปฏิบัติตามกฎเกณฑ์ของผู้ให้บริการเครือข่าย จำเป็นต้องมีการแยกสถาปัตยกรรมแบบ Multi-tenant อย่างเข้มงวด ตาราง Opt-out จะถูกแบ่งตาม Tenant ID เพื่อให้แน่ใจว่าคำสั่ง STOP ของลูกค้ารายหนึ่งจะไม่กระทบต่อทราฟฟิก OTP ธุรกรรมของลูกค้ารายอื่น การจัดสรรหมายเลขทั้งหมดเป็นไปตามโมเดล JIT โดยเปิดใช้งานผ่านระบบสำรองและหักยอดบัญชี MRC โดยตรง

สถาปัตยกรรมการตรวจสอบก่อนใช้งานจริงและการเชื่อมโยงการปฏิบัติตามกฎระเบียบ

ก่อนที่จะย้ายทราฟฟิกจาก Staging ไปยัง Production ทีมตรวจสอบต้องทำการทดสอบระบบ Opt-out บนหมายเลขเสมือนทั้งหมด ยืนยันว่า Webhook คำสั่ง STOP สามารถอัปเดตระบบ CRM ได้ภายใน 500 มิลลิวินาที และรายงาน DLR แสดงสถานะหมายเลขที่ถูกระงับอย่างถูกต้อง

บทความที่เกี่ยวข้อง: STOP หลังเข้าคิวส่ง: ข้ามข้อความ อย่าแกล้งทำเป็นส่งสำเร็จ · นโยบาย STOP และ HELP ไม่ใช่การกำหนดเส้นทางกล่องข้อความขาเข้า · การกันยอดเติมเงินก่อนการหักครั้งแรก.

เริ่มต้นกับ IOSOR

ไปที่คอนโซล IOSOR เพื่อตั้งค่าเว็บฮุกคีย์เวิร์ดขาเข้า และบังคับใช้การตรวจสอบบัญชีแยกประเภทความยินยอมก่อนเริ่มส่งข้อความจริง ดำเนินการทดสอบแบบดรายรันด้วยการส่งคีย์เวิร์ด STOP, CANCEL และ ARRET ขาเข้า เพื่อยืนยันว่าการอัปเดตการระงับบนเส้นทาง E.164 ที่กำหนดนั้นใช้เวลาต่ำกว่า 500 มิลลิวินาที ล็อคประตูการผลิตไว้จนกว่าการทดสอบความสอดคล้องจะยืนยันว่าไม่มีการรั่วไหลไปยังปลายทางในทุกผู้เช่าเป้าหมาย

สรุป IOSOR

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

ควรแยกบัญชีแยกประเภทการปฏิเสธรับของผู้เช่า พร้อมทั้งบังคับใช้การประมวลผลคีย์เวิร์ดระดับฮาร์ดแวร์ที่ขอบของแพลตฟอร์ม อย่าพึ่งพาการดึงข้อมูลฐานข้อมูลแบบอะซิงโครนัสหรือ cron job ระดับแอปพลิเคชันเพื่อประมวลผลสัญญาณยกเลิกการสมัครสมาชิกขาเข้าหลังจากที่การจราจรแบบใช้งานจริงเริ่มต้นขึ้นแล้ว