बहुतेक CRM चॅटबॉट्स हे महागड्या कॅल्क्युलेटरपेक्षा जास्त काही नसतात. पाइपलाइन व्हॅल्यूबद्दल (pipeline value) विचारले की, ते थेट रिपोर्टमधून घेतलेला आकडा देतात. तो आकडा का बदलला हे विचारले की, संभाषण तिथेच थांबते. कच्चा डेटा (raw data) आणि खरी समज यातील हीच तफावत आहे जिथे व्यवहार (deals) गमावले जातात आणि महसूल (revenue) नकळत निसटतो.
खरी ऑपरेशनल व्हॅल्यू संदर्भातून (context) येते. क्लोज रेट्स (close rates) का बदलले, ही ट्रेंड सुरू राहिल्यास काय होईल आणि कोणत्या अपस्ट्रीम बदलामुळे ही हालचाल झाली, हे तुम्हाला माहित असणे आवश्यक आहे. Zoho CRM चॅटबॉटमध्ये अशा प्रकारचे इंटेलिजन्स निर्माण करणे हे कोणतेही विज्ञान कथा (science fiction) नाही. त्यासाठी एक स्वच्छ डेटा पाइपलाइन, एक शिस्तबद्ध सिमेंटिक लेअर (semantic layer) आणि कारणांचा शोध घेणारी आर्किटेक्चरची रचना आवश्यक आहे.
खरी समस्या डेटाची नाही, तर संदर्भाची आहे
सेल्स टीम्स आधीच डॅशबोर्ड्समध्ये बुडालेल्या आहेत. प्रत्येक CRM डझनभर बार चार्ट्स आणि फनेल व्ह्यूज तयार करते. मात्र, केवळ एक आकडा ही केवळ माहिती (trivia) असते. क्लोज रेट्समध्ये १५ टक्क्यांची घट म्हणजे काहीतरी घडले आहे हे समजते. पण, SDR टीमने त्यांच्या क्वालिफिकेशन स्क्रिप्टमध्ये बदल केला आहे का, एखाद्या पेड ट्रॅफिक सोर्सने अचानक अनक्वालिफाईड व्हिजिटर्स पाठवले आहेत का, किंवा एखाद्या स्पर्धकाने महिन्याच्या पहिल्या तारखेला आक्रमक किंमत (pricing) लावली आहे का, याबद्दल ते काहीही सांगत नाही.
एक स्मार्ट सिस्टम प्रश्नामागचा प्रश्न सोडवते. ती CRM ला केवळ एक स्थिर डेटाबेस न मानता एक जिवंत सिग्नल स्ट्रीम मानते. योग्यरित्या तयार केल्यास, चॅटबॉट एक विश्लेषणात्मक भागीदार (analytical partner) बनतो जो विसंगती (anomalies) शोधतो, मूळ कारणांचा शोध घेतो आणि डेटाबेसच्या ओळींऐवजी बिझनेस आउटकम्समध्ये (business outcomes) बोलतो.
Zoho च्या API सोबत संघर्ष करणे थांबवा
काहीही विश्लेषण करण्यापूर्वी, तुम्हाला डेटा स्वच्छपणे Zoho मधून बाहेर काढावा लागेल. प्रत्येक स्टँडर्ड आणि कस्टम ऑब्जेक्टसाठी कस्टम सिंक स्क्रिप्ट लिहिण्याची ओढ रोखा. Zoho चे API पेजिनेशन (pagination), रेट लिमिट्स (rate limits) आणि OAuth टोकन मॅनेजमेंट लागू करते. तुमच्या CRM मधील प्रत्येक लहान स्कीमा बदल (schema change) मेंटेनन्सचे डोकेदुखी ठरते, ज्यामुळे इंजिनिअरिंगचे तास प्रत्यक्ष प्रॉडक्टच्या कामाऐवजी या कामात वाया जातात.
त्याऐवजी Airbyte वापरा. त्यामध्ये Zoho CRM कनेक्टर आहे जो तुमच्यासाठी कठीण कामे हाताळतो. ते मॉडिफाइड टाइमस्टॅम्प्सचा (modified timestamps) वापर करून इनक्रिमेंटली सिंक करते, ज्यामुळे तुम्हाला दर तासाला संपूर्ण टेबल्स खेचण्याची गरज पडत नाही. ते स्कीमा आपोआप नॉर्मलाईज (normalize) करते, जे Lead_Source_Detail किंवा Qualification_Score सारखे कस्टम फील्ड्स जोडताच महत्त्वाचे ठरते. जेव्हा ही फील्ड्स बदलतात, तेव्हा Airbyte तुम्हाला एक्सट्रॅक्शन लॉजिक पुन्हा लिहिण्यास भाग पाडत नाही. ते डेटा थेट Postgres, Snowflake किंवा BigQuery मध्ये पोहोचवते, ज्यामुळे रात्री २ वाजता बिघडणाऱ्या कमकुवत इंटरमीडिएट फाईल ड्रॉप्सची गरज उरत नाही.
ही विश्वासार्हता महत्त्वाची आहे कारण तुमच्या स्टॅकचे पुढील लेयर्स डेटाच्या ताजेपणावर (freshness) अवलंबून असतात. जर तुमच्या डेटा इनजेशनमध्ये रेकॉर्ड्स सुटले किंवा रो (rows) डुप्लिकेट झाले, तर तुमचे अनॉमली डिटेक्शन चुकीचे संकेत देईल आणि तुमचे कॉझल अनालिसिस (causal analysis) चुकीच्या गोष्टींकडे निर्देश करेल.
सहा लेयर्स, एक स्पष्ट आवाज
तुमचे आर्किटेक्चर लेअर्ड ठेवा जेणेकरून प्रत्येक घटक आपले काम उत्तम प्रकारे करू शकेल. वेगळेपणामुळे सिस्टम डीबग करणे सोपे होते, विस्तार करणे स्वस्त होते आणि जेव्हा सेल्स लीडरशिप विचारते की बॉटने उत्तरापर्यंत कसे पोहोचले, तेव्हा ते अधिक विश्वासार्ह ठरते.
1. Data Ingestion
Airbyte एका शेड्यूलवर Leads, Deals, Contacts आणि Activities खेचते. या चार ऑब्जेक्ट्समध्ये बहुतेक सेल्स ऑपरेशन्सचा जीव असतो. एक्सट्रॅक्शन सोपे आणि प्रेडिक्टेबल ठेवा.
2. Data Warehouse
प्रथम कच्चा डेटा स्टेजिंग एरियामध्ये लोड करा. विश्लेषकांना किंवा अल्गोरिदमला थेट Zoho च्या प्रोडक्शन API वर क्वेरी करू देऊ नका. स्टेजिंग लेअर तुम्हाला स्कीमा बदलल्यावर रिकव्हरी पॉईंट देते आणि तुमच्या CRM वर ताण न आणता इतिहास पुन्हा प्रोसेस करण्याची परवानगी देते.
3. Semantic Layer
येथे तुम्ही बिझनेस टर्म्सचा (business terms) नेमका अर्थ परिभाषित करता. "Won deal" म्हणजे Closed Won स्टेज असलेली, १०० टक्के संभाव्यता (probability) असलेली आणि गेल्या ९० दिवसांत क्लोज झालेली कोणतीही संधी असू शकते. "Stalled lead" म्हणजे १४ दिवसांपासून कोणतीही नोंदवलेली ॲक्टिव्हिटी नाही असा अर्थ असू शकतो. जेव्हा चॅटबॉट नंतर रिजनल मॅनेजरला सांगतो की स्टॉल झालेल्या लीड्समध्ये वाढ झाली आहे, तेव्हा त्याने नेमकी तीच व्याख्या वापरली पाहिजे जी त्रैमासिक बोर्ड रिपोर्टमध्ये दिसते. या लेअरशिवाय, तुम्हाला त्या क्लासिक संकोचाचा सामना करावा लागेल जिथे डॅशबोर्ड ४२ क्लोज झालेल्या डील्स दाखवतो आणि बॉट ३८ असल्याचे सांगतो.
4. Anomaly Detection
स्पष्ट आऊटलायर्स (outliers) पकडण्यासाठी सांख्यिकीय मॉडेल्स चालवा, जसे की रविवारी डील्स तयार होण्याचे प्रमाण शून्यावर येणे (जेव्हा सामान्यतः ॲक्टिव्हिटी असते), किंवा एखाद्या मोठ्या एंटरप्राइझ संधीमुळे पाइपलाइन व्हॅल्यूमध्ये अचानक वाढ होणे. सूक्ष्म बदलांसाठी (subtle drift) हलके ML वापरा, जसे की महिनाभरात दर आठवड्याला क्लोज रेट्स दोन टक्क्यांनी कमी होणे. तुम्हाला दोन्ही दृष्टीकोनांची गरज आहे. एक साधन आगीला पकडते; तर दुसरे धूर पकडते.
5. Causal Analysis
ही लेयर "का" या प्रश्नाचे उत्तर देते. मेट्रिक डिपेंडन्सी ग्राफ (metric dependency graph) तयार करा. महसूल (Revenue) हा क्लोज रेट (close rate) आणि पाइपलाइन व्हॉल्यूमवर (pipeline volume) अवलंबून असतो. क्लोज रेट हा लीड क्वालिटी (lead quality) आणि प्रतिनिधीच्या कामगिरीवर (rep performance) अवलंबून असतो. लीड क्वालिटी ही ट्रॅफिक चॅनेल (traffic channel) आणि क्वालिफिकेशन निकषांवर (qualification criteria) अवलंबून असते. जेव्हा एखादे डाउनस्ट्रीम मेट्रिक (downstream metric) अयशस्वी होते, तेव्हा सिस्टम ग्राफच्या माध्यमातून अपस्ट्रीम (upstream) दिशेने तपास करते. ती सहसंबंधाची तीव्रता (correlation strength) आणि वेळेच्या जवळीकीनुसार संभाव्य कारणांना क्रमवारी देते. अशा प्रकारे बॉट केवळ समस्या सांगण्यापासून ते त्यामागचे मुख्य कारण शोधण्यापर्यंत प्रवास करतो.
6. Chat Interface
निष्कर्ष Retrieval-Augmented Generation (RAG) सह LLM द्वारे सादर करा. महत्त्वाचा तपशील म्हणजे LLM ने तुमच्या सिमेंटिक लेयरला (semantic layer) क्वेरी करावी, कधीही रॉ वेअरहाऊस टेबल्सना (raw warehouse tables) नाही. रॉ टेबल्स फॉरेन की (foreign keys) आणि युनिक्स टाइमस्टॅम्प्समध्ये (Unix timestamps) बोलतात. सिमेंटिक लेयर व्यवसायाच्या भाषेत बोलतो. RAG मॉडेलला तुमच्या प्रत्यक्ष व्याख्येवर आधारित ठेवते, ज्यामुळे हॅलुसिनेशन्स (hallucinations) कमी होतात आणि सुसंगतता वाढते.
मेट्रिक ग्राफ सर्व काही का बदलतो
केवळ एक नोटिफिकेशन आणि एक इनसाइट (insight) मधील फरक विचारात घ्या. एक बेसिक डॅशबोर्ड अलर्ट पाठवतो: "या आठवड्यात क्लोज रेट १५ टक्क्यांनी कमी झाला आहे." ही केवळ एक हेडलाईन आहे, निदान नाही. एक स्मार्ट सिस्टम म्हणते: "चॅनेल X कडून येणाऱ्या लीड क्वालिटीमध्ये मंगळवारी घट झाल्यामुळे क्लोज रेट कमी झाला आहे." हे दुसरे वाक्य सेल्स मॅनेजरला त्वरित कृती करण्यासाठी मार्ग देते. तिमाही खराब होण्यापूर्वी ती जाहिरातीवरील खर्च थांबवू शकते, लँडिंग पेजवरील फॉर्ममध्ये काही त्रुटी आहे का ते तपासू शकते किंवा SDR कव्हरेज पुन्हा नियुक्त करू शकते.
हे तयार करण्यासाठी वर वर्णन केलेल्या कारणात्मक ग्राफची (causal graph) आवश्यकता आहे. जेव्हा डाउनस्ट्रीम नोड—क्लोज रेट—त्याच्या अपेक्षित मर्यादेबाहेर जातो, तेव्हा सिस्टम त्याच्या पेरेंट नोड्सचे (parents) मूल्यमापन करते. ती लीड स्कोअर, चॅनेल मिक्स, अलीकडील किंमतीतील बदल आणि प्रतिनिधींच्या नेमणुका तपासते. ती केवळ अंदाज लावत नाही; ती व्यवसायाची प्रत्यक्ष कार्यपद्धती दर्शवणारी रचना तपासते.
प्रोडक्शनमध्ये अचूकता मिळवणे
केवळ आर्किटेक्चर तुम्हाला गोंधळात टाकणारे अलर्ट किंवा अविश्वसनीय उत्तरांपासून वाचवू शकणार नाही. अंमलबजावणी महत्त्वाची आहे.
लहान सुरुवात करा. व्यवसाय आधीच लक्ष ठेवून असलेले तीन किंवा चार मुख्य मेट्रिक्स निवडा. पाइपलाइन निर्मिती (Pipeline created), सरासरी डील साईज (average deal size), क्लोज रेट आणि सेल्स सायकलची लांबी (sales cycle length) हा एक चांगला सुरुवातीचा संच आहे. वेबसाइट बाऊन्स रेट, ईमेल ओपन रेट किंवा सोशल सेंटिमेंट यांसारख्या गोष्टींचा समावेश करण्यापूर्वी हे मेट्रिक्स अचूक करा. खूप जास्त अलर्ट्स गोंधळ निर्माण करतात आणि या गोंधळामुळे लोक सिस्टमकडे दुर्लक्ष करायला शिकतात.
मानवी ज्ञान आणि गणित यांचा मेळ घाला. तुमच्या सेल्स ऑपरेशन्स टीमला कारणात्मक ग्राफची पहिली आवृत्ती तयार करू द्या. त्यांना अनुभवातून माहित असते की जेव्हा लीड स्कोअर कमी होतात, तेव्हा त्याचे कारण अनेकदा एखादी विशिष्ट मोहीम किंवा क्वालिफिकेशन स्क्रिप्टमधील अलीकडील बदल असते. सांख्यिकीय सहसंबंध (Statistical correlation) त्या लिंक्सची पुष्टी करू शकतो किंवा त्यांना आव्हान देऊ शकतो, परंतु शून्य परिस्थितीत ते स्वतःहून शोधून काढत नाहीत. सेल्स ऑर्गनायझेशनमधील कार्यकारणभाव (Cause and effect) डोमेनच्या बारकाव्यांनी भरलेला असतो. त्याचा आदर करा.
सर्व गोष्टींचे ऑडिट करा. चॅटबॉटचे प्रत्येक उत्तर, ते तयार करण्यासाठी वापरलेली नेमकी सिमेंटिक व्याख्या, SQL फ्रॅगमेंट किंवा मेट्रिक व्हर्जनसह लॉग करा. जेव्हा एखादा प्रतिनिधी विचारतो की बॉटने एखाद्या खात्याला 'हाय रिस्क' का म्हणून चिन्हांकित केले, तेव्हा त्यामागचे तर्क स्पष्ट करा. सेल्स टीममधील विश्वास हीच खरी संपत्ती आहे. जर वापरकर्त्यांना संशय आला की बॉट केवळ अंदाज लावत आहे, तर ते पुन्हा त्यांच्या अंतर्ज्ञानावर आणि स्प्रेडशीट शोधण्यावर अवलंबून राहतील.
मुख्य निष्कर्ष
केवळ CRM फील्ड्स वापरकर्त्यांना परत सांगणारी 'लुकअप टूल्स' बनवणे थांबवा. त्या पलीकडे जाण्यासाठी आवश्यक तंत्रज्ञान—Airbyte द्वारे स्ट्रीमिंग इनजेशन, एक नियंत्रित सिमेंटिक लेयर, सांख्यिकीय आणि कारणात्मक मॉडेल्स, आणि प्रत्यक्ष व्यावसायिक तर्कावर आधारित LLM—सध्या उपलब्ध आहे. कठीण भाग मॉडेलची रचना करणे नाही. तर तुमचे मेट्रिक्स अचूकपणे परिभाषित करणे, तुमच्या कारणांची अपस्ट्रीम रचना करणे आणि केवळ हुशार दिसण्यासाठी सिस्टमला गोंधळ निर्माण करू न देणे, ही शिस्त पाळणे कठीण आहे. उत्तरांसाठी सिस्टम तयार करा, आणि मगच चॅटबॉट सेल्स मीटिंगमध्ये आपले स्थान मिळवू शकेल.
Based on the architecture described by Mayu2008. For more discussions on data engineering and AI systems, join the GyaanSetu community.