IOSOR ज्ञान
भाड्याच्या DID वर STOP आणि HELP: सपोर्ट ज्याचे रक्षण करू शकेल अशी धोरणे
B2B संघ भाड्याच्या क्रमांकांवर STOP/HELP कीवर्ड धोरण कसे लिहितात — मालकी, शब्दशिल्प, ऑडिट लॉग आणि prepaid प्रामाणिकपणा थर्ड-पार्टी पोर्टलच्या सवयीशिवाय.
भाड्याच्या DID वर STOP आणि HELP कीवर्ड हाताळणे हे केवळ ऑटोरेस्पॉन्डर नसून कठोर कायदेशीर अनुपालन धोरण आहे, ज्याचे रक्षण सपोर्ट टीमने कोणत्याही गोंधळाशिवाय केले पाहिजे. या नियमांचे पालन न केल्यास द्विमार्गी मेसेजिंगमध्ये गंभीर तांत्रिक अडचणी निर्माण होतात. IOSOR इनबाउंड मेसेजिंगला थेट आउटबाउंडसारख्याच white-label prepaid प्लॅटफॉर्मवर सुरक्षित ठेवून थर्ड-पार्टी पोर्टलवरील अवलंबित्व पूर्णपणे काढून टाकते.
कीवर्ड हे धोरण आहेत, बॉटचे साइड-क्वेस्ट नाही
प्रॉडक्ट, कायदा आणि सपोर्टने पहिल्या conversational पाठवण्यापूर्वी एका पानावर स्वाक्षरी करावी:
सपोर्ट मोठ्याने वाचू शकेल अशी STOP भाषा लिहा
STOP उत्तरे लहान, ब्रँडकेंद्रित आणि अस्पष्ट नसावीत:
- या कार्यक्रम / ओळखीवर opt-out लागू झाले हे पुष्टी करा
- काय थांबते ते सांगा (अलर्ट, मार्केटिंग वर्ग, हा DID थ्रेड)
- ग्राहकाला अजून मदत हवी असल्यास मानवी मार्ग दाखवा
- तांत्रिक ID किंवा तृतीय-पक्ष ब्रँड नावे टाकू नका
लॉग: कोणी STOP पाठवला, कोणता DID, कधी सन्मानित, कोणते outbound वर्ग ब्लॉक. सपोर्ट एस्केलेशन तो लॉग तुमच्या प्लॅटफॉर्मवरून ओढावा — स्क्रीनशॉट शिकार नाही.
खऱ्या तासांशी जुळणारे HELP
HELP म्हणजे ब्रँड जास्त वचन देण्याची जागा.
- खरे सपोर्ट तास आणि टाइमझोन
- तुम्ही खरोखर कर्मचारी ठेवता ते चॅनेल (ईमेल, चॅट, कॉलबॅक) — कल्पना नाही
- ग्राहकाने काय समाविष्ट करावे (क्रमांकाचे शेवटचे ४, ऑर्डर id)
- कोणी ऑनलाइन नसल्यास पुढील पाऊल
मृत ईमेलने HELP ला उत्तर देणारा भाड्याचा DID वापरकर्त्यांना सोशलवर अधिक मोठ्याने तक्रार करायला शिकवतो — उशीरा OTP पेक्षा वेगाने विश्वास जाळतो.
मालकी आणि ऑडिट ट्रेल
प्राथमिक owner आणि बॅकअप नाव द्या. प्रॉडक्शनमध्ये STOP अयशस्वी झाले तर ते अनुपालन घटना आहे, «बॉट ट्वीक» तिकीट नाही.
मागा:
- तुमचा स्टॅक पडताळू शकेल असा MO webhook किंवा इनबॉक्स इव्हेंट
- Idempotent हाताळणी (retries होतात)
- सहसंबंध: इनबाउंड कीवर्ड → ग्राहक id → suppression स्थिती
- PII असू शकणाऱ्या कीवर्ड बॉडींसाठी retention नियम
White-label म्हणजे एजंट एका व्यावसायिक पृष्ठभागावर राहतात. «दुसरे पोर्टल तपासा» ऑपरेटिंग मॉडेल नाही.
एका ओळखीखाली receive + send DID जोडा
receive आणि send असंबंधित SKU बनले तर STOP/HELP कोसळतात.
- भाड्याचा DID MO घेऊ शकतो आणि नियम परवानगी देतात तिथे पाठवूही शकतो
- खरेदीनंतर assignment तुमच्या खात्यावर — इतरत्र क्लिक होईपर्यंत तरंगत नाही
- Webhook गंतव्ये त्या प्लॅटफॉर्मशी जुळतात जे तुम्ही आधीच outbound साठी वापरता
IOSOR चा क्रमांक मार्ग prepaid आणि just-in-time आहे: शोध, hold, खरेदी, असाइन. कीवर्ड तयारी त्या असाइनमेंट कथेचा भाग आहे.
IOSOR ने सुरुवात करा
संबंधित: इनबाउंड ऑटो-रिप्लाय लूप IOSOR मध्ये वाहक विलंबनाविरुद्ध इनबाउंड वेबहूक बफर कॉन्फिगरेशन पहिल्या डेबिटपूर्वी प्रीपेड रक्कम राखीव ठेवणे.
IOSOR सारांश
STOP आणि HELP भाड्याच्या DID वर बोलली धोरण आहे, अनेक भाडेकरू ऑप्ट-आउट समकाल नाही.
करा: सहाय्य वाचेल असा मजकूर लिहा आणि लेखा ओळ सिद्ध करा. करू नका: शब्द बॉटची बाजूची कामगिरी मानणे किंवा येथे दुसऱ्या भाडेकरूची यादी जुळवणे.
हा मार्गदर्शक उपयुक्त होता का?
संबंधित मार्गदर्शक
- इनबाउंड व्हॉइस मिस कॉलसाठी एसएमएस फॉलबॅक कॉन्फिगरेशन
व्हॉइस मार्ग अपयशी ठरल्यास लीड्स तात्काळ कॅप्चर करण्यासाठी तुमच्या व्हाईट-लेबल टेलिकॉम प्लॅटफॉर्मवर स्वयंचलित मिस कॉल मजकूर फॉलो-अप सेट करा.
- IOSOR मध्ये वाहक विलंबनाविरुद्ध इनबाउंड वेबहूक बफर कॉन्फिगरेशन
उच्च-व्हॉल्यूम वाहक वितरण विलंबादरम्यान डाउनस्ट्रीम अनुप्रयोग वेळेसमाप्ती रोखण्यासाठी IOSOR white-label CPaaS रांग बफर कॉन्फिगर करा.
- मल्टी-टेनंट आयसोलेशनमध्ये येणाऱ्या ऑप्ट-आउट कीवर्ड्सचे सिंकक्रोनायझेशन
IOSOR मध्ये मल्ट-टेनंट ऑप्ट-आउट सिंकक्रोनायझेशन मास्टर करा. सब-अकाउंट्स वेगळे करताना येणारे स्टॉप कीवर्ड्स जागतिक सप्रेशन कसे व्यवस्थापित करतात ते शिका.