ग्राहक खोए बिना CRM माइग्रेशन: एक चेकलिस्ट

ज़्यादातर मालिक एक ही वजह से CRM माइग्रेशन टालते हैं: पुराने सिस्टम में हर ग्राहक, हर नोट और भविष्य की हर बुकिंग है, और इनमें से एक भी खोना उस सॉफ़्टवेयर के साथ जीने से ज़्यादा बुरा लगता है जो अब फ़िट नहीं बैठता। यह डर वाजिब है, लेकिन किसी CRM डेटा माइग्रेशन में ज़्यादातर गड़बड़ी कुछ अनुमान लगाने लायक जगहों पर होती है, और हर एक को किसी ग्राहक की कीमत चुकाने से पहले जाँचा जा सकता है। यह चेकलिस्ट बताती है कि बिना ग्राहक, इतिहास या बुकिंग खोए किसी दूसरे बिज़नेस सिस्टम में कैसे माइग्रेट करें, चाहे आप एक बुकिंग ऐप, एक सेल्स CRM या एक स्प्रेडशीट छोड़ रहे हों। स्टेप को क्रम में पूरा करें।

1. कुछ भी बदलने से पहले सब कुछ एक्सपोर्ट करें

किसी सब्सक्रिप्शन को कैंसिल करने, नया अकाउंट बनाने या एक पंक्ति भी साफ़ करने से पहले, जो आपके पास है उसकी पूरी कॉपी लें। एक्सपोर्ट किसी माइग्रेशन का वह हिस्सा है जिसे पुराना सिस्टम जाने के बाद दोबारा नहीं किया जा सकता। प्रति रिकॉर्ड टाइप एक फ़ाइल:

• ग्राहक, टूल जो भी कॉलम दे उन सब के साथ, उन्हें भी जिन्हें आपको लगता है ज़रूरत नहीं।
• अपॉइंटमेंट या जॉब, बीते और आने वाले, ग्राहक, वर्कर, सर्विस, शुरू होने का समय और अवधि के साथ।
• नोट्स और एक्टिविटी हिस्ट्री।
• ग्राहकों या जॉब से जुड़ी फ़ाइलें और फ़ोटो। कई टूल में बल्क फ़ाइल एक्सपोर्ट नहीं होता; मान लेने से पहले जाँच लें।
• PDF के तौर पर इनवॉइस और रसीदें।
• आपकी सर्विस और कीमतें, साथ ही वे सेटिंग जिन्हें याद रखना मुश्किल है: काम के घंटे, कैंसिलेशन नियम, इनटेक सवाल, मैसेज टेम्पलेट।

सितंबर 2026 तक, एक्सपोर्ट कहाँ है यह टूल पर निर्भर करता है। Google Sheets: File, फिर Download, फिर (.csv) वाला विकल्प, प्रति शीट एक बार। Excel: File, फिर Save As, टाइप “CSV UTF-8”। HubSpot: कॉन्टैक्ट टेबल मेनू में Export एक्शन। Pipedrive: Settings, फिर Export data। Zoho CRM: Setup, फिर Data Administration, फिर Export। Square Appointments और Fresha जैसे बुकिंग ऐप ग्राहक लिस्ट को कस्टमर डायरेक्टरी से एक्सपोर्ट करते हैं, और अपॉइंटमेंट हिस्ट्री अक्सर सिर्फ़ एक रिपोर्ट के तौर पर मिलती है, इसलिए इसे सबसे चौड़ी अनुमति वाली डेट रेंज पर चलाएँ।

जो भी इम्पोर्ट करना चाहते हैं उसके लिए CSV या XLSX माँगें, कभी PDF नहीं, और हर फ़ाइल की पंक्तियों को पुराने सिस्टम की स्क्रीन पर दिखने वाली गिनती से मिलाएँ। चुपचाप 1,000 पंक्तियों पर रुक गया एक्सपोर्ट एक आम जाल है, और कैंसिल करने के बाद की तुलना में अभी नोटिस करना कहीं आसान है।

2. तय करें कि क्या नहीं ले जाना है

न ले जाने के उचित उम्मीदवार:

