शर्तें और दिशा-निर्देश

Business Messages के एजेंट के ज़रिए उपयोगकर्ताओं से इंटरैक्ट करते समय इन सबसे सही तरीकों को ध्यान में रखें.

संवेदनशील जानकारी न दें और न ही उसका अनुरोध करें

चैट के दौरान संवेदनशील सामग्री से बचने से, आपकी और आपके ग्राहकों की जानकारी सुरक्षित रहती है. संवेदनशील जानकारी में नीचे दी गई चीज़ों के साथ दूसरी जानकारी भी शामिल हो सकती है

  • क्रेडिट कार्ड नंबर
  • सामाजिक सुरक्षा, पासपोर्ट या दूसरी सरकारी पहचान संख्या
  • लॉगिन क्रेडेंशियल. जैसे- पासवर्ड

उपयोगकर्ताओं को तुरंत जवाब देना

उपयोगकर्ता के मैसेज का धीमा या अनुचित जवाब देने से आपके ग्राहकों को खराब अनुभव मिलता है. अपने जवाब में दिए गए इन्फ़्रास्ट्रक्चर को इस तरह डिज़ाइन करना न भूलें कि वह उपयोगकर्ता मैसेज का समय पर जवाब दे सके.

एक धीमे जवाब से भी खराब, कोई जवाब नहीं होता है. पक्का करें कि उपयोगकर्ताओं को हमेशा उनके मैसेज पर जवाब मिलें, चाहे आपका मैसेज लोड कुछ भी हो. उदाहरण के लिए, अगर लाइव स्टाफ़ उपलब्ध नहीं है, तो उपयोगकर्ता को इसकी जानकारी देने वाला एक ऑटोमेटेड मैसेज भेजें. साथ ही, यह बताएं कि उपयोगकर्ता जवाब कब दे सकता है.

Google, मैसेज के बीच जवाब देने के लिए समय (टीटीआर) मेज़र करता है. अगर किसी ब्रैंड का एजेंट, उपभोक्ताओं को जवाब देने में ज़्यादा समय ले रहा है, तो Google उस ब्रैंड के मैसेज बटन को हटा देगा.

जब ऑटोमेशन, अनुरोधों को पूरा नहीं कर पाता है, तो उसे लोगों को दे दें

ऑटोमेशन की सुविधा ठीक से काम न करने पर, उपयोगकर्ता परेशान हो जाते हैं. इसलिए, Google से मैनेज किए जाने वाले एंट्री पॉइंट (Google Ads के एंट्री पॉइंट को छोड़कर) से लॉन्च होने वाले सभी एजेंट के लिए ज़रूरी है कि उनके पास ऐसे प्रतिनिधि हों जो ऑटोमेशन का इस्तेमाल न कर सकें. लॉन्च करने से पहले, आपको प्रतिनिधि के तौर पर एजेंट इंटरैक्शन सेट करना होगा.

जब ऑटोमेशन, उपयोगकर्ता के अनुरोध को लगातार दो बार पूरा नहीं कर पाता है, तो लाइव एजेंट के लिए अनुरोध के सुझाव वाला मैसेज भेजना सबसे अच्छा तरीका होता है.

लाइव एजेंट से अनुरोध करने का सुझाव

जब कोई उपयोगकर्ता इस सुझाव पर टैप करता है, तो आपके एजेंट को लाइव एजेंट के लिए अनुरोध किया गया इवेंट मिलता है. आपके एजेंट को बातचीत का जवाब, किसी मानव प्रतिनिधि को देना होगा, ताकि उपयोगकर्ता को उसकी मदद मिल सके.

लोगों को हर समय आपकी साइट पर मौजूद रहना ज़रूरी नहीं है. अपने एजेंट की उपलब्धता सेट करें, ताकि उपयोगकर्ताओं को पता हो कि कब उन्हें जवाब मिलेगा.

OAuth का इस्तेमाल करने वाले उपयोगकर्ताओं की पुष्टि करें

उपयोगकर्ताओं की पहचान की पुष्टि करने और उन्हें मनमुताबिक जानकारी देने के लिए, OAuth के ज़रिए बैकएंड सिस्टम से उपयोगकर्ताओं की पुष्टि करें. OAuth का इस्तेमाल करके पुष्टि करने पर, एजेंट को उपयोगकर्ता का डेटा तेज़ी से ऐक्सेस करने की सुविधा मिलती है. इससे, उपयोगकर्ता या एजेंट, बातचीत में संवेदनशील जानकारी (जैसे कि उपयोगकर्ता नाम या पासवर्ड) भी शामिल नहीं कर सकते. OAuth की मदद से पुष्टि करना देखें.

कारोबार के मैसेज में सीएसएटी का आकलन करना

