सूचना प्रौद्योगिकी
Twilio की जानकारी: मैसेजिंग, वॉइस API और डिलीवरी वर्कफ़्लो
Twilio संचार उपकरण प्रदान करता है जिसका उपयोग डेवलपर्स संदेश और आवाज अनुभव बनाने के लिए कर सकते हैं। उपयोगी परिणाम केवल यह नहीं है कि एक अनुप्रयोग एक एपीआई अनुरोध कर सकता है। यह है कि सही व्यक्ति को एक समझने योग्य संचार प्राप्त होता है, वह उचित रूप से प्रतिक्रिया दे सकता है और बातचीत पर लागू होने वाली प्राथमिकताओं और अनुमतियों के अनुसार व्यवहार किया जाता है। इसलिए वितरण, सहमति, समर्थन और परिचालन साक्ष्य शुरू से ही परियोजना में शामिल हैं।
यह स्वतंत्र मार्गदर्शिका बताती है कि किसी परीक्षण से सामान्य उपयोग की ओर बढ़ने से पहले Twilio संदेश या ध्वनि परियोजना के बारे में कैसे सोचा जाए। इसमें प्रेषक योजना, संदेश अनुरोध, आने वाले कार्यक्रम, वितरण कॉलबैक, ध्वनि बातचीत और व्यावहारिक समीक्षा शामिल हैं। उदाहरण काल्पनिक हैं और किसी विशेष संगठन के लिए कानूनी या वाणिज्यिक सिफारिश स्थापित नहीं करते हैं। उत्पाद की उपलब्धता, प्रेषक की आवश्यकताएँ, गंतव्य नियम और मूल्य निर्धारण बदल सकते हैं, इसलिए आप जिस चैनल और बाजार का उपयोग करना चाहते हैं, उसके लिए वर्तमान Twilio प्रलेखन की पुष्टि करें।
1. ग्राहक की पूरी प्रक्रिया से शुरुआत करें
परिभाषित करें कि संचार प्राप्तकर्ता को क्या करने में मदद करता है। एक नियुक्ति अनुस्मारक, एक वितरण अद्यतन, एक समर्थन उत्तर और एक प्रचार घोषणा विभिन्न उद्देश्यों को पूरा करती है। प्रत्येक को उचित शब्द, समय और उत्तरों को संभालने की आवश्यकता होती है। एक काल्पनिक मरम्मत व्यवसाय ग्राहक को एक पुष्ट यात्रा के बारे में याद दिलाना चाहेगा। इसका सफल परिणाम यह है कि व्यक्ति नियुक्ति को समझता है और जानता है कि परिवर्तन का अनुरोध कैसे किया जाए, न कि केवल एक एपीआई कॉल सफलतापूर्वक लौटता है।
कार्यान्वयन विवरण चुनने से पहले पूरी यात्रा को तैयार करें। संदेश को क्या प्रेरित करता है, कौन इसे प्राप्त करता है और क्या जानकारी इसमें होती है और जब व्यक्ति जवाब देता है तो क्या होता है, इसे दर्ज करें। यह भी तय करें कि यदि डिलीवरी विफल हो जाती है या नियुक्ति बदल जाती है तो क्या होना चाहिए। यह उन अंतरालों को उजागर करता है जिन्हें आसानी से चूकना आसान होता है जब एक टीम केवल भेजने पर ध्यान केंद्रित करती है। संचार को एक अलग तकनीकी घटना बनने के बजाय एक मौजूदा सेवा प्रक्रिया के अनुरूप होना चाहिए, जो एप्लिकेशन को छोड़ने के बाद किसी के पास नहीं है।
2. बातचीत की जरूरत के अनुसार चैनल चुनें
एक संचार चैनल में ऐसी विशेषताएं होती हैं जो अनुभव को प्रभावित करती हैं। एक संक्षिप्त संदेश एक संक्षिप्त अद्यतन के लिए उपयोगी हो सकता है, जबकि एक आवाज बातचीत एक निर्देशित बातचीत में मदद कर सकती है। समृद्ध संदेश सुविधाएँ चयनित चैनल और इसकी समर्थित क्षमताओं पर निर्भर करती हैं। यह मानने के बजाय कि एक संदेश डिजाइन हर जगह समान रूप से काम करता है, वर्तमान उत्पाद प्रलेखन में उन क्षमताओं की समीक्षा करें। प्राप्तकर्ता का संदर्भ उतना ही महत्वपूर्ण है जितना कि प्रेषक की सुविधा।
एक काल्पनिक नियुक्ति सेवा के लिए, एक स्पष्ट लिखित अनुस्मारक पर फिर से विचार करना एक बोली गई घोषणा की तुलना में आसान हो सकता है। एक अलग स्थिति में एक इनबाउंड वॉयस मेनू की आवश्यकता हो सकती है जो किसी को सही टीम में निर्देशित करता है। पहले इच्छित अंतःक्रिया का वर्णन करें, फिर प्रासंगिक चैनल का मूल्यांकन करें। दूसरा चैनल जोड़ने से केवल इसलिए बचें क्योंकि यह तकनीकी रूप से उपलब्ध है। एक ही घटना के बारे में कई संचार प्राप्तकर्ता को भ्रमित या परेशान कर सकते हैं यदि परियोजना ने यह परिभाषित नहीं किया है कि कौन सा संदेश आधिकारिक है और डुप्लिकेट संपर्क को कैसे रोका जाता है।
3. बड़े कैंपेन से पहले प्रेषक की योजना
प्रेषक प्राप्तकर्ता के विश्वास निर्णय का हिस्सा है। समर्थित प्रेषक विकल्पों और इच्छित गंतव्य और उपयोग मामले के लिए वर्तमान आवश्यकताओं की समीक्षा करें। एक संख्या या प्रेषक पहचान जो एक छोटे से प्रदर्शन में काम करती है, उसे प्रत्येक देश, चैनल या मात्रा के लिए काम करने वाला नहीं माना जाना चाहिए। प्रेषक योजना को परियोजना की अन्य संचालन धारणाओं के साथ रखें, और प्रदाता के वर्तमान मार्गदर्शन के माध्यम से किसी भी पंजीकरण या सत्यापन चरणों की पुष्टि करें।
प्रेषक की पहचान करने और उसे जवाब देने की प्राप्तकर्ता की क्षमता पर विचार करें। संदेश निकाय को संगठन और उद्देश्य को पूरी तरह से उस संख्या पर भरोसा किए बिना स्पष्ट करना चाहिए जिसे कोई नहीं पहचान सकता है। तय करें कि उत्तरों को कौन संभालता है और क्या चैनल उस प्रतिक्रिया पथ का समर्थन करता है जिसका आप वर्णन कर रहे हैं। एक अनुस्मारक जो मदद के लिए जवाब देने के लिए कहता है, अगर कोई उन जवाबों की निगरानी नहीं करता है तो वह अधूरा है। इसलिए प्रेषक का चयन एक तकनीकी विन्यास निर्णय और संचार प्राप्त करने वाले व्यक्ति के साथ संबंध के बारे में एक डिजाइन निर्णय दोनों है।
4. खाते की कुंजियां नियंत्रित सर्वर पर रखें
एपीआई क्रेडेंशियल्स संचार और खर्च को सक्षम कर सकते हैं, इसलिए वे संरक्षित सर्वर विन्यास से संबंधित हैं। ब्राउज़र जावास्क्रिप्ट, एक सार्वजनिक रूप से वितरित मोबाइल एप्लिकेशन या एक साझा उदाहरण फ़ाइल में उत्पादन रहस्य न रखें। यह तय करें कि कौन सा घटक संदेश बना सकता है और यह कैसे सत्यापित करता है कि कार्रवाई एक अधिकृत खाते या सेवा प्रक्रिया से संबंधित है। एक सार्वजनिक अंतिम बिंदु को उचित नियंत्रण के बिना एक मनमाना गंतव्य और निकाय को स्वीकार नहीं करना चाहिए।
सामान्य संचालन से अलग परीक्षण कार्य जहां समर्थित खाता संरचना इसकी अनुमति देती है। प्रेषक विन्यास को कौन बदल सकता है और सामान्य नैदानिक लॉग से गुप्त रख सकता है, इसे सीमित करें। यदि किसी डेवलपर को किसी त्रुटि में मदद की आवश्यकता है, तो क्रेडेंशियल्स और अनावश्यक व्यक्तिगत डेटा को हटाने के बाद प्रासंगिक प्रतिक्रिया और अनुरोध संदर्भ साझा करें। एक संचार अनुप्रयोग बाहर से सरल लग सकता है, लेकिन इसकी सर्वर सीमा निर्धारित करती है कि क्या यह एक नियंत्रित व्यावसायिक उपकरण है या अवांछित संदेशों और अप्रत्याशित लागतों के लिए एक खुला मार्ग है।
5. मैसेज अनुरोध स्वीकार होने का सही अर्थ
एक बहिर्मुखी संदेश बनाना एक जीवन चक्र की शुरुआत है, न कि इस बात का प्रमाण कि किसी व्यक्ति ने इसे प्राप्त किया या समझा। Twilio दस्तावेज़ संदेश संसाधन और स्थिति परिवर्तन जो उस जीवन चक्र में विभिन्न बिंदुओं का वर्णन करते हैं। व्यावसायिक कार्यक्रम के लिए प्रदाता के संदेश पहचानकर्ता और अनुप्रयोग के अपने संदर्भ को सुरक्षित रखें। वे संदर्भ बाद में डिलीवरी अपडेट को नियुक्ति, आदेश या समर्थन मामले के साथ जोड़ने में मदद करते हैं जो संदेश का कारण बना।
मानव-मुख वाले शब्दों को सटीक रखें। एक प्रणाली यह कहने में सक्षम हो सकती है कि डिलीवरी के बारे में कुछ भी कहने से पहले एक अनुरोध स्वीकार कर लिया गया था। इसे केवल इसलिए एक सफल ग्राहक परिणाम प्रदर्शित नहीं करना चाहिए क्योंकि एक सर्वर ने प्रारंभिक प्रतिक्रिया दी है। एक काल्पनिक नियुक्ति कार्यप्रवाह में, रिकॉर्ड पुष्टि की गई बुकिंग, अनुस्मारक का प्रयास और बाद में वितरण साक्ष्य में अंतर कर सकता है। ये संबंधित तथ्य हैं, लेकिन उन्हें एक हरे सफलता बैज में जोड़ना एक समस्या को छिपा सकता है जिसकी अभी भी किसी को जांच करने की आवश्यकता है।
6. आउटबाउंड डिलीवरी के लिए स्टेटस कॉलबैक
Twilio आउटबाउंड संदेश स्थिति में परिवर्तन के लिए स्थिति कॉलबैक का समर्थन करता है। चयनित उत्पाद के प्रलेखन के अनुसार कॉलबैक एंडप्वाइंट को कॉन्फ़िगर करें और संदेश संदर्भ को बनाए रखें। एक कॉलबैक उपयोगकर्ता को तकनीकी स्थिति पृष्ठ की व्याख्या करने के लिए कहे बिना अपने वितरण रिकॉर्ड को अद्यतन करने में मदद कर सकता है। प्रलेखित सत्यापन प्रक्रिया का उपयोग करके आने वाले अनुरोधों को सत्यापित करें और ग्राहक या प्रचालक को दिखाई देने वाली किसी भी चीज़ को बदलने से पहले संदेश को अनुप्रयोग के सहेजे गए रिकॉर्ड के साथ सहसंबद्ध करें।
दोबारा आने वाली या अपेक्षा से अलग क्रम में पहुंचने वाली घटनाओं को सावधानी से संभालें। एक ही कॉलबैक दो बार आए तो उससे ग्राहक को दूसरा संदेश नहीं जाना चाहिए। घटना का प्रमाण सहेजें और अपडेट को इस तरह बनाएं कि उसे दोहराने से गलत असर न हो। तय करें कि चुने हुए संसाधन में कौन से स्टेटस अंतिम हैं और एप्लिकेशन किन बदलावों को स्वीकार करेगा। लक्ष्य ज्ञात घटनाओं का भरोसेमंद इतिहास रखना है, ऐसा आशावादी विवरण बनाना नहीं जिसमें केवल वही दिखे जिसकी टीम को उम्मीद थी। प्रमाण न मिलना और पक्की डिलीवरी विफलता अलग स्थिति रहें।
7. डिलीवरी और कारोबारी परिणाम का अंतर
एक वितरित संदेश यह स्थापित नहीं करता है कि एक प्राप्तकर्ता ने इसे पढ़ा, समझा या वांछित कार्य को पूरा किया। एक पढ़ने वाला संकेतक केवल वहीं उपलब्ध होता है जहां चैनल इसका समर्थन करता है, और यहां तक कि वह सामग्री के साथ सहमति साबित नहीं करता है। वितरण मेट्रिक्स को व्यावसायिक परिणाम से अलग रखें। नियुक्ति अनुस्मारक के लिए, प्रासंगिक अगला तथ्य एक पुष्टि, पुनर्निर्धारण अनुरोध या वास्तविक नियुक्ति प्रक्रिया के माध्यम से दर्ज उपस्थिति हो सकता है।
ऐसे मेट्रिक्स का उपयोग करें जो एक समझदारी भरे निर्णय का समर्थन करते हैं। यदि कई संदेश दिए जाते हैं लेकिन ग्राहक फिर भी पूछते हैं कि उनका क्या मतलब है, तो शब्दों या समय में सुधार की आवश्यकता हो सकती है। यदि वितरण विफलताएँ किसी विशेष इनपुट समस्या के इर्द-गिर्द जमा होती हैं, तो डेटा-प्रविष्टि प्रक्रिया पर ध्यान देने की आवश्यकता हो सकती है। एक एकल प्रेषण-सफलता प्रतिशत दोनों स्थितियों की व्याख्या नहीं कर सकता है। एक उपयोगी डैशबोर्ड तकनीकी घटना को ग्राहक यात्रा के साथ जोड़ता है, जबकि एक प्रणाली-उत्पन्न स्थिति और संदेश प्राप्त करने वाले व्यक्ति द्वारा वास्तविक कार्रवाई के बीच के अंतर को संरक्षित करता है।
8. आने वाले मैसेज की अलग प्रक्रिया
एक आने वाला संदेश वेबहूक एक आउटबाउंड डिलीवरी कॉलबैक से अलग होता है। सेवा द्वारा प्राप्त संदेश के बारे में एक कार्यक्रम होता है; दूसरा एप्लिकेशन भेजे गए संदेश के जीवन चक्र में परिवर्तन की रिपोर्ट करता है। Twilio इन्हें अलग से दस्तावेज़ करता है। आपके एप्लिकेशन को उन्हें उचित संचालन प्रक्रिया की ओर ले जाना चाहिए, न कि यह मानते हुए कि प्रत्येक वेबहूक एक ही प्रकार की बातचीत का प्रतिनिधित्व करता है।
यह परिभाषित करें कि आने वाले जवाब को क्या करना चाहिए। एक काल्पनिक सेवा पुनर्निर्धारण के अनुरोध को पहचान सकती है, यह स्वीकार कर सकती है कि यह समर्थन कतार तक पहुँच गई है और बातचीत को मूल नियुक्ति से जोड़ सकती है। एक अपरिचित उत्तर के लिए अभी भी एक समझने योग्य परिणाम की आवश्यकता होती है। इसे चुपचाप न फेंकें क्योंकि यह प्रदर्शन में उपयोग किए गए एक मुख्य शब्द से मेल नहीं खाता है। समीक्षा करें कि कौन सी जानकारी संग्रहीत की गई है, इसे कौन देख सकता है और जब स्वचालित संचालन इच्छित अनुरोध को निर्धारित नहीं कर सकता है तो व्यक्ति को कैसे मदद मिलेगी।
9. ग्राहक की पसंद और ऑप्ट-आउट लागू करें
मैसेजिंग प्रोजेक्ट में प्राप्तकर्ता की संचार संबंधी पसंद लागू करने का स्पष्ट तरीका होना चाहिए। चुने हुए चैनल के लिए Twilio के मौजूदा टूल और दस्तावेज देखें, जिनमें लागू ऑप्ट-आउट सुविधाएं भी शामिल हैं। एप्लिकेशन में सहेजे सहमति और पसंद के रिकॉर्ड सेवा प्रक्रिया के अनुरूप रखें। पसंद केवल डेटाबेस में लिखा लेबल बनकर न रह जाए: जिन संदेशों को रोकना चाहिए, उन्हें बाद में भी शेड्यूल या भेजते रहना उस पसंद का पालन नहीं है।
संदेश की कतार लगने के बाद होने वाले परिवर्तनों के बारे में सोचें। एक व्यक्ति अनुमति वापस ले सकता है, किसी गंतव्य को ठीक कर सकता है या उस मुद्दे को हल कर सकता हैं जिसने मूल रूप से एक अधिसूचना को शुरू किया था। परिभाषित करें कि एप्लिकेशन अगले प्रेषण से पहले पात्रता की पुनः जाँच कैसे करता है और ऑपरेटर एक विसंगति की जांच कैसे कर सकते हैं। सटीक कानूनी और मंच आवश्यकताएँ उपयोग मामले और गंतव्य पर निर्भर करती हैं। परियोजना के लिए उचित समीक्षा प्राप्त करें। यह परिचालन योजना उस समीक्षा को प्रतिस्थापित नहीं करती है, लेकिन यह सुनिश्चित करने में मदद करती है कि एक उल्लिखित वरीयता वास्तव में प्रणाली के काम को प्रभावित करती है।
10. ऐसा संदेश लिखें जो अपने आप स्पष्ट हो
एक प्राप्तकर्ता को यह समझना चाहिए कि उनसे कौन संपर्क कर रहा है, संचार क्यों महत्वपूर्ण है और क्या कार्रवाई उपलब्ध है। सादे शब्दों का उपयोग करें और उन विवरणों को हटा दें जो कार्य में मदद नहीं करते हैं। एक काल्पनिक अनुस्मारक सेवा, नियुक्ति की तारीख और परिवर्तन का अनुरोध करने के लिए एक स्पष्ट मार्ग की पहचान कर सकता है। साझा उपकरण या लॉक स्क्रीन पर दिखाई देने वाले संदेश में अनावश्यक संवेदनशील जानकारी को शामिल करने से बचें।
एप्लिकेशन के अपने इंटरफेस के बाहर संदेश की जाँच करें। एक वाक्य जो वेबसाइट के शीर्षक या आइकन पर निर्भर करता है, जब यह किसी मैसेजिंग ऐप में अकेला दिखाई देता है तो यह स्पष्ट नहीं हो सकता है। लिंक और उनके गंतव्य की सावधानीपूर्वक समीक्षा करें। प्राप्तकर्ता को यह अनुमान नहीं लगाना चाहिए कि कोई संक्षिप्त या अपरिचित लिंक संगठन का है या नहीं। सामग्री को वास्तविक व्यावसायिक रिकॉर्ड के अनुरूप रखें और इसे बड़े पैमाने पर भेजने से पहले शब्दों में किसी भी बदलाव की समीक्षा करें। कई प्राप्तकर्ताओं में दोहराने पर छोटी पाठ त्रुटियाँ बड़ी समर्थन समस्याएं बन सकती हैं।
11. प्राप्तकर्ता और समय की धारणाएं जांचें
एक संचार अनुप्रयोग को समर्थित उपकरणों और प्रलेखित परंपराओं का उपयोग करके गंतव्य के रूप और अर्थ को मान्य करना चाहिए। एक सही प्रारूपित मूल्य इस बात का प्रमाण नहीं है कि वर्तमान उपयोगकर्ता इसका मालिक है या कोई संदेश चाहता है। खाते के उचित सत्यापन और अनुमति प्रक्रिया के साथ गंतव्य संचालन को जोड़ें। सुधारों का रिकॉर्ड रखें ताकि एक पुराना गंतव्य चुपचाप फिर से दिखाई न दे जब एप्लिकेशन का दूसरा हिस्सा एक बासी ग्राहक रिकॉर्ड को बचाता है।
समय-निर्धारण के लिए भी स्पष्ट धारणाओं की आवश्यकता होती है। घटना और प्राप्तकर्ता-सामना करने वाले शब्दों पर कौन सा समय क्षेत्र लागू होता है, यह दर्ज करें। समीक्षा करें कि जब कोई मुलाकात बदलती है या जब कोई निर्धारित संदेश उपयोगी नहीं होता है तो क्या होता है। रद्द होने के बाद भेजा गया अनुस्मारक तकनीकी रूप से दिया जा सकता है और परिचालन में गलत हो सकता है। एक सफल समयबद्ध प्रदर्शन को इस बात के प्रमाण के रूप में मानने से पहले कि पूरा समय-निर्धारण कार्यप्रवाह सामान्य ग्राहक उपयोग के लिए तैयार है, इन सामान्य परिवर्तनों का परीक्षण करें।
12. गलती से एक ही संदेश दोबारा भेजने से बचें
ब्राउज़र के दोबारा कोशिश करने, बैकग्राउंड वर्कर के फिर शुरू होने या एप्लिकेशन के दो हिस्सों के एक ही कारोबारी घटना पर प्रतिक्रिया देने से डुप्लिकेट संदेश भेजे जा सकते हैं। उस घटना और इच्छित संदेश के बीच स्पष्ट संबंध बनाएं। प्रयास और प्रदाता द्वारा स्वीकार किए जाने का उपलब्ध प्रमाण सहेजें। नेटवर्क रुकने से स्वीकृति अस्पष्ट हो तो यह मानकर दूसरी कॉपी न भेजें कि कुछ हुआ ही नहीं था; पहले सहेजे गए रिकॉर्ड की जांच करें।
एक काल्पनिक आदेश अधिसूचना में एक विशेष घटना और टेम्पलेट संस्करण के लिए एक स्वामित्व वाला प्रेषण निर्णय हो सकता है। उस निर्णय पर एक और संदेश बनाए बिना फिर से विचार करना सुरक्षित होना चाहिए क्योंकि वही इनपुट फिर से आया। यह तय करें कि वास्तविक पुनः प्रेषण कब उपयुक्त है और इसे एक अलग जानबूझकर की गई कार्रवाई के रूप में चिह्नित करें। यह एक परिचालन इतिहास बनाता है जिसे कोई भी समझ सकता है। यह ग्राहक द्वारा अनुरोधित दोहराव को तकनीकी दोहराव से अलग करना भी आसान बनाता है जिसे अनुप्रयोग को रोकना चाहिए था।
13. वॉइस कॉल को पूरी बातचीत की तरह डिजाइन करें
Twilio के प्रोग्रामेबल वॉयस प्रलेखन में वॉयस कॉल और संबंधित सुविधाओं को बनाने और संभालने के तरीके शामिल हैं। उपलब्ध नियंत्रणों की सूची के बजाय कॉल के कारण से शुरू करें। एक इनबाउंड सर्विस लाइन, एक अधिसूचना और एक निर्देशित फोन मेनू अलग-अलग अपेक्षाएँ पैदा करते हैं। एक जटिल कॉल प्रवाह लिखने से पहले प्रारंभिक संदेश, कॉल करने वाले के लिए उपलब्ध विकल्प और उचित सहायता के लिए मार्ग को परिभाषित करें।
कॉल करने वाले की ओर से बातचीत का परीक्षण करें। अभिवादन सुनें, एक सामान्य विकल्प चुनें और जानबूझकर अप्रत्याशित प्रतिक्रिया दें। जाँच करें कि क्या कॉल करने वाला समझता है कि क्या हो रहा है और वह गलती से उबर सकता है। तकनीकी रूप से जुड़ने वाली कॉल तब भी एक सेवा अनुभव के रूप में विफल हो सकती है यदि मेनू अस्पष्ट है या कोई विकल्प कहीं नहीं जाता है। ध्वनि परियोजना को पूरी बातचीत के स्वामित्व की आवश्यकता होती है, जिसमें मौन, बार-बार इनपुट, डिस्कनेक्शन और उस बिंदु पर जहां एक व्यक्ति को मानव सहायता की आवश्यकता है।
14. वॉइस मेन्यू छोटा रखें और गलती सुधारने का रास्ता दें
एक उपयोगी वॉयस मेनू कॉल करने वाले को एक सार्थक अगले चरण तक पहुंचने में मदद करता है। बहुत सारे विकल्पों को याद रखना मुश्किल हो सकता है, खासकर जब कॉल करने वाला विचलित हो या किसी अपरिचित भाषा का उपयोग कर रहा हो। सेवा यात्रा के अनुसार समूह विकल्प और स्पष्ट शब्दों का उपयोग करें। यदि कॉल करने वाला एक अमान्य विकल्प प्रदान करता है, तो अनिश्चित काल के लिए एक लंबी व्याख्या को फिर से शुरू करने के बजाय एक उचित पुनर्प्राप्ति मार्ग प्रदान करें।
वास्तविक प्लेबैक अनुभव में समय और सुलभता की समीक्षा करें। एक संकेत बहुत जल्दी बोला जा सकता है, एक विराम बहुत छोटा हो सकता है या एक पुष्टि अस्पष्ट हो सकती है। उन विवरणों का परीक्षण इच्छित दर्शकों के साथ करें जहां व्यावहारिक हो। सेवा डिजाइन की आवश्यकता होने पर किसी अन्य उपयुक्त चैनल के माध्यम से महत्वपूर्ण जानकारी उपलब्ध रखें। एक वॉयस मेनू से मदद पाने में घर्षण कम होना चाहिए। यह एक ऐसी बाधा नहीं बननी चाहिए जो अन्यथा एक सरल ग्राहक अनुरोध को पूरा करना कठिन बना देती है।
15. रिकॉर्डिंग और ट्रांसक्रिप्ट को संवेदनशील सामग्री समझें
एक परियोजना जो कॉल रिकॉर्ड या ट्रांसक्राइब करती है, अतिरिक्त जिम्मेदारियां पैदा करती है। तय करें कि क्या वे परिसंपत्तियाँ आवश्यक हैं, कौन उन्हें प्राप्त कर सकता है और उन्हें कब तक बनाए रखा जाना चाहिए। वर्तमान उत्पाद नियंत्रणों और इच्छित उपयोग पर लागू आवश्यकताओं की समीक्षा करें। केवल एक विन्यास विकल्प मौजूद होने के कारण रिकॉर्डिंग को चालू न करें। परियोजना को यह समझाने में सक्षम होना चाहिए कि रिकॉर्डिंग किस उद्देश्य को पूरा करती है और इसमें शामिल लोगों को कैसे सूचित किया जाता है।
पहुँच को नियंत्रित रखें और रिकॉर्डिंग को व्यापक रूप से साझा किए गए समर्थन टिप्पणियों में नक़ल करने से बचें। यदि किसी मुद्दे की जाँच एक सीमित तकनीकी रिकॉर्ड के माध्यम से की जा सकती है, तो पूरी बातचीत को प्रसारित करने के बजाय उस रिकॉर्ड का उपयोग करें। जहाँ एक प्रतिलेख का उपयोग किया जाता है, याद रखें कि इसमें त्रुटियाँ हो सकती हैं और इसकी साफ-सुथरी स्वरूपण प्रत्येक शब्द को सटीक नहीं बनाती है। ये व्यावहारिक सूचना-प्रबंधन विचार हैं; किसी विशेष संगठन को यह तय करने से पहले विशेषज्ञ समीक्षा की आवश्यकता हो सकती है कि एक रिकॉर्डिंग या प्रतिलिपि अपनी सेवा प्रक्रिया में कैसे फिट बैठती है।
16. पहचान संख्या और घटनाओं से समस्या जांचें
एक उपयोगी समर्थन रिकॉर्ड अनुप्रयोग के व्यावसायिक संदर्भ को प्रदाता के संचार पहचानकर्ता और प्रासंगिक घटना इतिहास से जोड़ता है। एक अधिकृत प्रचालक को यह देखने में सक्षम होना चाहिए कि अनुरोध कब किया गया था, कौन सा स्वीकृति प्रमाण मौजूद है और बाद में कौन से कॉलबैक को सत्यापित किया गया। नियमित लॉग में क्रेडेंशियल्स या अनावश्यक संदेश सामग्री को शामिल करने से बचें। अभिलेख को जाँच की आवश्यकता से अधिक जानकारी को उजागर किए बिना मुद्दे की जाँच करने में मदद करनी चाहिए।
तकनीकी लक्षणों को निष्कर्षों से अलग करें। एक अनुपलब्ध कॉलबैक अंतिम बिंदु, एक अमान्य गंतव्य और एक अस्पष्ट प्रारंभिक नेटवर्क प्रतिक्रिया अलग-अलग परिस्थितियाँ हैं। देखी गई त्रुटि को दर्ज करें और इसमें शामिल संसाधन के लिए वर्तमान दस्तावेजों का पालन करें। प्रत्येक अनसुलझे संदेश को वितरित या केवल डैशबोर्ड को पूरा करने में विफल होने के रूप में लेबल न करें। स्पष्ट साक्ष्य एक समर्थन प्रक्रिया को बड़ी मात्रा में स्थिति जानकारी की तुलना में अधिक उपयोगी बनाता है जिसका वास्तविक ग्राहक बातचीत के साथ संबंध अनिश्चित है।
17. चैनल और गंतव्य के अनुसार बजट
संचार लागत उत्पाद और किए जा रहे काम पर निर्भर करती है। वर्तमान Twilio मूल्य निर्धारण और चयनित चैनल, गंतव्य और प्रेषक व्यवस्था से संबंधित शर्तों की समीक्षा करें। यह न मान लें कि एक परीक्षण संदेश प्रति ग्राहक सार्वभौमिक लागत स्थापित करता है। एक वास्तविक सेवा को जवाब, बार-बार वैध अधिसूचनाओं या अन्य संचालन के लिए भी जिम्मेदार होना पड़ सकता है जो पूरी यात्रा का हिस्सा हैं।
एक परिभाषित परिदृश्य से एक अनुमान बनाएँ। एक काल्पनिक नियुक्ति सेवा यह सूचीबद्ध कर सकती है कि एक सामान्य बुकिंग के कितने अनुस्मारक और अपेक्षित उत्तर हैं, फिर इसकी अपेक्षित मात्रा के साथ तुलना करें। धारणाओं को दिखाई देते रहें और जब डिजाइन बदल जाता है तो उन्हें फिर से देखें। यह एक कार्यप्रवाह के लिए एक सटीक मासिक आंकड़े का विज्ञापन करने से अधिक उपयोगी है जो निर्दिष्ट नहीं किया गया है। ऑपरेशन के बाद वास्तविक उपयोग रिकॉर्ड को संरक्षित करें ताकि टीम अपने अनुमान की तुलना स्मृति के बजाय साक्ष्य से कर सके।
18. संदेश भेजने वाले एंडपॉइंट को दुरुपयोग से बचाएं
एक अनुप्रयोग जो संचार भेज सकता है, उसका भी दुरुपयोग किया जा सकता है यदि इसमें उचित नियंत्रण का अभाव है। प्रमाणित कार्रवाई को सत्यापित करें, इच्छित प्राप्तकर्ता को मान्य करें और सेवा के उद्देश्य के लिए उपयुक्त सीमाएँ लागू करें। चयनित उत्पाद के लिए Twilio के वर्तमान सुरक्षा और धोखाधड़ी-रोकथाम मार्गदर्शन की समीक्षा करें। किसी ऐसे सार्वजनिक रूप को उजागर करने से बचें जो किसी अधिकृत व्यावसायिक कार्रवाई के साथ प्रभावी संबंध के बिना बार-बार मनमाने गंतव्यों पर संदेश या कॉल को ट्रिगर कर सकता है।
अप्रत्याशित पैटर्न की निगरानी करें और परिभाषित करें कि कौन उनका जवाब देता है। मात्रा में अचानक परिवर्तन, गंतव्य वितरण या बार-बार विफलताओं की जांच की आवश्यकता हो सकती है। प्रतिक्रिया को आनुपातिक और देखे गए साक्ष्य के आधार पर रखें। प्रचालन सुरक्षा को यह समझने की क्षमता को बनाए रखना चाहिए कि क्या हुआ, न कि रिकॉर्ड को मिटाना या यह मानना कि प्रत्येक असामान्य घटना हानिरहित है। एक भरोसेमंद संचार सेवा में इच्छित ग्राहक मार्ग और नियंत्रण दोनों शामिल हैं जो उस मार्ग को एक अप्रतिबंधित प्रेषण तंत्र बनने से रोकते हैं।
19. बदलाव और त्रुटियों को भी शुरुआती परीक्षण में रखें
एक पायलट को खुशहाल मार्ग से अधिक परीक्षण करना चाहिए। एक काल्पनिक अनुस्मारक सेवा के लिए, एक नई बुकिंग, एक पुनर्निर्धारित नियुक्ति, एक रद्द यात्रा, एक आने वाला प्रश्न और एक गंतव्य शामिल करें जो इच्छित संदेश प्राप्त नहीं कर सकता है। पुष्टि करें कि ग्राहक क्या देखता है और सहायता दल क्या जांच कर सकता है। जहाँ उपयुक्त हो, हानिरहित परीक्षण डेटा और प्रदाता के समर्थित परीक्षण विकल्पों का उपयोग करें। पायलट को तब तक सीमित रखें जब तक कि टीम प्रत्येक परिदृश्य के परिणाम को नहीं समझती।
स्वीकृति मानदंड पहले से लिख लें। एक अनुस्मारक में वर्तमान जानकारी होनी चाहिए, लागू वरीयता का सम्मान करना चाहिए और एक वास्तविक समर्थन मार्ग की ओर ले जाना चाहिए। कॉलबैक को डुप्लिकेट सेंड बनाए बिना सही स्वामित्व वाले रिकॉर्ड को अपडेट करना चाहिए। एक असफल डिलीवरी को एक स्वीकृत लेकिन अनसुलझे अनुरोध से अलग होना चाहिए। ये मानदंड तकनीकी कार्यान्वयन को दी जा रही सेवा से जोड़ते हैं। जब अगला टेम्पलेट या कार्यप्रवाह परिवर्तन पेश किया जाता है तो वे टीम को एक दोहराने योग्य परीक्षण भी देते हैं।
20. Twilio प्रोजेक्ट शुरू करने की व्यावहारिक योजना
एक ग्राहक यात्रा और एक उपयुक्त चैनल से शुरुआत करें। प्रेषक की आवश्यकताओं की पुष्टि करें, स्पष्ट शब्द तैयार करें और उत्तर मार्ग को परिभाषित करें। सर्वर पर क्रेडेंशियल्स रखें, प्रदाता पहचानकर्ताओं को सहेजें और आने वाली घटनाओं को सत्यापित करें। एप्लिकेशन और इसकी रिपोर्ट दोनों में अलग-अलग संदेश स्वीकृति, वितरण और व्यावसायिक परिणाम। योजना बनाएँ कि जब अंतर्निहित नियुक्ति, आदेश या ग्राहक वरीयता बदल जाती है तो कार्यप्रवाह कैसे प्रतिक्रिया करता है।
फिर एक छोटा सा प्रायोगिक प्रयोग करें, प्राप्तकर्ता के पूर्ण अनुभव की समीक्षा करें और अपेक्षित प्रक्रिया के साथ वास्तविक घटनाओं की तुलना करें। चैनल, गंतव्य रणनीति या महत्वपूर्ण विन्यास को बदलते समय दस्तावेजों की फिर से जांच करें। Twilio संचार क्षमताओं की आपूर्ति करता है; परियोजना को उन क्षमताओं को एक समझने योग्य और अच्छी तरह से संचालित सेवा में बदलना चाहिए। सबसे उपयोगी कार्यान्वयन वह है जिसमें ग्राहक, प्रचालक और एप्लिकेशन रिकॉर्ड सभी यह समझ सकते हैं कि क्या हुआ और आगे क्या होना चाहिए।
स्रोत और आगे पढ़ने की सामग्री
तकनीक और API की दूसरी गाइड पढ़ें
सूचना प्रौद्योगिकी की अन्य स्वतंत्र गाइड में मैसेजिंग, क्रिएटिव मॉडल API, वॉइस टूल और संचार वर्कफ़्लो की तुलना करें।
सूचना प्रौद्योगिकी के लेख देखें