• वे ग्राहक जिनके पास न कोई कॉन्टैक्ट डिटेल है, न कोई विज़िट, न कोई नोट। ये लोग नहीं, बस जगह घेरने वाले हैं।
• टेस्ट रिकॉर्ड, और वह “Walk-in” या “Unknown” ग्राहक जो किसी बुकिंग ऐप ने आप पर थोप दिया।
• एक या दो साल से पुरानी कैंसिल हुई बुकिंग, जब तक आप यह तय करने के लिए कैंसिलेशन हिस्ट्री का इस्तेमाल न करते हों कि डिपॉज़िट कौन देता है।
• वे फ़ील्ड जो कभी नहीं भरी गईं। एक “Referral source” कॉलम जो दस में से नौ पंक्तियों में खाली है, डेटा नहीं है।
• मार्केटिंग लिस्ट जिन्हें आप अब नहीं भेजते, ख़ासकर वे कॉन्टैक्ट जिन्होंने कभी मैसेज पाने की सहमति नहीं दी।

“माइग्रेट नहीं हुआ” का मतलब “डिलीट हो गया” नहीं है: जो भी आप छोड़ें वह स्टेप 1 के एक्सपोर्ट में अब भी जीवित है।

3. एक्सपोर्ट को स्प्रेडशीट में साफ़ करें

सफ़ाई किसी स्प्रेडशीट में करें, नए सिस्टम में नहीं। हर इम्पोर्ट टूल जो हमने इस्तेमाल किया है, अपना भी शामिल, एक साफ़-सुथरी फ़ाइल के साथ एक कच्चे डंप से बेहतर काम करता है। अगर आपका सोर्स पहले से ही एक स्प्रेडशीट है, तो यहीं ज़्यादातर काम होता है; स्प्रेडशीट से वर्कस्पेस तक पर हमारी गाइड लेआउट को गहराई से कवर करती है।

• प्रति टैब एक रिकॉर्ड टाइप: ग्राहक एक में, अपॉइंटमेंट दूसरे में, नोट्स तीसरे में। एक टैब जो एक ही पंक्ति में ग्राहक और उनकी बुकिंग को मिला देता है, किसी भी टूल से साफ़ इम्पोर्ट नहीं हो सकता।
• सादे नामों वाली एक हेडर पंक्ति, कोई मर्ज्ड सेल नहीं, उसके ऊपर कोई खाली पंक्ति नहीं। “Phone (mobile, for SMS!)” से बेहतर है “Phone”।
• पूरी फ़ाइल के लिए एक तारीख़ फॉर्मेट। ISO चुनें (2026-09-01): यह स्पष्ट है, सही सॉर्ट होता है, और हर इम्पोर्टर इसे पढ़ लेता है।
• एक फ़ोन फॉर्मेट, आदर्श रूप से देश कोड के साथ (+1 415 555 0134), “Tel:” उपसर्ग और “(home)” जैसे नोट अपने कॉलम में ले जाएँ।
• पुराने सिस्टम का ID कॉलम रखें। यह स्टेप 6 में ग्राहकों को अपॉइंटमेंट और नोट्स से जोड़ता है, भले आप इसे फिर कभी न दिखाएँ।

साफ़ की गई वर्कबुक को एक नए नाम से सेव करें और कच्चे एक्सपोर्ट को बिना छुए छोड़ दें।

4. हर फ़ील्ड को उसके नए घर से मैप करें

फ़ील्ड मैपिंग वह स्टेप है जिसे एक CRM माइग्रेशन चेकलिस्ट सबसे ज़्यादा छोड़ देती है, और यही वजह है कि “इम्पोर्ट काम कर गया लेकिन आधा डेटा ग़लत जगह है” इतनी आम शिकायत है। इम्पोर्ट करने से पहले, कॉलम-दर-कॉलम लिख लें कि हर फ़ील्ड कहाँ जाएगी। एक ऐसे सैलून के लिए जो एक बुकिंग ऐप छोड़ रहा है:

