Colay / मार्गदर्शिकाएँ
कई AI दृष्टिकोणों को ग्राहक प्रस्ताव में बदलें
सलाहकारों और एजेंसियों को एक प्रस्ताव की आवश्यकता होती है जो ग्राहक को अगले चरण के लिए सहमत होने में मदद करे। Colay में, आप व्यक्तिगत एजेंट प्रतिक्रियाएं एकत्र कर सकते हैं, Consensus में असहमति पर चर्चा कर सकते हैं और निष्कर्ष की HTML प्रस्तुति का अनुरोध कर सकते हैं। यह मार्गदर्शिका उस वर्कफ़्लो को ग्राहक का कार्य-विवरण, कार्यक्षेत्र सीमाओं और प्रतिबद्धताओं से जोड़ती है जिन्हें आप प्रमाणित कर सकते हैं।
तय करें कि प्रस्ताव को क्या हासिल करना है
प्रारंभिक बैठक के लिए एक प्रस्तुति अनुमोदन के लिए तैयार प्रस्ताव से एक अलग उद्देश्य पूरा करती है। पहला समस्या को स्पष्ट करने और खोज के लिए सहमत होने में मदद करता है। दूसरा दायरा, जिम्मेदारियां, कीमत और स्वीकृति की शर्तें निर्दिष्ट करता है। सौदे के चरण को संक्षेप में बताएं ताकि मसौदा सहमति से आगे न बढ़ जाए।
प्राप्तकर्ता का वर्णन करें, उनका निर्णय क्या है और वे पहले से क्या जानते हैं। हो सकता है कि कोई व्यवसाय स्वामी अगला कदम चुन रहा हो, जबकि संचालन प्रमुख यह जांच कर रहा हो कि कर्मचारी कार्यान्वयन में सहायता कर सकते हैं या नहीं। वह अंतर यह निर्धारित करता है कि कौन सी आपत्तियां ध्यान देने योग्य हैं और कौन सी स्लाइड पर हैं।
कार्य परिदृश्य: एक एजेंसी खोए हुए इनबाउंड अनुरोधों की समीक्षा करती है
कल्पना करें कि कोई ग्राहक किसी एजेंसी से नया सीआरएम लागू करने के लिए कह रहा है क्योंकि कुछ पूछताछ छूट रही है। स्रोत सामग्री में एक प्रक्रिया मानचित्र और छूटे हुए अनुरोधों के उदाहरण शामिल हैं। यह स्थापित नहीं करता है कि नुकसान स्टाफ हैंडऑफ़, डेटा प्रविष्टि या फॉलो-अप के दौरान होता है या नहीं। यह एक काल्पनिक वर्कफ़्लो है, कोई Colay ग्राहक कहानी नहीं।
एक प्रारंभिक प्रस्ताव सीधे कार्यान्वयन के लिए आगे बढ़ सकता है। समीक्षा से पता चल सकता है कि सिस्टम को बदलना अभी तक उचित नहीं है: अस्पष्ट स्वामित्व वास्तविक कारण हो सकता है। एक उपयोगी चर्चा परिणाम में प्रक्रिया का निरीक्षण करने, कारण का परीक्षण करने और फिर कार्यान्वयन के दायरे पर सहमति व्यक्त करने का प्रस्ताव होगा। सिस्टम प्रतिस्थापन का समर्थन करने वाले साक्ष्य एक अलग सिफारिश की ओर ले जाएंगे।
प्रस्तुति में उस तर्क को शामिल करें: क्या ज्ञात है, कौन सी अनिश्चितता पहले चरण में हल होती है और क्या अगले निर्णय का समर्थन करता है। नई प्रणाली का परिष्कृत विवरण उस संबंध को स्थापित नहीं करता है।
कार्य-विवरण की कई दृष्टिकोणों से समीक्षा करें
ये आपके संकेतों के लिए सुझाए गए कार्य हैं, प्रमाणित विशेषज्ञों का कोई अंतर्निहित पैनल नहीं। व्यक्तिगत आरंभिक प्रतिक्रियाओं के लिए Ask separately का उपयोग करें। वही कार्य-विवरण प्रदान करें और पहचानें कि ग्राहक के साक्ष्य कहाँ समाप्त होते हैं और आपकी धारणाएँ कहाँ से शुरू होती हैं।
साझा निष्कर्ष के लिए, कार्य-विवरण, प्रासंगिक अंश और समीक्षा नोट्स के साथ Consensus का उपयोग करें। इन्हें स्पष्ट रूप से प्रदान करें: अलग-अलग चैट स्वचालित रूप से नए अनुरोध के स्रोत नहीं बन जाते हैं। चर्चा को उन असहमतियों को संरक्षित करने के लिए कहें जिनका समाधान उपलब्ध साक्ष्य नहीं कर सकते।
- समाधान डिजाइनर: कार्य का कौन सा क्रम ग्राहक की समस्या का समाधान करता है।
- आलोचक: किन दावों के समर्थन में साक्ष्य नहीं हैं और किन निर्भरताओं का उल्लेख नहीं है।
- प्राप्तकर्ता का दृष्टिकोण: अनुमोदन से पहले क्या स्पष्टीकरण की आवश्यकता है।
- संपादक: समीक्षा किए गए निष्कर्षों को संक्षिप्त दस्तावेज़ में कैसे बदलें।
वादों को ऐसी शर्तों में बदलें जिनकी टीम पुष्टि कर सके
सिर्फ एक स्लाइड भरने के लिए अज्ञात को विश्वसनीय संख्याओं में न बदलें। जिम्मेदार टीम को अनुमानों, तारीखों और प्रतिबद्धताओं की पुष्टि करनी होगी। जब कोई मान अनसुलझा हो तो वर्किंग ड्राफ्ट में एक प्रश्न छोड़ दें; क्लाइंट संस्करण में, शर्त स्पष्ट रूप से बताएं या असमर्थित वादे को हटा दें।
| ड्राफ्ट स्टेटमेंट | क्या निर्दिष्ट करें |
|---|---|
| हम बिक्री बढ़ाएंगे | प्रक्रिया के दायरे में परिवर्तन और इसके परिणाम का मूल्यांकन कैसे किया जाएगा। |
| सभी एकीकरण शामिल | नामांकित सिस्टम, आवश्यक पहुंच और सहमत सीमाएँ। |
| सहमत तिथि तक डिलीवरी | दिनांक, निर्भरताएं और शर्तें जो शेड्यूल शुरू करती हैं। |
| समर्थन शामिल | समर्थन अवधि, कवर किया गया कार्य और स्वामित्व सीमाएँ। |
निष्कर्ष और प्रस्तुति के लिए प्रॉम्प्ट
“इस कार्य-विवरण [साक्ष्य] और समीक्षा नोट्स [अंश] के आधार पर [प्राप्तकर्ता] के लिए [प्रारंभिक बैठक या कार्य-दायरे के अनुमोदन] चरण का प्रस्ताव तैयार करें। तथ्यों को धारणाओं से अलग करें। जाँचें कि हर प्रस्तावित गतिविधि ग्राहक की समस्या का समाधान करती है। टीम का अनुभव, ग्राहकों की प्रशंसा, कीमतें, तारीखें या प्रदर्शन में सुधार गढ़ें नहीं। उन विवादित शर्तों को पहचानें जिनकी किसी व्यक्ति को पुष्टि करनी होगी। फिर इन विषयों पर HTML प्रस्तुति तैयार करें: ग्राहक की समस्या; स्थापित अवलोकन; विकल्प और सुझाया गया तरीका; कार्य-दायरा और उससे बाहर की बातें; निर्भरताएँ और स्वीकृति की शर्तें; अगला कदम।”
पहले मूल निष्कर्ष की समीक्षा करें। अंतिम प्रस्तुति कार्य से पहले दायरे या स्थिति में बदलाव का समाधान करें। Colay के डिफ़ॉल्ट Consensus अनुरोध में निष्कर्ष के आधार पर एक HTML प्रस्तुति शामिल है, लेकिन उत्पन्न परिणाम की समीक्षा करें: एक मॉडल किसी आवश्यकता को छोड़ सकता है या इसे खराब तरीके से प्रस्तुत कर सकता है।
एक संस्करण तैयार करें जिसे आप मीटिंग में उपयोग कर सकते हैं
प्रत्येक स्लाइड को प्राप्तकर्ता के दृष्टिकोण से पढ़ें। क्या मौखिक स्पष्टीकरण के बिना प्रस्ताव का कोई मतलब है? क्या दायरा स्पष्ट है? क्या संपीड़न ने एक महत्वपूर्ण शर्त को हटा दिया है? नाम, संख्या, लिंक और तालिका पठनीयता की जाँच करें। उन आंतरिक नोट्स को हटा दें जो क्लाइंट के लिए नहीं हैं।
आवश्यकता पड़ने पर समीक्षा की गई प्रस्तुति को निर्यात करें। Colay का वर्तमान PPTX निर्यात स्लाइड्स को छवियों के रूप में संरक्षित करता है; अलग-अलग लेबल संपादन योग्य PowerPoint टेक्स्ट ऑब्जेक्ट नहीं हैं। यदि आपको स्लाइड टेक्स्ट में बदलाव की आवश्यकता है, तो उन्हें निर्यात करने से पहले करें या अतिरिक्त संपादन की योजना बनाएं।
संशोधन में लगे समय और सहमति योग्य शर्तों की स्पष्टता के आधार पर वर्कफ़्लो का मूल्यांकन करें। यह परिदृश्य तैयारी के समय का कोई बेंचमार्क या बिक्री में सुधार साबित नहीं करता। क्रेडिट और बार-बार किए गए जनरेशन का हिसाब रखें। पहचान हटाकर दिए गए एक कार्य-विवरण और प्रस्ताव के ऐसे एक खंड से शुरुआत करें जिस पर टीम असहमत हो।
अपना अगला सवाल Colay में पूछें
एक मॉडल चुनें, Auto का उपयोग करें, या Consensus के साथ कई दृष्टिकोण एक साथ लाएं।