भारतीय SDR से सेल्स को हैंडओवर के लिए एक पेज का लीड नोट

SDR का handover note कंपनी और contact के परिचय से आगे जाए: ग्राहक ने क्या कहा, क्या वादा किया गया, कौन सा प्रश्न खुला है और अगली meeting में क्या करना है, यह एक पेज में जोड़ें। Note भेजने को ownership transfer न मानें। Receiving sales owner से scope तथा अगला action स्वीकार करवाएँ और pending facts साफ रखें।

एक पेज का अर्थ निर्णय योग्य सार है, पूरी history नहीं

Handover का पहला reader वह colleague है जिसे अगला काम करना है। उसे account का नाम देखकर भरोसा करने के बजाय current conversation समझनी चाहिए। Note में relevant company/site, known contact role और specific topic दें। Source messages तक approved reference रहे, लेकिन पूरा inbox paste न करें। Unrelated personal remarks हटाएँ। सार इतना हो कि buyer को वही शुरुआती कहानी दोबारा बताने की जरूरत न पड़े।

एक पेज की सीमा author की practical recommendation है, कोई universal sales standard नहीं। किसी complex मामले में essential context अधिक हो तो summary के साथ authorised source references दें। Text छोटा करने के लिए uncertainty न काटें। «Need confirmed» लिखने से पहले customer ने कौन सा काम बताया है, उसका छोटा accurate statement होना चाहिए। आपकी interpretation अलग label में रहे, customer quotation बनकर नहीं।

इस note का output data capture मात्र नहीं, accepted responsibility transfer है। इसलिए incoming owner, outgoing SDR और acceptance status अलग fields रखें। भेज दिया, पढ़ा गया और अगला action स्वीकार हुआ—ये अलग घटनाएँ हैं। Tool notification आए तो भी colleague ने scope समझ लिया, ऐसा अनुमान न लगाएँ। Actual acknowledgement या आपकी approved team process का equivalent evidence चाहिए।

ग्राहक की बात और sales interpretation अलग रखें

Customer statement के लिए आवश्यक original wording या सटीक summary दें। उसकी तारीख तथा thread reference साथ हों। उसने operational problem बताई हो तो वही scope रखें; measurable financial loss उसने नहीं बताया तो invented amount न जोड़ें। Contact ने colleague से बात कराने को कहा हो तो उसे personal endorsement या खरीद अधिकार की पुष्टि न बनाएं। Receiving owner को वही certainty मिलनी चाहिए जो original source देता है।

Interpretation में लिख सकते हैं कि आपकी team उस statement को अपने offer से कैसे जोड़ रही है। इसे hypothesis ही रखें जब तक buyer ने संबंध नहीं बताया। किसी website announcement से निकला context और actual reply अलग sources हैं। Public source useful हो सकता है, मगर वह बातचीत की missing जरूरत नहीं भरता। Note में source type दिखने से next owner उपयुक्त प्रश्न चुन सकेगा।

Unknowns का छोटा meaningful हिस्सा रखें। हर blank field बराबर urgent नहीं। कौन सा missing fact अगला meeting goal बदलता है और कौन बाद में लिया जा सकता है, बताएं। SDR अपनी समझ से technical requirement तय न करे। Reviewer की जरूरत हो तो उसका role लिखें। Handover quality का प्रमाण ज्यादा fields नहीं, सही boundaries तथा next decision की स्पष्टता है।

Promises और अगली meeting की तैयारी जोड़ें

पहले seller के दिए promises सूची के बजाय साफ छोटे paragraphs में पकड़ें। किसने कौन सी approved document summary देने को कहा, कब तक और किस channel में, यह स्पष्ट हो। Internal target date को buyer commitment न बनाएं। कोई अस्वीकृत capability message में चली गई है तो उसे छिपाने के बजाय appropriate owner तक correction task पहुँचाएँ। Handover पुराने promise को अपने आप valid नहीं बनाता।

Meeting booked हो तो उसका confirmed date/time reference, participants की relevant roles और limited goal लिखें। Calendar invite मौजूद होने से technical evaluation approved नहीं होती। अगली call केवल missing scope समझने के लिए हो सकती है। Needed materials, pending access और उन सवालों को अलग रखें जिनका उत्तर sales अकेले नहीं दे सकता। Application specialist चाहिए तो उसका actual involvement तय हो।

Contact restrictions भी operational context हैं। Buyer ने किसी विषय को pause किया है तो note में उसका actual scope रहे। New owner के आते ही पुरानी routine sequence फिर शुरू हो जाए, ऐसा न हो। यह लेख automated pause या sync सुविधा का दावा नहीं करता। Outgoing SDR और receiver अपने actual queues, drafts तथा tasks में relevant limits बनाए रखने का तरीका confirm करें।