पुराना कॉलम	नई फ़ील्ड	नोट
Client name	ग्राहक: Full name	अगर नए सिस्टम में दो फ़ील्ड हों तो पहला और आख़िरी नाम बाँटें
Service booked	अपॉइंटमेंट: Service	पहले बनाई गई सर्विस लिस्ट से मेल खाना ज़रूरी
Staff	Appointment: Worker	नए सिस्टम में मौजूद किसी वर्कर से मेल खाना ज़रूरी
Start	Appointment: Start time	तारीख़ और समय साथ, एक टाइम ज़ोन
Client ID	ग्राहक: External ID	छिपी हुई फ़ील्ड, लिंकिंग के लिए इस्तेमाल होती है

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

5. डुप्लीकेट को इम्पोर्ट से पहले संभालें, बाद में नहीं

कुछ सालों तक इस्तेमाल हुए हर सिस्टम में डुप्लीकेट होते हैं। इम्पोर्ट के बाद मर्ज करना धीमा है, क्योंकि तब तक हर कॉपी के पीछे अपॉइंटमेंट और नोट्स लटके होते हैं; स्प्रेडशीट में मर्ज करना तेज़ है।

1. फ़ोन नंबर से क्लाइंट टैब सॉर्ट करें और मेल खाती सटी हुई पंक्तियों को ढूँढें। फ़ोन आमतौर पर सबसे भरोसेमंद कुंजी है।
2. ईमेल से सॉर्ट करके वही करें, फिर आख़िरी और पहले नाम से, ताकि अलग फ़ोन और बिना ईमेल वाले जोड़े भी पकड़ में आएँ।
3. हर जोड़े के लिए, ज़्यादा भरी पंक्ति रखें, कोई भी नोट्स उसमें कॉपी करें, और छोड़ी गई पंक्ति की पुरानी ID रखी हुई पंक्ति के बगल में लिख लें, ताकि जो अपॉइंटमेंट उसकी ओर इशारा करते थे वे अब भी लिंक हो सकें।
4. असली डुप्लीकेट को डिलीट करने की बजाय एक “Merge into” कॉलम में चिह्नित करें, ताकि फ़ैसला दिखता और पलटने लायक रहे।

कुछ इम्पोर्ट टूल अपनी खुद की डुप्लीकेट जाँच चलाते हैं। Ifa का इम्पोर्ट फ़ाइल का प्रीव्यू देता है और कुछ भी लिखे जाने से पहले संभावित डुप्लीकेट, खाली वैल्यू और न पढ़ी जाने वाली तारीख़ें फ्लैग करता है, और जाँच पढ़ने के बाद आप इम्पोर्ट मंज़ूर करते हैं। यह एक उपयोगी सुरक्षा जाल है, इस स्टेप का विकल्प नहीं: कोई टूल यह फ्लैग कर सकता है कि क्या मिलता-जुलता है, पर यह नहीं जान सकता कि “Chris Park” और “Christina Park” एक ही नियमित ग्राहक हैं।

6. सही क्रम में इम्पोर्ट करें

जो रिकॉर्ड दूसरे रिकॉर्ड का संदर्भ लेते हैं उन्हें उनके संदर्भित रिकॉर्ड के बाद आना चाहिए। क्रम ग़लत होना ऐसी अपॉइंटमेंट का सबसे आम कारण है जो बिना किसी ग्राहक के पहुँचती हैं।

1. वर्कर और स्टाफ़। अपॉइंटमेंट इनका संदर्भ लेंगी।
2. सर्विस या जॉब टाइप, अवधि और कीमतों के साथ।
3. ग्राहक, एक खास फ़ील्ड में पुरानी ID के साथ ताकि बाद की फ़ाइलें उन्हें ढूँढ सकें।
4. नोट्स और हिस्ट्री जो ग्राहकों का संदर्भ लेती है।
5. बीती अपॉइंटमेंट और जॉब, जो ऊपर की हर चीज़ का संदर्भ लेती हैं।
6. फ़ाइलें और दस्तावेज़, उस ग्राहक या जॉब से जुड़े जिनके वे हैं।

