अधूरी RFQ को मूल्यांकन के लिए तैयार कैसे करें

अधूरी RFQ में पहले अनुरोध का reference, उत्पाद, specification की revision, मात्रा और जवाब की समय-सीमा जाँचें। फिर गायब जानकारी को तकनीकी तथा व्यावसायिक प्रश्नों में बाँटें और हर प्रश्न का मालिक लिखें। मूल्यांकन तभी आगे बढ़े जब उसकी जरूरी शर्तें स्पष्ट हों; बाकी मामलों में अनुमानित quote के बजाय सीमित clarification भेजें।

एक RFQ का संदर्भ और संस्करण पहले पकड़ें

किसी email का subject «urgent quotation» होना उसकी पूरी पहचान नहीं है। देखें अनुरोध किस व्यवसायिक बातचीत से आया, भेजने वाले ने कौन सा reference दिया और attachments किस उत्पाद के लिए हैं। मूल email, attachment का नाम और उपलब्ध revision साथ रखें। कोई reference न दिया हो तो अपनी टीम का आंतरिक case reference बनाएँ और उसे ग्राहक का RFQ नंबर बताकर इस्तेमाल न करें।

यदि एक ही thread में बाद में नया drawing आया है, तो दोनों files पर सिर्फ «latest» लिखना पर्याप्त नहीं होगा। दर्ज करें कि कौन सी file किस समय मिली और क्या सामने वाले ने पुरानी file को बदलने को कहा। दूसरे उत्पाद का चित्र उसी thread में हो सकता है। जब संबंध स्पष्ट न हो, तो तकनीकी मूल्यांकन शुरू करने से पहले सही item और revision की पुष्टि माँगें।

जवाब की अंतिम तारीख अलग field में रखें। timezone और portal submission का समय स्पष्ट न हो तो उन्हें प्रश्न बनाएं। टीम की भीतरी review तारीख ग्राहक की घोषित समय-सीमा नहीं है। यदि जरूरी जानकारी मिलने से पहले समय खत्म होने वाला है, तो account owner तय करे कि clarification, समय का अनुरोध या भाग न लेने का उत्तर देना है। अधूरी जानकारी को चुपचाप मान्य करके समय बचाना उचित विकल्प नहीं है।

हर item के लिए जरूरी और उपलब्ध जानकारी मिलाएँ

RFQ को केवल पूरे document के स्तर पर complete या incomplete न कहें। हर item के लिए requested product, grade या model, unit, quantity, required operation, delivery location और उपलब्ध specification लिखें। इनमें से क्या जरूरी है, यह आपके उत्पाद तथा मूल्यांकन पर निर्भर होगा। buyer ने जो बताया है और sales team ने जो अनुमान लगाया है, उनके लिए अलग field रखें। अनुमान technical brief का हिस्सा बनकर आगे नहीं जाना चाहिए।

किसी part के drawing में material न दिखे तो उस कमी का असर समझाएँ: क्या उसकी वजह से process, costing या feasibility तय नहीं हो सकती? केवल «material missing» लिखने से sales rep को यह नहीं पता चलेगा कि अगला सवाल क्यों जरूरी है। दूसरी ओर billing contact का नाम बाद में मिल सकता हो तो उसे उसी urgency पर न रखें। blocking और बाद में पूरा किए जा सकने वाले inputs अलग करें।

मात्रा में unit भी जरूरी है। «एक lot» या «monthly requirement» के साथ वास्तविक scope अस्पष्ट हो सकता है। इस अस्पष्टता को अपनी सुविधा से pieces में न बदलें। पूछें कि संख्या प्रति item है, sample batch है या समय के भीतर अपेक्षित कुल जरूरत। buyer ने सालाना संभावना बताई हो तो उसे firm order की quantity न मानें। यह distinction बाद की production और commercial review दोनों के लिए उपयोगी है।

तकनीकी प्रश्न और commercial प्रश्न अलग मालिकों को दें

तकनीकी queue में product specification, interface, tolerance, operating condition और उपलब्ध drawing से संबंधित प्रश्न आएँगे। engineering reviewer बताए कि कौन सी कमी मूल्यांकन रोकती है और किस प्रश्न का साफ उत्तर चाहिए। बिक्री व्यक्ति केवल form भरने के लिए अनिश्चित parameter निश्चित न करे। यदि कोई तकनीकी शब्द समझ में नहीं आता, तो उसका original wording सुरक्षित रखें और सही specialist से अर्थ की पुष्टि कराएँ।