Business Messages, ग्राहक के अनुभव से जुड़े स्कोर (सीएसएटी) का आकलन, सीधे सर्वे की मदद से करता है. यह मैसेज सेवा देने वाली कंपनियों के साथ होता है. उपयोगकर्ताओं को एक से ज़्यादा सर्वे पाने से रोकने के लिए, Business Messages की सर्वे सुविधा का इस्तेमाल करें. सीएसएटी मेज़रमेंट की अपनी तकनीकें लागू न करें.

विषय पर बने रहें

ऐसे मैसेज न भेजें जो मौजूदा बातचीत से अनचाहे हों या काम के न हों. उदाहरण के लिए,

  • किसी ऐसे प्रॉडक्ट या सेवा के बारे में मैसेज जो मूल अनुरोध से संबंधित नहीं है
  • उपयोगकर्ताओं के जवाब के बिना बार-बार मिलने वाले मैसेज
  • बहुत ज़्यादा मैसेज दिखना या इमोजी और यूआरएल का बहुत ज़्यादा इस्तेमाल करना

जगह का आईडी उपलब्ध होने पर उसका लाभ उठाएं

जगह के हिसाब से एंट्री पॉइंट के लिए, मैसेज में संदर्भ पेलोड में placeId शामिल हो सकते हैं. इसका इस्तेमाल, ऐसी जानकारी देने के लिए किया जा सकता है जिसके बारे में उपयोगकर्ता पूछ रहा हो. जैसे, किसी खास जगह की इन्वेंट्री. placeId Google Places के डेटाबेस और Google Maps Platform में किसी जगह की खास पहचान करता है.

यहां तक कि अगर आप सिर्फ़ जगह के हिसाब से एंट्री पॉइंट के साथ लॉन्च करते हैं, तो भी उन स्थितियों के लिए एक रणनीति लागू करना न भूलें जहां placeId मौजूद नहीं है. हालांकि, आम तौर पर ऐसा नहीं होता. हालांकि, कुछ स्थितियां ऐसी होती हैं जिनमें placeId आपके काम के दूसरे डेटा के साथ, आपके वेबहुक में पास नहीं होता.

एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करना

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

एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करने की सुविधा का इस्तेमाल करने पर, आपका इन्फ़्रास्ट्रक्चर अपने-आप चालू हो जाता है

  1. पूरे न हो पाने वाले एपीआई कॉल की पहचान करता है
  2. इंतज़ार का शुरुआती समय और ज़्यादा से ज़्यादा बार कोशिश करने की सुविधा सेट करता है
  3. इंतज़ार का समय रोकने के लिए
  4. एपीआई कॉल को फिर से आज़माया जा सकता है
  5. एपीआई कॉल के जवाब का आकलन करता है:

    • अगर सफल हो जाए, तो वर्कफ़्लो में अगले चरण पर जाएं
    • अगर ऐसा नहीं होता है, तो इंतज़ार की अवधि बढ़ जाती है और तीसरे चरण पर वापस आ जाता है
    • ज़्यादा से ज़्यादा बार कोशिश करने के बाद भी फ़ेल होने की स्थिति में, फ़ेल स्थिति मिलती है

सही इंतज़ार अवधि और फिर से कोशिश करने का सबसे सही तरीका, इस्तेमाल के हिसाब से अलग-अलग हो सकता है. अपने इन्फ़्रास्ट्रक्चर और वर्कफ़्लो की इंतज़ार के समय की ज़रूरतों के आधार पर ये संख्याएं तय करें.

डुप्लीकेट इनकमिंग मैसेज की जांच करें

उपयोगकर्ताओं के इनकमिंग मैसेज को देखने और उनका जवाब देने के लिए, messageId देखें और पुष्टि करें कि आपको अब तक कोई मैसेज न मिला हो और उसका जवाब दिया गया हो.

डिस्ट्रिब्यूट किए गए सिस्टम में, मैसेज भेजने के दो तरीके हैं: ज़्यादा से ज़्यादा एक बार और कम से कम एक बार. "ज़्यादा से ज़्यादा एक बार" सिस्टम के साथ, सिस्टम एक बार मैसेज भेजता है. हालांकि, इस दौरान नेटवर्क या संचार से जुड़ी गड़बड़ियां होने पर शायद मैसेज न मिले. "कम से कम एक बार" सिस्टम के साथ, सिस्टम एक से ज़्यादा बार मैसेज भेज सकता है, लेकिन नेटवर्क या कम्यूनिकेशन में गड़बड़ियां होने पर भी मैसेज मिल सकता है.

Business Messages में, "कम से कम एक बार" सिस्टम का इस्तेमाल होता है. हालांकि, इससे डुप्लीकेट मैसेज ले सकते हैं, लेकिन messageId स्ट्रिंग को ट्रैक करके, मैसेज की डुप्लीकेट कॉपी को हटाना आसान है. अगर आपको पहले ही कोई मैसेज मिल चुका है, तो messageId के साथ मिलने वाले मैसेज को नज़रअंदाज़ करना सुरक्षित है.