पहले बीस ग्राहकों और उनकी अपॉइंटमेंट का एक सैंपल इम्पोर्ट करें; बीस रिकॉर्ड ठीक करना दर्द रहित है। फिर पूरी फ़ाइल चलाएँ। Ifa का इम्पोर्ट, जो अपना डेटा इम्पोर्ट करें पेज पर बताया गया है, CSV, TSV, JSON, JSONL, XLSX, XLS और निष्क्रिय XLSM फ़ाइलें स्वीकार करता है, जाँच के साथ एक प्रीव्यू दिखाता है, और रिकॉर्ड बनने से पहले आपकी मंज़ूरी का इंतज़ार करता है। ज़्यादातर बुकिंग ऐप अपॉइंटमेंट हिस्ट्री के लिए कोई इम्पोर्ट ही नहीं देते।

फ़ाइलों पर एक बात। Ifa अपलोड की गई फ़ाइलों को उनके रिकॉर्ड से जुड़ा रखता है, एक प्रीव्यू के साथ, जैसा कस्टमर फ़ाइल पेज पर बताया गया है। Ifa खुद इनवॉइस नहीं बनाता, इसलिए स्टेप 1 वाले PDF ही इनवॉइस हैं; उन्हें ग्राहक से जोड़ें या अपने अकाउंटिंग टूल में रखें, पर उन्हें सिर्फ़ पुराने सिस्टम में मत छोड़ें।

7. काम के घंटे सेट करें, फिर भविष्य की बुकिंग दोबारा बनाएँ

भविष्य की बुकिंग को अपना स्टेप मिलता है क्योंकि यह किसी माइग्रेशन का वह हिस्सा है जिसे ग्राहक असल में नोटिस करते हैं।

1. हर वर्कर के लिए काम के घंटे सेट करें, तय छुट्टियों सहित, और बुकिंग पॉलिसी सेट करें: बफर, न्यूनतम नोटिस, कैंसिलेशन विंडो।
2. तभी भविष्य की बुकिंग लोड करें या दोबारा बनाएँ। घंटे मौजूद होने से पहले लोड की गई बुकिंग रिजेक्ट हो जाती हैं या ऐसे स्लॉट में गिर जाती हैं जिनके लिए कोई स्टाफ़ नहीं।
3. अगले आठ हफ्तों के लिए पुराना कैलेंडर प्रिंट करें और हर बुकिंग को नई बुकिंग के मुक़ाबले हाथ से टिक करें। ज़्यादातर दुकानों के लिए इसमें कुछ घंटे लगते हैं और यह पूरे माइग्रेशन की सबसे कीमती जाँच है।
4. टाइमज़ोन शिफ़्ट पर नज़र रखें। UTC में एक एक्सपोर्ट जो लोकल टाइम के तौर पर इम्पोर्ट हो जाए, हर अपॉइंटमेंट को कई घंटे इधर-उधर कर देता है, और सिर्फ़ तारीख़ दिखाने वाली स्क्रीन इसे उजागर नहीं करेगी।

अगर भविष्य की बुकिंग कम हैं, तो उन्हें हाथ से दोबारा बनाना अक्सर इम्पोर्ट करने से तेज़ और सुरक्षित होता है। Ifa में, बुकिंग आपकी टीम वर्कस्पेस के अंदर बनाती, दोबारा शेड्यूल करती, कैंसिल करती और पूरी करती है, आपने सेट किए घंटों के हिसाब से उपलब्धता जाँची जाती है, और ग्राहक Ifa के बनाए बुकिंग पेज से या किसी जुड़े हुए चैनल पर चैट में बुक कर सकते हैं। Ifa में Google या Outlook कैलेंडर सिंक नहीं है, और रिमाइंडर किसी स्विच की बजाय एक वर्कफ़्लो है जो आप खुद तय करते हैं, इसलिए पहले हफ्ते में ही रिमाइंडर वर्कफ़्लो सेट कर लें और कटओवर के हिस्से के तौर पर अपनी साइट के बुकिंग लिंक को नए पेज पर ले जाएँ।

8. थोड़े समय के लिए दोनों सिस्टम चलाएँ

शुक्रवार को स्विच करके शनिवार को पुराना सब्सक्रिप्शन कैंसिल न करें। दोनों को एक से दो हफ्ते तक चलने दें, नए को सच के स्रोत के तौर पर और पुराने को रीड-ओनली के तौर पर।

