इस पेज पर
सहायता टिकट पर “पूरा” लिखा हो, फिर भी ग्राहक सुविधा इस्तेमाल न कर पाए। एक काल्पनिक CSV निर्यात अनुरोध में टिकट T-104 का कोड मिला दिया गया है, लेकिन सुविधा का रोलआउट अब भी बंद है। “आपकी सुविधा उपलब्ध है” कहना टूटा हुआ वादा होगा।
एक अनुरोध को एक पुष्ट रिलीज़ और एक ऐसे व्यक्ति से जोड़ें जिससे संपर्क हो सके। xAI का GTM Loop Closer उदाहरण प्रतिबद्धताएँ ढूँढ़ने, प्रमाण दिखाने और उत्तर तैयार करने की बात करता है। यहाँ प्रतिबद्धता की जाँच और कड़ी है: उत्पाद प्रबंधक को पुष्टि करनी होगी कि क्या रिलीज़ हुआ और कौन उसे इस्तेमाल कर सकता है।
रिलीज़ का प्रमाण हो तभी शुरू करें
ट्रिगर के लिए टिकट की स्थिति नहीं, उत्पाद रिलीज़ रिकॉर्ड लें। उसमें स्थिर feature_id, release_id, रिलीज़ हुआ व्यवहार, रिलीज़ तारीख, रोलआउट स्थिति और नामित प्रबंधक चाहिए। प्रबंधक जाँचे कि अनुरोध करने वाले ग्राहक के खाते या प्लान में सुविधा उपलब्ध है। मिला दिया गया कोड, परीक्षण वातावरण का डेमो या प्रस्तावित रिलीज़ नोट पर्याप्त नहीं।
अनुरोध रिकॉर्ड को सुविधा ID के माध्यम से रिलीज़ से, और अनुरोध को सहायता प्रणाली के संपर्क ID से ग्राहक से जोड़ें। केवल मैपिंग और स्थिति रखें। Grok Bot को पूरा इनबॉक्स या कैटलॉग नहीं चाहिए। कोई ID न मिले तो मिलते-जुलते नाम से अनुमान लगाने के बजाय समीक्षा का विषय लौटाएँ।
| इनपुट | न्यूनतम फ़ील्ड | जाँच |
|---|---|---|
| अनुरोध | टिकट ID, सुविधा ID, अनुरोध तारीख, अनुरोधकर्ता का संपर्क ID | इस व्यक्ति ने सच में यह सुविधा माँगी थी |
| रिलीज़ | रिलीज़ ID, सुविधा ID, रिलीज़ हुआ व्यवहार, उपलब्धता, प्रबंधक की मंज़ूरी | यह खाता अभी इसे इस्तेमाल कर सकता है |
| संपर्क | संपर्क ID, स्वीकृत सहायता संपर्क रास्ता, दमन स्थिति | इस व्यक्ति को इस तरह का उत्तर भेजा जा सकता है |
अनुरोध मार्केटिंग सहमति नहीं है। उसी अनुरोध के तथ्यात्मक उत्तर के लिए स्वीकृत सहायता चैनल इस्तेमाल करें। मसौदा अन्य सुविधाओं का प्रचार करे, महँगा प्लान बेचे या उन लोगों को लक्षित करे जिन्होंने माँगा ही नहीं, तो उसे अपनी योग्यता शर्तों वाला अलग मार्केटिंग अभियान मानें। चुने चैनल की सदस्यता समाप्त और दमन स्थिति मानें। डबल ऑप्ट-इन मार्गदर्शक समझाता है कि टिकट सदस्यता रिकॉर्ड का विकल्प क्यों नहीं है।
सीमित प्रॉम्प्ट से एक उत्तर तैयार करें
एक काल्पनिक परिणाम T-104 को F-7 और R-22 से जोड़ता है, पर रोलआउट बंद मिलता है। रुकें; न भेजें।
स्वीकृत रिकॉर्ड देने के बाद यह प्रॉम्प्ट कॉपी करें:
केवल मेरे दिए अनुरोध, रिलीज़ और संपर्क रिकॉर्ड देखें। सिर्फ़ शब्दों की समानता से नहीं, स्थिर सुविधा ID और संपर्क ID से मिलाएँ। हर संभावित मेल के लिए टिकट ID, सुविधा ID, रिलीज़ ID, प्रबंधक की मंज़ूरी, खाते में उपलब्धता, स्वीकृत संचार उद्देश्य और दमन स्थिति दिखाएँ। गुम या टकराते प्रमाण को अवरुद्ध लिखें। केवल पुष्ट और उपलब्ध रिलीज़ के लिए छोटा तथ्यात्मक उत्तर लिखें। सिर्फ़ दिए तथ्यों से बताएँ क्या बदला, ग्राहक उसे कहाँ इस्तेमाल कर सकता है और मदद कहाँ मिलेगी। मार्केटिंग सहमति न मानें, प्रचार के दावे न जोड़ें, संपर्क न बनाएँ या बदलें, संदेश न भेजें और टिकट बंद न करें। प्रमाण तालिका और मसौदा यहीं समीक्षा के लिए लौटाएँ।
जाँच: उत्पाद प्रबंधक मसौदे की रिलीज़ रिकॉर्ड से तुलना करे और अनुरोधकर्ता के खाते में उपलब्धता जाँचे। सहायता प्रबंधक प्राप्तकर्ता की पहचान और संचार उद्देश्य जाँचे। कोई भी जाँच विफल हो तो मसौदा चैट में ही रखें। Grok Bot और Brevo आरंभिक मार्गदर्शक दस्तावेज़ में दर्ज MCP कनेक्शन और उपलब्ध क्रियाओं की जाँच क्यों आवश्यक है, समझाता है; यह विशेष वर्कफ़्लो किसी Grok Bot खाते में चलाया नहीं गया है।
एक बार भेजें, फिर रसीद दर्ज करें
मंज़ूर संदेश कतार में डालने से पहले feature_id + contact_id + release_id से डुप्लिकेट रोकने की कुंजी बनाएँ और उसे स्थायी लेखे में परमाणु रूप से आरक्षित करें। पहले से आरक्षित, लंबित, अज्ञात स्थिति वाली या सफल कुंजी दूसरी बार कतार में डालने से रोकती है। दो कर्मचारी अलग-अलग पढ़ने और फिर लिखने वाली जाँच पार न कर सकें। समयसीमा समाप्त होने पर दोबारा प्रयास सोचने से पहले घटना और प्रदाता रसीदें मिलाएँ; उत्तर न मिलना, डिलीवरी न होने का प्रमाण नहीं।
समीक्षा के बाद Brevo में स्वीकृत रास्ता सेट करें। Automations > Workflows > Create an automation में अगर खाते पर कस्टम घटना ट्रिगर और ईमेल क्रिया उपलब्ध हों, तो प्रस्तावित feature_followup_approved घटना को स्वीकृत सहायता-उद्देश्य टेम्पलेट से जोड़ें। घटना में सत्यापित संपर्क पहचान आवश्यक है; सुविधा और रिलीज़ ID आपके प्रस्तावित घटना गुण हैं, Brevo के डिफ़ॉल्ट नहीं। सक्रियण से पहले आंतरिक संपर्क से जाँच करें। मंज़ूरी और सफल कुंजी आरक्षण के बाद ही एक घटना भेजें। अन्यथा सहायता टीम का व्यक्ति हाथ से जवाब दे। Brevo कस्टम घटनाएँ और वर्कफ़्लो सेटअप दर्ज करता है; अपने खाते में उपलब्ध कार्य देखें। Grok Bot का मसौदा निष्पादन की अनुमति नहीं। Brevo API मार्गदर्शक अलग API रास्ता बताता है। घटना स्वीकार किए जाने का रिकॉर्ड, संदेश भेजने की रसीद से अलग रखें। घटना स्वीकार होना ईमेल भेजे जाने का प्रमाण नहीं। सही प्राप्तकर्ता, स्वीकृत पाठ, रिलीज़ प्रमाण, उद्देश्य, चैनल, प्रदाता भेजने की ID और समय दर्ज करें। पुष्ट भेजने की रसीद या दस्तावेज़ वाला हस्तचालित सहायता उत्तर मिलने के बाद ही टिकट को फ़ॉलो-अप पूरा चिह्नित करें। Brevo का MCP दस्तावेज़ संभावित कनेक्शन बताता है, यह नहीं कि आपके क्लाइंट में हर लिखने का कार्य या अनुमति उपलब्ध है।
हर रिलीज़ के लिए अवलोकन की अंतिम तारीख तय करें, जैसे प्रबंधक के उपलब्धता पुष्टि करने के सात दिन बाद। उस तारीख पर पूर्णता मापें: एक पुष्ट फ़ॉलो-अप वाले योग्य अनुरोधों को उस रिलीज़ के सभी योग्य अनुरोधों से भाग दें। अवरुद्ध और संपर्क न हो सकने वाले अनुरोध अलग गिनें। डिलीवरी स्थिति और ग्राहक उत्तर विफलताएँ पहचानने में मदद करते हैं; खुलना यह नहीं साबित करता कि ग्राहक ने सुविधा देखी या इस्तेमाल की। सत्यापित प्राप्तकर्ता बिना रिलीज़ अब भी लंबित काम है। अलग परिणाम मापने वाले अभियान प्रयोग में भी यही प्रमाण अनुशासन लागू होता है।
अक्सर पूछे जाने वाले प्रश्न
माँगी गई सुविधा पर ग्राहक को कब फ़ॉलो-अप भेजें?
तभी जब प्रबंधक रिलीज़ ID, उस ग्राहक के खाते में उपलब्धता और वास्तव में रिलीज़ हुआ व्यवहार सत्यापित करे। बंद टिकट, मिला हुआ कोड या मसौदा रिलीज़ नोट ग्राहक द्वारा उपयोग करने का प्रमाण नहीं।
क्या सहायता अनुरोध मार्केटिंग ईमेल की अनुमति देता है?
नहीं। उस ग्राहक के अनुरोध पर तथ्यात्मक उत्तर स्वीकृत सहायता संचार प्रक्रिया से दें। बड़े प्रचार अभियान को अपनी अनुमत दर्शक सूची और सदस्यता आधार चाहिए; टिकट यह नहीं बनाता।
क्या Grok Bot Brevo से रिलीज़ सूचना अपने आप भेज सकता है?
यह गाइड Grok Bot से प्रमाण मिलवाती और उत्तर का मसौदा बनवाती है। Brevo में हर लिखने या भेजने के लिए अलग सत्यापित कनेक्शन, अनुमति जाँच और मंज़ूरी चाहिए। दर्ज MCP अनुकूलता का यहाँ लाइव परीक्षण नहीं हुआ है।