CRM के साथ डिलीवरी का इंटीग्रेशन: कौन-सा डेटा जाता है और एक्सचेंज कैसे सेट करें

जब CRM और डिलीवरी अलग-अलग रहते हैं, तो क्या टूटता है

CRM ग्राहक के साथ रिश्ते सँभालता है: वहाँ सौदे, संपर्क, समय और भुगतान की सहमतियाँ दर्ज होती हैं। डिलीवरी मैनेजमेंट सिस्टम काम पूरा कराने के लिए है: कौन जाएगा, किस क्रम में, और काम पूरा होने का प्रमाण क्या होगा। जब तक ये दोनों घेरे जुड़े नहीं होते, बीच में एक इंसान खड़ा रहता है जो डेटा हाथ से एक जगह से दूसरी जगह ले जाता है — और इस मेहनत की क़ीमत सिर्फ़ बीते हुए समय से कहीं ज़्यादा होती है।

इस दरार के आम नतीजे कुछ ऐसे दिखते हैं:

• दोहरी एंट्री और टाइपिंग की ग़लतियाँ। दूसरी बार टाइप किया गया पता वह पता है जिसमें ग़लती की पूरी गुंजाइश है। कर्मचारी ग़लत जगह पहुँच जाता है, और मामला मौक़े पर ही सुलझाना पड़ता है।
• स्टेटस का पिछड़ना। मैनेजर को दिखता ही नहीं कि ऑर्डर के साथ क्या हो रहा है, इसलिए वह ग्राहक को साफ़ जवाब देने के बजाय «अभी पता करके बताता हूँ» कहता है। हर बार का यह «पता करना» डिस्पैचर को एक फ़ोन कॉल है।
• खो जाने वाले ऑर्डर। सौदा «डिलीवरी को सौंपा गया» स्टेज पर चला गया, पर डिस्पैचर तक पहुँचा ही नहीं: किसी ने ध्यान नहीं दिया, जब तक ग्राहक ने फ़ोन नहीं किया।
• न मिलने वाली रिपोर्टिंग। CRM में डिलीवरी की संख्या कुछ और है, ऑपरेशनल सिस्टम में कुछ और, और यह अंतर सिर्फ़ वही कर्मचारी समझा पाता है जिसे ब्योरे अच्छे से याद रहते हैं।

इंटीग्रेशन इस मैन्युअल परत को हटा देता है: ऑर्डर डिस्पैचर के पास उसी क्षण दिख जाता है जब सौदा ज़रूरी स्टेज पर पहुँचता है, और काम का नतीजा बिना किसी के दोहराए ग्राहक के कार्ड में लौट आता है। बाक़ी सब — नोटिफ़िकेशन, एनालिटिक्स, इंटरफ़ेस की सुविधा — इसी बुनियादी एक्सचेंज के ऊपर की मंज़िल है। इसीलिए इंटीग्रेशन का डिज़ाइन «कौन-से तथ्य किस दिशा में जाने चाहिए» सवाल से शुरू करना चाहिए, न कि «कौन-सा बटन दबाना है» से।

CRM और डिलीवरी सिस्टम के बीच कौन-सा डेटा चलता है

एक्सचेंज लगभग हमेशा दोतरफ़ा होता है, और इसे दो छोटी सूचियों में लिखना फ़ायदेमंद है — CRM से क्या जाता है और वापस क्या आता है। CRM से डिलीवरी सिस्टम में आम तौर पर भेजा जाता है:

• ऑर्डर या आवेदन: नंबर, काम का प्रकार, सामग्री, मैनेजर की टिप्पणी;
• काम की जगह का पता, प्रवेश से जुड़े ब्योरों के साथ — गेट, मंज़िल, पास, मौक़े पर किसे फ़ोन करना है;
• प्राप्तकर्ता के संपर्क और तय किया गया समय-अंतराल;
• राशि और भुगतान का तरीक़ा, अगर कर्मचारी मौक़े पर पैसे लेता है;
• तात्कालिकता या प्राथमिकता का संकेत — ताकि डिस्पैचर को दिखे कि इसे कल पर नहीं टाला जा सकता।

