IOSOR ज्ञान
DID घटना सप्ताह: मैसेजिंग बंद सक्रिय नहीं है
आउटेज के दौरान अपनी पहली DID मैसेजिंग घटना को कैसे संभालें, दुकान के स्टॉक की कल्पना के बिना प्रीपेड होल्ड का प्रबंधन करें और ईमानदार स्थितियां संचारित करें।
मैसेजिंग बंद होने का अर्थ है रूटिंग विफलता, दुकान का स्टॉक रीस्टॉक नहीं
जब किसी नए प्रावधानित नंबर पर मैसेजिंग विफल हो जाती है, तो आपकी पहली प्रवृत्ति इन्वेंट्री की जांच करना या रीस्टॉक अलर्ट देखना हो सकती है। व्हाइट-लेबल CPaaS संचालन में, कोई गोदाम या भौतिक शेルフ नहीं होता है। नंबर JIT प्रोविजनिंग के माध्यम से इंस्टेंटिएट किए जाते हैं। यदि इनबाउंड एसएमएस या ओटीपी डिलीवरी रुक जाती है, तो समस्या रूटिंग टेबल, वेबहुक डिस्पatchers या अपस्ट्रीम गेटवे हैंडशेक में होती है - 'सोल्ड आउट' बिन में कभी नहीं। प्रत्येक आउटेज को मर्चेंडाइजिंग त्रुटि के बजाय लाइव नेटवर्क अपवाद के रूप में मानें।
असाइनमेंट और भेजने कतारों पर तत्काल फ्रीज
जैसे ही ग्राहक गिराए गए DLR या मूक OTP प्रवाह की रिपोर्ट करते हैं, स्वचालित नंबर असाइनमेंट और उच्च-वॉल्यूम भेजने वाली कतारों को तुरंत फ्रीज कर दें। सक्रिय क्षरण के दौरान स्क्रिप्ट को मार्ग आवंटित करना जारी रखने से ब्लास्ट रेडियस बढ़ जाता है। प्रभावित उप-खातों के लिए प्रीपेड बैलेंस आवंटन पर एक अस्थायी होल्ड लगाएं। स्पष्ट रूप से संवाद करें कि घटना सक्रिय इंजीनियरिंग समीक्षा के अधीन है, समर्थन टीमों द्वारा HB और API पेलोड लॉग को ट्रैक करने के दौरान आपके न्यूनतम USD 20 प्रीपेड फ्लोर को बरकरार रखते हुए।
नेटवर्क को दोष देने से पहले तत्परता का सत्यापन
घटना को बढ़ाने से पहले, सत्यापित करें कि प्रभावित नंबर बेसलाइन प्रोटोकॉल आवश्यकताओं को पूरा करता है। कई कथित आउटेज उत्पादन से पहले DID मैसेजिंग तत्परता गाइड में उल्लिखित छोड़े गए सत्यापन चरणों से उत्पन्न होते हैं। 10DLC पंजीकरण स्थिति, ब्रांड अनुपालन, और वेबहुक URL प्रतिक्रिया की जाँच करें। यदि हेडर 5xx त्रुटियां लौटाते हैं, तो अड़चन वाहक नेटवर्क पर नहीं, बल्कि एप्लिकेशन एंडपॉइंट पर है।
विफल संपत्तियों को अदला-बदલી, रिफंड या रिलीज़ करना
यदि अंतर्निहित रूटिंग पथ स्थायी रूप से खराब हो गया है और SLA सीमाओं के भीतर पुनर्प्राप्त नहीं किया जा सकता है, तो ग्राहक को अधर में न छोड़ें। एक साफ स्वैप निष्पादित करें या स्वचालित क्रेडिट जारी करें। संतुलन समायोजन को सही ढंग से साफ़ करने के लिए DID ऑर्डर विफल रिफंड और स्वैप के लिए प्रोटोकॉल की समीक्षा करें। विफल बुनियादी ढांचा के लिए दो बार भुगतान किए बिना किरायेदार को काम करने वाली संपत्ति प्रदान करने के लिए प्रीपेड होल्ड को तुरंत जारी किया जाना चाहिए।
हनीमून चरण से परे वित्तीय predictability
परिचालन संबंधी घटनाएं अक्सर स्केलिंग मील के पत्थर के साथ मेल खाती हैं। एक बार जब कोई किरायेदार शुरुआती परीक्षणों से आगे निकल जाता है और USD 1,000/माماه के पास नरम समीक्षा के करीब पहुंच जाता है, तो यातायात पैटर्न छिटपुट ओटीपी फटने से निरंतर A2P अभियानों में स्थानांतरित हो जाते हैं। आवर्ती शुल्क और उपयोग टॉप-अप को सक्रिय समस्या निवारण के दौरान झूठी-सकारात्मक धोखाधड़ी निलंबन को ट्रिगर किए बिना साफ-सुथरा मेल खाने के लिए अपने DID दूसरा महीना: UTC कैलेंडर रोल होने पर पूर्ण MRC चक्रों पर कड़ी नजर रखें।
मूल व्हाइट-LABEL विश्वसनीयता के लिए IOSOR से शुरुआत करें
DLR या messaging webhook मर जाए तो उस DID पर भेज कतार जमा दें। पंक्ति अभी assigned है इसलिए MT न चलाएँ। जमा समय, अंतिम अच्छा DLR और messaging-down स्थिति निर्यात करें। उन्हीं अंकों पर जीवित smoke के बाद ही फिर चलाएँ। यह दुकान अनुपलब्ध बैज नहीं, चालान विवाद भी नहीं।
IOSOR सार
messaging-down जमाव है, सूची टूटन नहीं।
करें: कतारें रोकें और किरायेदारों को कहें संदेश गिरा है। न करें: भेजते रहना, या DID को गायब स्टॉक कहना।
क्या यह गाइड मददगार थी?
संबंधित गाइड
- सेकंड-ओनर DID हैंडओवर: कौन असाइन और रिलीज़ कर सकता है
सेकंड-ओनर DID हैंडओवर के दौरान ऑपरेशनल सीमाएं, JIT प्रोविजनिंग और प्रीपेड वित्तीय सीमाओं में महारत हासिल करें।
- प्रति DID व्यय सीमा: एक नंबर पर किराया और आउटबाउंड ट्रैफ़िक
स्थिर लागत और आउटबाउंड ट्रैफ़िक के लिए संयुक्त व्यय सीमा के साथ अपने व्हाइट-लेबल CPaaS में जोखिम को नियंत्रित करें।
- DID पर इनबाउंड वेबहुक रूटिंग: बिना ओनर के MO से STOP खो जाता है
इनबाउंड वेबहुक को ओनिंग अकाउंट पर सुरक्षित रूप से रूट करें। व्हाइट-लेबल प्रीपेड CPaaS में अनाथ MO इवेंट्स और छूटे हुए ऑप्ट-आउट्स को रोकें।