Commercial queue में quoted scope, quantity basis, delivery destination, requested schedule, payment discussion और submission process जैसे विषय आ सकते हैं। इसका अर्थ यह नहीं कि इन सब पर sales rep अकेले निर्णय ले सकता है। हर विषय के लिए उस टीम की जिम्मेदारी लिखें जो उत्तर approve करेगी। तकनीकी feasibility मिल जाने पर भी price, dispatch commitment या contractual term स्वतः मंजूर नहीं हो जाते।

कई प्रश्न दोनों queues को जोड़ेंगे। उदाहरण के लिए finish बदलने से process और लागत दोनों प्रभावित हो सकते हैं। ऐसे मामले में एक primary owner रखें, dependent reviewer अलग लिखें और तय करें कि buyer को consolidated उत्तर कौन देगा। engineering और sales से अलग-अलग विरोधी जवाब जाने से बचें। ग्राहक को आपकी आंतरिक routing समझाने की जरूरत नहीं; उसे स्पष्ट प्रश्न और एक जिम्मेदार business contact मिलना चाहिए।

काल्पनिक ट्रायेज कार्ड में आगे बढ़ने और रुकने का फर्क

यह पूरा मामला काल्पनिक है। «उदाहरण buyer अ» एक machined bracket की RFQ भेजता है। drawing की revision मौजूद है, quantity pieces में दी गई है, लेकिन surface finish और delivery destination नहीं बताए गए। technical reviewer finish को feasibility तथा cost के लिए blocking input मानता है। logistics reviewer destination के बिना dispatch scope रोकता है। card पर दोनों प्रश्न, संबंधित मालिक और मूल्यांकन की सीमित स्थिति दर्ज होगी।

काल्पनिक card का सार होगा: RFQ reference उपलब्ध, item bracket, drawing revision दर्ज, quantity का आधार स्पष्ट, finish लंबित, destination लंबित, स्थिति clarification needed। यह कोई वास्तविक खरीद, प्रमाणित specification या मूल्य का उदाहरण नहीं है। टीम buyer को एक साथ सिर्फ वे प्रश्न लौटाएगी जिनके उत्तर के बिना मूल्यांकन नहीं चल सकता। बाकी optional जानकारी को अलग रखा जाएगा, ताकि जरूरी clarification अनावश्यक questionnaire में न दबे।

दूसरा काल्पनिक मामला standard catalogue item का है, जिसका model और quantity स्पष्ट हैं। buyer केवल अपनी supplier-registration प्रक्रिया की जानकारी बाद में देने वाला है। यदि आपकी approved internal प्रक्रिया इसकी अनुमति देती है, तो technical evaluation शुरू हो सकता है, जबकि onboarding अलग pending रहे। card पर «technical review ready, commercial submission pending» जैसी स्पष्ट सीमा लिखें। इससे एक काम की पूर्णता को दूसरे काम की approval नहीं बनाया जाता।

Clarification ऐसा भेजें जिसका उत्तर देना संभव हो

Clarification में मूल reference और संबंधित item बताकर पूछें कि कौन सा input चाहिए और क्यों। उदाहरण के लिए «Finish स्पष्ट होने पर process और मूल्यांकन आगे बढ़ेगा; कृपया अपेक्षित finish या लागू specification बताएं»। इससे ग्राहक को प्रश्न की वजह समझ आती है। अपने सवाल में ही मनचाहा उत्तर न भरें। कोई विकल्प उदाहरण के रूप में दिखाना जरूरी हो तो साफ कहें कि वह आपकी ओर से पुष्टि नहीं है।

सवाल उस क्रम में रखें जिसमें उत्तर अगले निर्णय को खोलते हैं। model ही अस्पष्ट है तो लंबी payment discussion पहले शुरू करने की जरूरत नहीं है। buyer ने कुछ शर्तें जानबूझकर खुली छोड़ी हों तो पूछें कि क्या alternative proposal स्वीकार है। उत्तर मिलने से पहले अपनी पसंद का substitute देकर मूल RFQ compliant घोषित न करें। विकल्प की समीक्षा और मूल अनुरोध का मूल्यांकन card पर अलग branch में रहें।

