CRM सेतु
सत्र पहिचान भएपछि रेकर्डिङ CRM मा त्यही व्यक्तिको नोट बन्छ — पहिल्यै भएको सम्पर्कमा, नयाँमा होइन।
1. एक वाक्यमा यसको काम
सत्र पहिचान हुनेबित्तिकै पठाएको ID बाट CRM मा व्यक्ति खोजेर रेकर्डिङ लिङ्कसहित नोट जोड्छौँ।
यत्ति हो। नयाँ सम्पर्क, कारोबार वा पाइपलाइन परिवर्तन छैनन्। मूल्य पृष्ठ हेर्दैपिच्छे दोहोरो सम्पर्क बनाउने CRM एकीकरण नहुनुभन्दा खराब हो।
व्यक्ति नभेटिए केही हुँदैन। नयाँ व्यक्ति बनाउनु भनेको ब्राउजर सत्रबाट CRM मा रेकर्ड लेख्नु हो — ग्राहक को हुन् भन्ने सत्यको आधार ब्राउजर सत्र होइन।
2. मिलान कुञ्जी: व्यक्ति कसरी भेट्छौँ
दस मिनेट ध्यान दिनलायक भाग यही हो, किनकि CRM एकीकरण प्रायः यहीँ चुपचाप गलत हुन्छ।
साइटले दिएको कुराबाट आगन्तुक चिन्छौँ — MousePlayer.setUserId(), विश्लेषण उपकरणबाट लिइएको distinct ID वा सर्भरतर्फको identify कल। CRM ले पनि कुनै मानबाट चिन्छ। दुवै उही हुनुपर्छ।
| खोजिने मान | बदल्न मिल्छ? | |
|---|---|---|
| HubSpot | सम्पर्कको इमेल ठेगाना | मिल्दैन — खोज एन्डपोइन्ट त्यसैमा आधारित छ |
| Pipedrive | खोज शब्दबाट व्यक्ति, पहिले इमेल | मिल्दैन |
| Salesforce | एउटा फिल्ड तपाईंले तोक्ने, पूर्वनिर्धारित Email | मिल्छ |
Salesforce ले किन सोध्छ
Salesforce सेटअप प्रायः इमेलमा आधारित हुँदैन। तपाईंको यो मानमा आधारित हुन सक्छ: Customer_Number__c वा बिलिङ प्रणालीको बाहिरी ID मा। तैपनि इमेल खोजे केही नभेटी सफलता जनाउँथ्यौँ — एकीकरण चलेको देखिने भएकाले सबैभन्दा खराब विफलता।
त्यसैले फारमले सोध्छ: Contact को कुन फिल्डमा हामीले पठाएको मान छ? अनुकूलित फिल्ड भए यससहित API नाम राख्नुहोस्: __c ।
क्वेरीमा पुग्नुअघि फिल्ड नाम कडा ढाँचामा जाँचिन्छ। CRM फिल्ड नाममा अक्षर, अङ्क र अन्डरस्कोर मात्र हुन्छन् — अरू escape गर्नुको सट्टा अस्वीकार गरिन्छ, किनकि escape गर्दा सूक्ष्म त्रुटि हुन सक्छ।
3. कहिले चल्छ र कहिले जानाजानी चल्दैन
पहिचान हुँदा: साइटले यो कल गर्दा MousePlayer.setUserId(), विश्लेषण सेतुले PostHog, Mixpanel वा Amplitude बाट distinct ID पढ्दा वा सर्भरले identify एन्डपोइन्ट कल गर्दा।
प्रति सत्र एक पटक, प्रति पृष्ठ होइन
लग इन गरेर एघार पृष्ठ हेर्ने व्यक्तिको एउटा नोट हुन्छ, एघार होइन। CRM टाइमलाइन मानिसले पढ्ने ठाउँ हो।
पहिचानकर्ताबिना चल्दैन
गुमनाम सत्रमा मिलान गर्ने आधार छैन। IP बाट अनुमान गर्दैनौँ र उही ठेगाना साझा गर्ने जोकोहीमा रेकर्डिङ जोड्दैनौँ।
CRM मा व्यक्ति नभए चल्दैन
असफल होइन, पूरा भएको मानिन्छ — सम्भावित ग्राहक अझै CRM मा नहुनु सामान्य हो र भोलि दोहोर्याउँदा बदलिँदैन।
4. नोट र टोकनको भण्डारण
सम्पर्क टाइमलाइनमा एउटा नोट: सत्र रेकर्ड भएको वाक्य र लिङ्क। बिक्रीकर्मीले क्लिक गरेर सम्पर्क गर्नुअघि व्यक्तिले वास्तवमा के गर्यो हेर्छन्।
प्रमाण
AES-256-GCM एन्क्रिप्सनमा राखिन्छ। सुरक्षित गरेपछि फेरि देखाइँदैन — फिल्डमा तारा देखिन्छन् र तारा राखेरै सुरक्षित गर्दा पुरानो मान बदलिँदैन। काम बोक्ने आन्तरिक पङ्क्तिमा पनि जानाजानी राखिँदैन: त्यो साझा अवस्था हो, कुञ्जी राख्ने ठाउँ होइन।
Salesforce लाई तीन कुरा, अरूलाई दुई
Salesforce ले रिफ्रेस टोकनसहित Connected App बाट प्रमाणीकरण गर्छ, त्यसैले consumer key, गोप्य कुञ्जी, रिफ्रेस टोकन र इन्स्ट्यान्स URL माग्छ। HubSpot र Pipedrive ले एउटै API टोकन लिन्छन्। तीनैमा एप तपाईंको हो — MousePlayer ले विश्वास गर्नुपर्ने marketplace एप चलाउँदैन।
5. Zoho CRM र Freshsales
थप दुई CRM, सेटअप मेहनतको हिसाबले फरक छेउमा।
| Zoho CRM | Freshsales | |
|---|---|---|
| तपाईंले दिने | डेटा केन्द्र, क्लाइन्ट ID, क्लाइन्ट गोप्य कुञ्जी, रिफ्रेस टोकन | API कुञ्जी र Freshworks डोमेन |
| खोजिने मान | तपाईंले तोकेको फिल्ड, पूर्वनिर्धारित Email | तपाईंले तोकेको फिल्ड, पूर्वनिर्धारित email |
| नोट पुग्ने ठाउँ | सम्पर्कमा Note रेकर्डका रूपमा | सम्पर्कमा नोटका रूपमा |
Zoho छमध्ये एउटा डेटा केन्द्रमा हुन्छ
खाता यसमध्ये एउटामा हुन्छ: com, eu, in, com.au, jp वा com.cn र कुन हो भन्ने कुञ्जीले बताउँदैन। गलत छाने Zoho ले यो जवाफ दिन्छ: INVALID_TOKEN — खराब कुञ्जीजस्तो देखिएर गलत ठाउँ खोज्न लगाउँछ। त्यसैले फिल्ड ड्रपडाउन हो।
एक पटक Self Client
Zoho API कन्सोलमा Self Client बनाएर यी स्कोपका लागि grant token बनाउनुहोस्: ZohoCRM.modules.ALL र ZohoSearch.securesearch.READ, अनि एक पटक रिफ्रेस टोकनमा साट्नुहोस्। त्यसको म्याद सकिँदैन; घण्टैपिच्छेका पहुँच टोकन त्यसैबाट लिइन्छन्, भण्डारण गरिँदैनन्।
अस्वीकार गर्दा पनि Zoho ले 200 फर्काउँछ
टोकन साट्दा र रेकर्ड लेख्दा HTTP 200 सहित मुख्य भागमा त्रुटि वा प्रति-रेकर्ड स्थिति आउन सक्छ। हामी मुख्य भाग पढ्छौँ — स्थिति कोडमा भर पर्ने सेतुले नबनेको नोट पनि सफल भन्थ्यो।
यहाँ उल्लेख सबै ट्रेडमार्क सम्बन्धित मालिकका हुन्। MousePlayer को यी प्रदायकसँग व्यावसायिक सम्बन्ध छैन।