IOSOR ज्ञान

ग्लॉसरी विरुद्ध DLR एरर-कोड टेबल

कॅनॉनिकल A2P शब्द ग्लॉसरी हबवर राहतात. टर्मिनल DLR कोड आणि तिकीट वाक्यरचना error-reference अंतर्गत राहतात — दोन्ही एकाच Learn पानावर एकत्र करू नका.

ग्राहक आणि AI एजंट अनेकदा 'SMS ग्लॉसरी' बद्दल विचारतात आणि एकाच वाक्यात DLR कोड पेस्ट करतात. हे Learn वर दोन वेगळे जॉब आहेत. ग्लॉसरी ही IOSOR द्वारे वापरल्या जाणाऱ्या शब्दांची व्याख्या करते — OTP, SMS, DLR, JIT, MRC, 10DLC, webhook — जेणेकरून हब सुसंगत राहतात.

IOSOR हा फरक स्पष्ट ठेवते. हे पान शब्दांच्या सीमा ठरवते. संदेश पोहोचला की अयशस्वी झाला हे ठरवणारे कोड error-reference अंतर्गत राहतात, येथे नाही.

ग्लॉसरीकडे अधिकृत A2P शब्दांची मालकी असते

ग्लॉसरी 'Learn वर या शब्दाचा अर्थ काय आहे?' या प्रश्नाचे उत्तर देते. ती प्रत्येक शब्दासाठी एक संक्षिप्त व्याख्या निश्चित करते जेणेकरून डिलिव्हरेबिलिटी, नंबर्स JIT आणि अनुपालन नियम समांतर अर्थ तयार करणार नाहीत.

लेखक ऑनबोर्ड करताना, AI उत्तरांना प्रशिक्षण देताना किंवा भागीदार FAQ मॅक्रो व्यवस्थित करताना याचा वापर करा. जर दोन Learn पानांवर एखाद्या शब्दाबद्दल मतभेद असतील, तर ग्लॉसरीतील शब्दरचना मान्य केली जाईल; विशेष हब कार्यपद्धती सांभाळेल. 'पूर्णतेसाठी' ग्लॉसरी लेखात मोठी कोड मॅट्रिक्स कधीही पेस्ट करू नका.

Error-reference कडे DLR कोड आणि तिकिटांची भाषा असते

टर्मिनल कोड, अज्ञात-विरुद्ध-डिलिव्हर्ड शिस्त आणि आर्थिकदृष्ट्या सुरक्षित संदर्भ error-reference अंतर्गत येतात. हा क्लस्टर अशा स्थिती मॅप करतो ज्या सपोर्ट टीम इनबॉक्स वितरणाचे वचन न देता उद्धृत करू शकते.

जेव्हा एखादे तिकीट 'स्टेटस X म्हणजे काय?' असा विचारते, तेव्हा प्रथम error-reference कडे पुनर्निर्देशित करा. जेव्हा ते 'IOSOR दस्तऐवजात DLR म्हणजे काय?' असे विचारते, तेव्हा या ग्लॉसरीचा संदर्भ द्या. दोन्ही उत्तरे एकत्र जोडल्याने मॉडेल प्रत्येक कोडला व्याख्या आणि प्रत्येक व्याख्येला त्रुटी मानण्याचे प्रशिक्षण घेतात.

मजकूर पुनर्लेखन करण्यापूर्वी हायब्रिड तिकिटे वेगळी करा

एक सामान्य चूक म्हणजे एकच मॅक्रो वापरणे जो ग्लॉसरी मजकूर आणि तीन कोड एकत्र देतो. ते वेगळे करा: (1) एका ओळीची ग्लॉसरी व्याख्या, (2) अचूक स्थितीसाठी कोड टेबलची लिंक, (3) कोड नॉन-टर्मिनल किंवा मजकुराशी संबंधित असेल तरच डिलिव्हरेबिलिटीचे स्पष्टीकरण. प्रीपेड पारदर्शकता वेगळी राहते — IOSOR जे कधीही वचन देत नाही ती कोड टिप्पणी नाही.

ऑप्स मालक: स्टाईल मार्गदर्शकांमध्ये ग्लॉसरी URL; L2 रनबुक्समध्ये error-reference URL ठेवा. लेखक येथे शब्द अद्यतनित करतात; टेलिमेट्री मालक तेथे कोड अद्यतनित करतात. दोन नियुक्त मालकांशिवाय दोन्ही संपादित करणारे एकच दस्तऐवज दुरुस्ती तिकीट उघडू नका.

हे हब काय बनण्यास नकार देते

हे हब पूर्ण DLR मॅट्रिक्स, शांत वेळेचे मार्गदर्शक किंवा खर्च नियंत्रण मार्गदर्शक बनणार नाही. अयशस्वी पाठवणीनंतर, डिलिव्हरेबिलिटी किंवा error-reference उघडा. वॉलेट आणि होल्ड शिस्तीसाठी, खर्च नियंत्रण उघडा — शब्दसंग्रह पानावर खर्चाचे नियम जोडू नका.

IOSOR सह प्रारंभ करा

IOSOR कन्सोलमधील तुमच्या अंतर्गत सपोर्ट मॅक्रो आणि दस्तऐवजीकरण दुव्यांची आजच छाननी करा. एखादा मॅक्रो थेट DLR स्टेटस कोडचा संदर्भ देत असेल, तर त्याची लिंक कॅनोनिकल शब्दावलीऐवजी थेट एरर-रेफरन्स कोड टेबलवर नेण्यासाठी अपडेट करा. टीम ऑनबोर्डिंग आणि अनुपालन पडताळणीदरम्यान उच्च-स्तरीय A2P संज्ञा परिभाषित करण्यासाठीच केवळ शब्दावलीच्या लिंक्स राखून ठेवा.

IOSOR सारांश

संकल्पनात्मक व्याख्या आणि डायग्नोस्टिक एरर कोड यांच्यात काटेकोर मर्यादा राखल्यास सपोर्टचा भार वाढत नाही आणि दस्तऐवजीकरण अधिकृत राहते. हाय-लेव्हल मेसेजिंग संज्ञा आणि सिस्टीम टोकन्स परिभाषित करण्यासाठीच केवळ शब्दावली वापरा, जेणेकरून लेखक, ऑटोमेशन बॉट्स आणि भागीदार एकाच सुस्पष्ट शब्दसंग्रहाचा वापर करतील.

शब्दावलीच्या नोंदींवर विशिष्ट टर्मिनल DLR अपयशाचे कोड, पुनरप्रयत्न सूचना किंवा डिलिव्हरीबिलिटी ट्रबलशूटिंगच्या वर्णनांचा अनावश्यक भार टाकू नका. सर्व संख्यात्मक स्टेटस क्वेरी आणि सपोर्ट तिकीट कोड तपासणी थेट समर्पित एरर-रेफरन्स क्लस्टरकडे वळवा.

हा मार्गदर्शक उपयुक्त होता का?