• हर नई बुकिंग और हर नया ग्राहक सिर्फ़ नए सिस्टम में जाए। दोनों में लिखना काम दोगुना करता है और गड़बड़ी की गारंटी देता है।
• पुराना सिस्टम लुकअप के लिए खुला रहे: एक नोट जिसे आप माइग्रेट करना भूल गए, एक फ़ोटो, एक पुराना इनवॉइस।
• आख़िर में, पुराने सिस्टम में ग़लती से बने किसी भी रिकॉर्ड के लिए एक आख़िरी एक्सपोर्ट लें, और उसे नए में जोड़ दें।

Ifa में कोई लाइव दो-तरफ़ा सिंक नहीं है, और हम दो-हफ्ते के ओवरलैप के लिए किसी भी वेंडर के सिंक की सिफ़ारिश नहीं करेंगे; “सिर्फ़ नया सिस्टम” ही सरल नियम है।

9. ग्राहकों को बताएँ कि क्या बदलता है

किसी माइग्रेशन का ज़्यादातर हिस्सा ग्राहकों को दिखना नहीं चाहिए, और ऐसा ही रहना चाहिए। उन्हें सिर्फ़ वही बताएँ जो उनके लिए बदलता है, और होने से पहले बताएँ।

• अगर बुकिंग लिंक, फ़ोन नंबर या मैसेजिंग चैनल बदल रहा है, तो नया एक हफ्ते पहले भेजें और उसी दिन फिर से।
• अगर रिमाइंडर रुक जाएँगे या किसी और भेजने वाले से आएँगे, तो बता दें और उनसे नया नंबर सेव करने को कहें।
• अगर आपके पास सहमति रिकॉर्ड हैं, तो सबूत ग्राहक की फ़ाइल के साथ रखें, हर किसी से दोबारा सहमति माँगने की बजाय।

इसे छोटा रखें: “15 सितंबर से हम अपॉइंटमेंट के लिए एक नया सिस्टम इस्तेमाल कर रहे हैं। आपकी मौजूदा बुकिंग वैसी ही रहेंगी। बुक करने के लिए, हमेशा की तरह उसी नंबर पर कॉल या मैसेज करें।”

10. पुराने एक्सपोर्ट को एक फ़ाइल के तौर पर रखें

जब ओवरलैप ख़त्म हो जाए और सब्सक्रिप्शन कैंसिल हो जाए, एक्सपोर्ट डिलीट न करें। स्टेप 1 की कच्ची फ़ाइलें, स्टेप 3 की साफ़ की गई वर्कबुक, स्टेप 4 की मैपिंग टेबल और स्टेप 8 का आख़िरी ओवरलैप एक्सपोर्ट, इन सबको एक फ़ोल्डर में रखें, उसे तारीख़ के साथ नाम दें, और उसे कहीं ऐसी जगह रखें जो लैपटॉप ख़राब होने पर भी बची रहे। आप इसे उम्मीद से ज़्यादा इस्तेमाल करेंगे। एक आर्काइव की कोई कीमत नहीं है। एक को दोबारा बनाना नामुमकिन है।

क्या गलत होता है और इसे कैसे रोकें

गड़बड़	यह कैसी दिखती है	रोकथाम
अधूरा एक्सपोर्ट	स्क्रीन पर पंक्तियों की गिनती फ़ाइल से ज़्यादा है	साफ़ करने से पहले पंक्तियाँ गिनें; सपोर्ट से पूरा एक्सपोर्ट माँगें
मिले-जुले तारीख़ फॉर्मेट	अपॉइंटमेंट ग़लत दिन या महीने में जा गिरती हैं	इम्पोर्ट से पहले पूरी फ़ाइल में एक ही ISO फॉर्मेट
टाइमज़ोन शिफ़्ट	हर अपॉइंटमेंट एक जैसे कई घंटों से इधर-उधर है	एक सैंपल बुकिंग इम्पोर्ट करें और घड़ी का समय मिलाएँ
अनाथ अपॉइंटमेंट	बिना किसी ग्राहक से जुड़ी बुकिंग	पहले पुरानी ID के साथ ग्राहक, फिर अपॉइंटमेंट
मर्ज्ड डुप्लीकेट इतिहास खो देते हैं	दो ग्राहक एक बनते ही नोट्स ग़ायब हो जाते हैं	स्प्रेडशीट में “Merge into” कॉलम के साथ मर्ज करें
बुकिंग के बाद घंटे सेट करना	भविष्य की बुकिंग रिजेक्ट होती हैं या बिना स्टाफ़ वाले स्लॉट में जाती हैं	पहले काम के घंटे और पॉलिसी, फिर बुकिंग