वापसी में, डिलीवरी सिस्टम से CRM में काम पूरा होने के तथ्य लौटते हैं:

• नियुक्त किया गया कर्मचारी और पहुँचने का अनुमानित समय;
• स्टेटस: काम में लिया गया, निकल पड़ा, जगह पर है, पूरा हुआ, पूरा नहीं हुआ;
• पूरा न होने का कारण, एक तय सूची में से — इनकार, फ़ोन नहीं उठा, पता नहीं मिला, ग्राहक के कहने पर टाला गया;
• प्रमाण: फ़ोटो रिपोर्ट, प्राप्तकर्ता के हस्ताक्षर, निशान लगाने का समय और जगह;
• मौक़े पर लिया गया भुगतान, अगर उसे कर्मचारी ने इकट्ठा किया था।

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

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

एक्सचेंज के तरीक़े: API, वेबहुक और फ़ाइल अपलोड

तकनीकी रूप से सिस्टम कई रास्तों से जोड़े जा सकते हैं। चुनाव फ़ैशन से नहीं होता, बल्कि इससे कि डेटा कितनी जल्दी चाहिए और आपके CRM में कौन-सी सुविधाएँ हैं।

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

कोई एक सार्वभौमिक जवाब नहीं है, पर एक सीधा पैमाना है। अगर ग्राहक उसी दिन स्टेटस चाहता है और मैनेजर «मेरा ऑर्डर कहाँ है» वाले फ़ोन उठाता है, तो घटना-आधारित एक्सचेंज चाहिए। अगर प्रवाह एक दिन पहले बन जाता है और स्थिर रहता है, तो फ़ाइल अपलोड काफ़ी है, और उसे जटिल बनाना तभी ठीक है जब कोई ठोस काम सामने आए जिसे वह हल न कर पा रही हो।

itlogist AmoCRM, Bitrix24, 1С और Excel के साथ इंटीग्रेशन सपोर्ट करता है — ऑर्डर आपके जाने-पहचाने स्रोत से सीधे काम में आ जाते हैं, बिना हाथ से दोबारा टाइप किए। इसके आगे ऑर्डर के साथ क्या होता है — कर्मचारियों में बँटवारा, नक़्शे पर लाइव रूट, फ़ोटो रिपोर्ट और चेकलिस्ट वाला कर्मचारी का मोबाइल ऐप, स्टेटस दिखाने वाला ग्राहक का पर्सनल अकाउंट — यह सब itlogist की क्षमताएँ पेज पर इकट्ठा है।

सच्चाई का स्रोत, मिलान की कुंजी और ग़लतियों का प्रबंधन

इंटीग्रेशन की ज़्यादातर दिक़्क़तें तकनीकी नहीं, सहमति की होती हैं। नीचे चार सवाल हैं, जिनके जवाब तय करते हैं कि एक्सचेंज रोज़ की निगरानी के बिना चलेगा या नहीं।

• मिलान की कुंजी। डिलीवरी का ऑर्डर CRM के सौदे से किस फ़ील्ड पर मिलाया जाएगा — सौदे का नंबर, अंदरूनी आइडेंटिफ़ायर, या ऑर्डर नंबर। कुंजी एक ही होनी चाहिए, अपरिवर्तित, और दोनों दिशाओं में भेजी जानी चाहिए। फ़ोन या पते से मिलान उसी ग्राहक के दोबारा ऑर्डर करने पर बिखर जाता है।
• हर फ़ील्ड के लिए सच्चाई का स्रोत। पते का मालिक कौन है, डिलीवरी के समय का कौन, राशि का कौन। अगर मैनेजर ने CRM में समय-अंतराल बदला और डिस्पैचर ने डिलीवरी सिस्टम में, तो जीत उसकी नहीं होनी चाहिए जिसने बाद में क्लिक किया, बल्कि उसकी जिसे नियम में तय किया गया है।
• एक ही स्टेटस मॉडल। CRM की फ़नल स्टेज और काम पूरा होने के स्टेटस अलग-अलग चीज़ें हैं। मिलान की साफ़ तालिका चाहिए: कौन-सा ऑपरेशनल स्टेटस सौदे को किस स्टेज पर ले जाता है और कौन-से बदलाव मना हैं। वरना हर दोबारा डिलीवरी की कोशिश पर सौदा पीछे लुढ़कने लगेगा।
• ग़लती होने पर व्यवहार। अगर पता ख़ाली है, ग्राहक नहीं मिला या पाने वाला सिस्टम जवाब नहीं देता, तो क्या होगा। काम करने वाला परिदृश्य यह है: ऑर्डर चुपचाप गुम न हो, बल्कि दोबारा कोशिश की क़तार में या हाथ से देखने वाली सूची में चला जाए, और उस सूची का कोई ज़िम्मेदार हो।

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

