SPIN पद्धति: सही सवालों से ज़रूरत सामने लाएं।

Huthwaite ने यह पद्धति विकसित की और इसे Neil Rackham के काम से जोड़ा जाता है। इसमें ग्राहक के नज़रिए से ज़रूरत समझने की प्रक्रिया को व्यवस्थित किया गया है। इसके चार अक्षर बातचीत तैयार करने के लिए संकेत देते हैं। यह सवालों की सूची नहीं है जिसे एक-एक करके पूछना हो।

कॉल में SPIN से समाधान पेश करने को तब तक टाला जा सकता है, जब तक ज़रूरत स्पष्ट न हो। अगर ग्राहक कहता है, «हमारे काम की निगरानी करना मुश्किल है», तो अभी यह स्पष्ट नहीं है कि समस्या क्या है, किसे है या वे कौन-सा नतीजा चाहते हैं।

अगर संपर्क व्यक्ति इस विषय से जुड़ा नहीं है या बात नहीं करना चाहता, तो SPIN कॉल जारी रखने की वजह नहीं है। आगे बढ़ने से पहले विषय पर उनकी सहमति ज़रूरी है।

ये सवाल मौजूदा कामकाज के बारे में होते हैं। इनसे उपयोगी जानकारी मिलनी चाहिए, न कि ऐसी बात दोहरवानी चाहिए जिसे आप कॉल से पहले ही ढूंढ सकते थे। Situation वाले बहुत ज़्यादा सवाल पूछने से बातचीत पूछताछ जैसी लगती है।

काल्पनिक उदाहरण: एक प्रबंधक को कई चैनलों से कोटेशन के अनुरोध मिलते हैं। उपयोगी सवाल: «अनुरोध मिलने से लेकर उस पर काम करने वाले व्यक्ति तक, यह प्रक्रिया कैसे चलती है?» इससे प्रक्रिया सामने आती है।

फिर बात को अपने शब्दों में दोहराएं: «अगर मैंने सही समझा है, तो हर प्रबंधक अपने क्षेत्र के अनुरोधों को संभालता है।» गलती पर आगे बढ़ने से पहले ग्राहक उसे सुधार सकता है।

ये सवाल इस बारे में होते हैं कि क्या ठीक से काम नहीं कर रहा है। ग्राहक को यह कहने की गुंजाइश दें कि उन्हें कोई समस्या नहीं है। उन पर समस्या थोपने की ज़रूरत नहीं।

«किस स्थिति में किसी अनुरोध पर नज़र रखना मुश्किल हो जाता है?» ग्राहक को अपना अनुभव बताने की गुंजाइश देता है। «इस टूल की वजह से आपका बहुत समय बर्बाद होता होगा?» में निष्कर्ष पहले से मौजूद है।

अगर ग्राहक अनुपस्थिति के दौरान काम सौंपने में आने वाली दिक्कत की बात करे, तो हाल का कोई उदाहरण पूछें—लेकिन निजी जानकारी मांगने से बचें।

इनसे पता चलता है कि कोई परेशानी प्राथमिकता का विषय है या नहीं। इस मुश्किल से क्या होता है: देरी, काम दोबारा करना, फैसलों में खींचतान या जानकारी की कमी? नतीजे ग्राहक बताए, यह तय न करें कि उनका खर्च या आवृत्ति क्या है।

«जब किसी की अनुपस्थिति में अनुरोध की ज़िम्मेदारी किसी और को नहीं मिलती, तो टीम पर क्या असर पड़ता है?» प्रबंधक बता सकता है कि किसी सहकर्मी को पिछली जानकारी फिर से जुटानी पड़ती है। इससे पता चलता है कि कौन प्रभावित होता है।

बात को बढ़ा-चढ़ाकर न पेश करें। अगर ऐसा बहुत कम होता है और अच्छी तरह संभल जाता है, तो इसे दर्ज करें। ईमानदारी से ज़रूरत समझने पर यह नतीजा भी निकल सकता है कि कोई परियोजना नहीं है। इससे बिक्री का अनावश्यक सिलसिला बचता है।

ग्राहक बताता है कि समस्या सुलझने से क्या बदलेगा। बातचीत समस्या को समझने से इच्छित नतीजे तक पहुंचती है। अभी अपने उत्पाद या उसकी कीमत की स्वीकृति लेने की बात नहीं है।

«अगर काम संभालने वाले व्यक्ति को उपयोगी जानकारी तुरंत मिल जाए, तो आपके यहां क्या बदलेगा?» जवाब में बचने वाले समय की बजाय सेवा की निरंतरता की बात हो सकती है। आपका प्रस्ताव इसी प्राथमिकता के अनुसार होना चाहिए।

आखिर में पूछें कि वे सुधार को कैसे पहचानेंगे। कोई भी संख्यात्मक पैमाना उनके साथ मिलकर तय करें, अपने तर्क के लिए गढ़ें नहीं।

ऐसी स्थिति चुनें जिसमें आपका प्रस्ताव सचमुच मदद करता हो। हर सवाल-श्रेणी के लिए एक सवाल लिखें, फिर कॉल का अभ्यास करें—सभी सवाल पूछना ज़रूरी न बनाएं। हो सकता है ग्राहक समस्या पूछने से पहले ही उसका असर बता दे।

कॉल के बाद अपने सवालों को उनके उद्देश्य के अनुसार वर्गीकृत करें। दोहराए गए और दिशा देने वाले सवाल पहचानें। क्या आपका अंतिम प्रस्ताव ग्राहक के बताए किसी लाभ को दोहराता है? अगर नहीं, तो आपने बहुत जल्दी तर्क देना शुरू कर दिया। आपके कॉल रिपोर्ट का मूल्यांकन करने के लिए SPIN स्कोरिंग ग्रिड उपलब्ध है।

SPIN, खरीद प्रक्रिया की योग्यता-जाँच का विकल्प नहीं है। ज़रूरत स्पष्ट होने के बाद BANT या MEDDIC पूरक हो सकते हैं। पहली कॉल में कई पद्धतियों को एक साथ अपनाने की ज़रूरत नहीं है।

S, P, I, N को सख्त क्रम में पूछना। आसान होने के कारण Situation वाले बहुत सारे सवाल पूछना। कार्रवाई न करने की कीमत को बढ़ा-चढ़ाकर बताकर Implication को नाटकीय बनाना।

सुधार के लिए: सामान्य अंक के बजाय किसी खास अंश को दोबारा पढ़ें, दिशा बताने वाले सवाल की जगह ऐसा सवाल पूछें जिसके कई जवाब हो सकते हैं, ग्राहक को सोचने का समय दें और अपनी परिकल्पना के विरोध में उनका जवाब भी स्वीकार करें।