काल्पनिक note में handover acceptance दिखाएँ

यह पूरा example काल्पनिक है। «उदाहरण account अ» item क की installation जानकारी पर चर्चा कर रहा है। Contact ने कहा कि उसे अपने technical colleague के लिए public overview चाहिए। SDR ने वही overview तैयार करने का promise किया है; compatibility, budget और order पर कोई फैसला नहीं हुआ। One-page note में source statement, promised overview, open installation scope और next-call goal लिखा जाएगा।

कल्पित receiving owner note पढ़कर कहता है: «मैं overview का approved version देखकर agreed channel पर follow-up संभालूँगा; technical suitability pending रखेंगे।» Acceptance entry में role, acknowledgement reference और next action आएँगे। यह वास्तविक customer, acknowledgement या सफल sale नहीं है। Filled note का पूरा परिणाम जिम्मेदारी स्वीकार होना है, merely transferred lead label नहीं। Actual technical approval भविष्य के अलग evidence पर निर्भर रहेगा।

दूसरा काल्पनिक stop case है: SDR note भेजता है लेकिन receiving owner उपलब्ध नहीं और कोई backup स्वीकार नहीं करता। Case unowned transferred के रूप में बंद नहीं होगा। Current team का responsible manager continuity owner तय करेगा। Buyer को दिए due task की जिम्मेदारी तब तक स्पष्ट रहे। Email भेजने या assignment field बदलने को accepted handover लिखना इसी स्थिति में गलत होगा।

स्वीकृति में scope लौटाकर स्पष्ट कराएँ

Receiver से केवल «received» लेना जरूरी action की समझ नहीं बताता। अपनी approved process के अनुसार उसे next task और pending limit दोहराने का मौका दें। अगर वह technical demo समझ रहा है जबकि buyer ने केवल scope call स्वीकार की है, तो meeting से पहले अंतर सुलझे। Handover acceptance का उपयोग colleague को फँसाने के बजाय shared understanding बनाने के लिए करें।

Receiver कोई missing prerequisite बताए तो उसे specific action दें। Source link खुल नहीं रहा, role unconfirmed है या promised attachment approved नहीं—इनका remedy अलग होगा। SDR सभी objections को rejected lead code में न डाल दे। कभी note correction के बाद transfer संभव है। Ownership unresolved रहते हुए routine work किसके पास रहेगा, यह भी स्पष्ट हो; ग्राहक के सामने दो teams की competing promises न जाएँ।

Customer context अनावश्यक लोगों तक न फैले। Note summary और restricted original records के access scope अलग रखें। नई team को relevant material देना और पूरे customer history की unlimited copy बनाना एक action नहीं। आपका actual tool permission model क्या अनुमति देता है, authorised owner तय करेगा। Handshake की speed के लिए confidentiality या existing contact instructions को silently छोटा न करें।

Transfer बंद करें और change का रास्ता खुला रखें

Final note में acknowledged owner, next action, current promises, unresolved facts और source references complete हों। SDR का काम तब बंद दिखे जब approved process के अनुसार continuity सच में स्थापित है। बाद में buyer scope बदले तो नया owner note के updated version का reference रखे। Original evidence को बदलकर ऐसा न दिखाएँ कि नई आवश्यकता शुरुआत से ज्ञात थी। Handover record बातचीत का इतिहास नहीं मिटाता।

LDM से SDR-to-sales workflow पर चर्चा में यह accepted one-page note उपयोगी context है। Automatic qualification, guaranteed owner acceptance या CRM-to-calendar sync की सुविधा उपलब्ध न मानें। Real implementation अलग verify होगी। इस लेख की उपयोगिता accountability और exact next task है; कोई meeting rate, saved hours या achieved sales outcome मापा नहीं गया है। Unknown commercial conditions accepted note में भी unknown रहेंगी।

आधिकारिक संदर्भ, जाँच तारीख 2026-10-18: Microsoft Learn, Opportunity tables — https://learn.microsoft.com/en-us/dynamics365/sales/developer/opportunity-entities । Publicly readable text opportunity के साथ activities तथा account/contact संबंध का सीमित product context बताता है; page पर authorization banner भी था। यह LDM feature या mandatory handover standard नहीं। One-page note, acceptance process और सभी cases लेखक की recommendations तथा स्पष्ट काल्पनिक examples हैं।

व्यवहार में इसे मुफ़्त इनबॉक्स प्लेसमेंट टेस्ट (check.live-direct-marketing.online) से जांचा जा सकता है।

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