Buyer के उत्तर को केवल «clarified» में समेटने के बजाय संबंधित field से जोड़ें। कौन सी revision बदली, किसने मात्रा का आधार बताया और कौन सा प्रश्न अभी अनुत्तरित है, यह दिखना चाहिए। यदि उत्तर नई अस्पष्टता पैदा करे तो card उसी अनुसार फिर खुले। एक बार clarification email भेज देना RFQ को complete नहीं करता; मूल्यांकन मालिक को देखना होगा कि उसकी blocking जरूरत सच में पूरी हुई है या नहीं।

पूर्णता की स्थिति और जिम्मेदार स्वीकृति दर्ज करें

एक छोटा triage card में case reference, item, original source, आवश्यक input, उपलब्ध value, missing question, असर, owner और review decision आएँ। इसे lead scoring का विकल्प न बनाएं। «अच्छी lead» कह देने से specification पूरी नहीं होगी। card का निर्णय केवल यह बताए कि कौन सा मूल्यांकन अभी किया जा सकता है, कौन सा नहीं और उसे शुरू करने का जिम्मेदार व्यक्ति कौन है।

स्थितियाँ अपनी टीम के लिए परिभाषित करें: received का अर्थ केवल प्राप्ति, clarification needed का अर्थ दर्ज blocker, review ready का अर्थ संबंधित reviewer ने inputs स्वीकार किए। Declined या no-bid का कारण भी अलग रखें। ये संगठन की कामकाजी स्थितियाँ हैं, सभी RFQ या portals का सार्वभौमिक नियम नहीं। किसी automated system में वही labels हों, यह अनुमान भी न लगाएँ; वास्तविक workflow के साथ पहले मिलाएँ।

Owner बदलने पर केवल नाम बदलना पर्याप्त नहीं है। नए व्यक्ति से खुले प्रश्न और पुराने promises स्वीकार करवाएँ। buyer को जवाब देने की सहमत तारीख हो तो वह card में रहे। तारीख पूरी न हो सके तो उसकी जानकारी देने वाला भी तय हो। LDM से B2B replies और handover पर चर्चा करते समय यही card उपयोगी संदर्भ बनेगा; इसमें किसी automatic RFQ parser, engineering approval या quotation feature की उपलब्धता का दावा नहीं है।

संदर्भ और quote से पहले की अंतिम जाँच

UNGM की glossary RFQ को goods या services के लिए quotation माँगने के solicitation तरीके के रूप में समझाती है। उसका संदर्भ UN procurement है, सभी भारतीय निजी खरीदारों का नियम नहीं। यहाँ बनाई गई checklist आपकी internal evaluation की कार्य-पद्धति है। वास्तविक RFQ की definitions, instructions और authorized clarification को प्राथमिकता दें; किसी अन्य portal की सामान्य भाषा से उन शर्तों को प्रतिस्थापित न करें।

Quote तैयार करने से पहले reviewer यह देखे कि item और revision पहचाने गए हैं, blockers का उत्तर दर्ज है और कोई अनकहा assumption अंतिम commitment नहीं बना। जो सीमा बाकी है उसे buyer-facing उत्तर में उपयुक्त ढंग से दिखाएँ। price माँगे जाने को order, budget approval या आपकी offer acceptance न समझें। इस लेख का पूरा किया हुआ परिणाम मूल्यांकन-योग्य card है, कोई हासिल बिक्री या निश्चित conversion नहीं।

आधिकारिक संदर्भ, जाँच तारीख 2026-10-18: United Nations Global Marketplace, The UNGM Glossary — https://www.ungm.org/Shared/KnowledgeCenter/Pages/UNGMglossary । इसका उपयोग RFQ के सीमित अर्थ के लिए किया गया है। उदाहरण के cases, internal labels और प्रश्नों की routing लेखक की सिफारिशें हैं; कोई वास्तविक RFQ, निजी दस्तावेज या buyer account इस लेख में जाँचा नहीं गया है।

अक्सर पूछे जाने वाले सवाल