लागू करने का क्रम: एक परिदृश्य से पूरे प्रवाह तक

इंटीग्रेशन को एक साथ पूरी चौड़ाई में शुरू नहीं करना चाहिए। काम करने वाला क्रम कुछ ऐसा दिखता है और आम तौर पर कुछ छोटे चरणों में पूरा हो जाता है।

• एक परिदृश्य को पूरा लिखें। सबसे ज़्यादा चलने वाला ऑर्डर प्रकार लें और उसे CRM की स्टेज से लेकर पूरा होने के निशान तक चलाकर देखें। ग़ैर-मामूली मामले — वापसी, आंशिक इनकार, दोबारा विज़िट — दूसरे चरण में जोड़ें।
• फ़ील्ड का नक़्शा तय करें। वही चार कॉलम वाली तालिका। जब तक दोनों पक्ष उस पर सहमत न हों, सेटअप शुरू करना जल्दबाज़ी है।
• डेटा में व्यवस्था लाएँ। साफ़-सुथरे पते, चालू फ़ोन नंबर, प्रवेश से जुड़ी टिप्पणियाँ। इंटीग्रेशन कचरे की रफ़्तार भी बढ़ा देता है: ख़राब पता बस और जल्दी कर्मचारी तक पहुँच जाएगा।
• टेस्ट प्रवाह पर जाँचें। दोनों दिशाओं में दस-बारह ऑर्डर, जिनमें जान-बूझकर ग़लत भी हों: बिना पते के, डुप्लीकेट के साथ, नियुक्ति के बाद रद्द होने वाले।
• हाथ से डेटा ले जाना बंद करें। जैसे ही एक्सचेंज चल पड़े, पुराना तरीक़ा रोक देना चाहिए। दो समानांतर व्यवस्थाओं का अंत हमेशा डेटा के फ़र्क़ और इस बहस में होता है कि सही कौन-सी है।
• सपोर्ट पर सहमति बनाएँ। ग़लतियों की क़तार कौन देखता है, कितनी जल्दी प्रतिक्रिया देता है, और किसी एक सिस्टम के बंद होने पर क्या करता है।

नतीजा परखने में कुछ आसान संकेतक मदद करते हैं, जिन्हें पहले और बाद में दर्ज किया जाए: सौदे के ज़रूरी स्टेज पर पहुँचने से लेकर डिस्पैचर के पास ऑर्डर दिखने तक कितना समय लगता है, कितने ऑर्डर हाथ से बनाए जाते हैं, मैनेजर कितनी बार स्टेटस पूछने के लिए डिस्पैच रूम में फ़ोन करते हैं। आख़िरी संकेतक आम तौर पर सबसे पहले बदलता है — उसी से दिखता है कि जानकारी अब लोगों के ज़रिए नहीं, सिस्टम के ज़रिए चलने लगी है।

यहाँ शुरू करने की दहलीज़ आम धारणा से नीची है: शुरुआत में 7 दिन लगते हैं, लंबी अवधि के अनुबंध के बिना, और प्लेटफ़ॉर्म 5 से 100 कर्मचारियों वाली टीमों के लिए बना है। यानी CRM वाले जोड़ को असली ऑर्डर प्रवाह पर परखा जा सकता है और एक महीने में ही दर्ज किए गए आधार से तुलना की जा सकती है।