स्कोप को लेकर ईमानदार रहें। अगर आप कई सालों की हिस्ट्री और एक बड़े फ़ोटो आर्काइव वाले कई हज़ार ग्राहकों को ले जा रहे हैं, तो स्टेप वही रहते हैं पर समय का अंदाज़ा नहीं; स्प्रेडशीट सफ़ाई के लिए एक फ्रीलांसर पैसे के लायक है। Ifa कोई पेड माइग्रेशन सर्विस नहीं देता, इसलिए Ifa के साथ यह काम आपका या किसी कॉन्ट्रैक्टर का है, इम्पोर्ट के प्रीव्यू और जाँच के सहारे। कुछ और वेंडर ऊँचे टियर पर सहायता वाला माइग्रेशन देते हैं; अगर आपका डेटा बड़ा है तो कमिट करने से पहले पूछ लें।

लोग जो सवाल पूछते हैं

एक मालिक-संचालित टीम के लिए CRM माइग्रेशन में कितना समय लगता है?

दो-कुर्सी वाले सैलून, चार लोगों की सफ़ाई क्रू या कुछ सौ ग्राहकों वाले एक अकेले कंसल्टेंट के लिए, एक्सपोर्ट और सफ़ाई में एक दोपहर लगती है, इम्पोर्ट और बुकिंग जाँच में एक और, और ओवरलैप बैकग्राउंड में एक से दो हफ्ते चलता है। बड़ी हिस्ट्री सफ़ाई स्टेप के साथ बढ़ती है, इम्पोर्ट के साथ नहीं।

क्या मुझे साल के किसी शांत समय पर CRM बदलना चाहिए?

हाँ, अगर आपके पास कोई शांत समय है। कम भविष्य की बुकिंग का मतलब है स्टेप 7 में एक छोटी जाँच, और कम वॉक-इन ओवरलैप को पुलिस करना आसान बनाते हैं।

क्या मैं अपॉइंटमेंट हिस्ट्री माइग्रेट कर सकता हूँ, या सिर्फ़ ग्राहक?

यह इस पर निर्भर करता है कि पुराना टूल क्या एक्सपोर्ट करता है। ज़्यादातर सेल्स CRM एक्टिविटी पूरी तरह एक्सपोर्ट करते हैं। कई बुकिंग ऐप ग्राहक लिस्ट आसानी से एक्सपोर्ट करते हैं पर हिस्ट्री सिर्फ़ एक रिपोर्ट के तौर पर दिखाते हैं। अगर हिस्ट्री साफ़-साफ़ एक्सपोर्ट न हो, तो कम से कम एक “Last visit” और “Visit count” कॉलम के साथ ग्राहक माइग्रेट करें ताकि नए सिस्टम को पता हो कि आपके नियमित ग्राहक कौन हैं, और पुरानी रिपोर्ट को आर्काइव के तौर पर रखें।

क्या CRM बदलने के बाद मुझे ग्राहकों से दोबारा सहमति माँगनी होगी?

आमतौर पर नहीं, अगर सहमति कानूनी तरीके से ली गई थी और उसका रिकॉर्ड ग्राहक के साथ चलता है। मायने यह रखता है कि आप अब भी दिखा सकें किसने, किस बात के लिए, और कब सहमति दी। सहमति फ़ील्ड और उसकी तारीख़ को साथ लाएँ, और मूल एक्सपोर्ट को सबूत के तौर पर रखें। अगर पुराने टूल ने कभी सहमति दर्ज ही नहीं की, तो इसे माइग्रेशन की वजह से हुई कमी की बजाय नए सिस्टम में ठीक करने लायक कमी मानें।

अंतिम बार अपडेट किया गया: 2 सितंबर, 2026।