स्केल करने से पहले वॉइस एजेंट जाँच की चेकलिस्ट

सफलता को एक जाँचे गए बिज़नेस नतीजे के रूप में तय करें। अपॉइंटमेंट फ़्लो के लिए जाँचें कि सही समय, सर्विस और कॉल करने वाले की जानकारी दर्ज हुई और बोली गई पुष्टि उस रिकॉर्ड से मेल खाती है। सहज बातचीत या खाली न होने वाला ट्रांसक्रिप्ट काम पूरा होने का पर्याप्त सबूत नहीं है।

कनेक्शन, बातचीत की गुणवत्ता और काम पूरा होने को अलग रखें। कैरियर का कॉल मना करना, गलत समझे गए नाम से अलग तरह की गड़बड़ी है, और दोनों अपॉइंटमेंट API के एरर लौटाने से अलग हैं। गड़बड़ी की श्रेणी दर्ज करें ताकि सुधार सही परत पर हो।

जिन कामों और भाषाओं को आप संभालना चाहते हैं, उनसे एक टेस्ट सेट बनाएँ। जहाँ हो सके, सहमति देने वाले टेस्टर और बनावटी जानकारी इस्तेमाल करें। निर्देश और परिस्थितियों के निर्देशों का वर्ज़न रखें ताकि इंजन या इंटीग्रेशन बदलने के बाद वही जाँच दोहरा सकें।

नीचे के केस शुरुआती चेकलिस्ट हैं। ये सुझाए गए टेस्ट हैं, यह दावा नहीं कि हर इंजन इन्हें पास करता है। अपने ऐप्लिकेशन के लिए ज़रूरी कॉल करने वाले का व्यवहार और फ़ेल होने की स्थितियाँ जोड़ें।

• एक सीधी माँग, जिसका अपेक्षित नतीजा साफ़ हो।
• बातचीत के बीच में सुधारा गया नाम, फ़ोन नंबर या अपॉइंटमेंट का समय।
• एजेंट के बोलते समय टोकना, और फिर कोई दूसरी माँग।
• पीछे का शोर, चुप्पी, अनजाना लहजा और हर सपोर्ट की गई लक्ष्य भाषा।
• नॉलेज बेस से बाहर का सवाल और ऐसी माँग जिसे पूरा करने की एजेंट को अनुमति नहीं है।
• उपलब्ध न होने वाला बैकएंड, दोहराया गया इवेंट और काम पूरा होने से पहले कॉल करने वाले का कॉल काटना।
• इंसान से बात करने की माँग, जिसे उस एस्केलेशन व्यवहार पर टेस्ट किया जाए जो आपका ऐप्लिकेशन असल में करता है।

परिस्थिति, इंजन और निर्देश का वर्ज़न, कॉल आइडेंटिफ़ायर, कनेक्शन का नतीजा, काम का नतीजा, अवधि और लागत दर्ज करें। किसी समीक्षक से असल बिज़नेस रिकॉर्ड जँचवाएँ, बजाय इसके कि वही एजेंट अपने जवाब को ख़ुद नंबर दे।

जवाब देने की तेज़ी के लिए वह अंतराल तय करें जिसे आप मापते हैं, जैसे कॉल करने वाले की बात ख़त्म होने से एजेंट की सुनाई देने वाली आवाज़ शुरू होने तक। डिस्ट्रिब्यूशन, सैंपल साइज़ और टेस्ट की स्थितियाँ बताएँ। एक तेज़ डेमो को लेटेंसी के आम वादे में न बदलें।

• काम पूरा होने की दर = जाँच में पूरे पाए गए काम / उस काम के लिए जाँची गई बातचीत।
• कनेक्शन दर = कनेक्ट हुई कॉल / कोशिश की गई कॉल, अलग से बताई जाए।
• हर पूरे काम की लागत = पायलट का पूरा खर्च / जाँच में पूरे पाए गए काम; शून्य पूरे काम होने पर इसे अपरिभाषित बताएँ।
• गंभीर गलतियों को अलग से दर्ज करें ताकि कोई औसत गलत बुकिंग या मनगढ़ंत जवाब को छिपा न सके।

स्टेटस, ट्रांसक्रिप्ट और cost_micros के लिए कॉल रिकॉर्ड पढ़ें। जब कॉल कनेक्ट नहीं हुई, तो निर्देश बदलने से पहले failure_code और failure_reason देखें। चार्ज को usage events से मिलाएँ। जब कॉल पूरी हो गई लेकिन आपका ऐप्लिकेशन अपडेट नहीं हुआ, तब webhook डिलीवरी देखें।

कॉल शुरू करते समय idempotency की इस्तेमाल करें ताकि रिक्वेस्ट दोबारा भेजने पर दूसरी बार डायल न हो। दोहराई गई डिलीवरी के लिए अपना इवेंट हैंडलर टेस्ट करें और उसका सेव किया गया नतीजा जाँचें। पायलट बड़ा होने से पहले ऑथेंटिकेशन और webhook सिग्नेचर की जाँच इंटीग्रेशन में होनी चाहिए।

तब आगे बढ़ें जब आपकी पहले से तय स्वीकृति की शर्तें पूरी हों, गंभीर गड़बड़ियों के ज़िम्मेदार तय हों और ऑपरेशन का रास्ता टेस्ट हो चुका हो। थ्रेशोल्ड अपने इस्तेमाल के जोखिम और महत्व के हिसाब से चुनें; ऐसी कोई एक काम पूरा होने की दर नहीं है जिससे हर वॉइस वर्कफ़्लो तैयार माना जाए।

ट्रैफ़िक नियंत्रित हिस्सों में बढ़ाएँ, फ़ेल हुई कॉल देखें और देखे गए खर्च की बजट से तुलना करें। निर्देश और मॉडल में बदलाव के लिए वापस लौटने का रास्ता रखें। अगर आप केस स्टडी प्रकाशित करते हैं, तो मापे गए नतीजे तरीके और सीमाओं के साथ बताएँ।

यह संसाधन Wixzel Voice ने प्रकाशित किया है। प्रोडक्ट की जानकारी नीचे दिए रेफ़रेंस से ली गई है; जाँच की सिफ़ारिशें एक सुझाया गया तरीका हैं, बेंचमार्क के नतीजे नहीं।

• कॉल एरर और फ़ेल होने के कोड
• Webhook डिलीवरी और जाँच
• Idempotency के साथ सुरक्षित दोबारा कोशिश

कोई गलती मिली? सुधार भेजें।