castomo परिवारभित्र
ग्राहक आठ ग्राहक हुनबाट रोकिने ठाउँ
यदि तपाईं पहिले नै dash-b, castomo, clickSomo वा FABLS प्रयोग गर्नुहुन्छ भने, तपाईं आधुनिक एकीकरणको समस्यासँग परिचित हुनुहुन्छ: सबै कुरा सबैसँग जोडिन्छ, र एउटै मानिस आठ ठाउँमा, अलि-अलि फरक हिज्जे भएर, आठ पटक अस्तित्वमा आउँछ — जहाँ प्रत्येक ठाउँ आफैलाई नै अधिकारसम्पन्न ठान्छ।
सामान्य समाधान भनेको सिंक्रोनाइजेसन जब हो, जुन दुई झूटलाई मिलाउने एउटा मेसिन हो। यो तबसम्म चल्छ जबसम्म चल्ने क्रममा एउटा तिर सम्पादन हुँदैन — त्यो बेला तपाईंसँग तेस्रो झूट र एउटा सहयोग टिकट हुन्छ।
iKonekt परिवारसँग एकीकृत छैन। यो त्यसको भित्रै छ। उही साइन-इन, उही खाता, मुनि उही प्लेटफर्म — त्यसैले ग्राहक रेकर्डलाई उत्पादनहरूबीच मिलाउनु पर्दैन, किनकि त्यो एउटै छ।
मुनि castomAPI
परिवारका हरेक उत्पादन चल्ने प्लेटफर्म तह: एउटा खाता, एउटा वालेट, प्रमाणीकरण, बिलिङ, भुक्तानी र बुकिङका लागि एउटै सेवा-समूह। कनेक्टरहरू वीरगाथा होइनन्, छोटा हुनुको कारण यही हो।
clickSomo, दुवै दिशामा
सन्देश स्वचालन जहाँ राम्रो छ, त्यहीँ नै रहन्छ — clickSomo मा। यात्रा गर्ने कुरा भनेको कुराकानी र नतिजा हो, त्यसैले कुनै सिक्वेन्सलाई मानिसले काटेको थाहा हुन्छ, र बिक्रेताले सिक्वेन्सले पहिले नै के भनिसक्यो भन्ने देख्न सक्छ।
FABLS, माथि खुवाउने
ब्लगिङ र सोसलले पाठक बनाउँछन्; पाठकले सोधपुछ बनाउँछन्; सोधपुछ यहाँ आउँछन्, र त्यो लेख जसले बनायो त्यो स्रोतका रूपमा रेकर्ड भएर। बीचमा स्प्रेडसिट नराखी नै लुप पूरा हुन्छ।
castomUI का फारमहरू
castomUI ले बनाएका साइट र ल्यान्डिङ पेजहरूमा यहाँ सिधै आउने फारमहरू हुन्छन् — इमेलबाट होइन, तपाईंले मर्मत गर्ने वेबहुकबाट पनि होइन। पृष्ठ र इनबक्स दुवै उही परिवारले बनाएका हुन्।
dash-b, हेरिरहेको
उही खाताबाट पढ्ने ड्यासबोर्डहरू, त्यसैले भित्तामा भएको अङ्क र CRM मा भएको अङ्क कहिल्यै नमिल्न सक्दैन — एउटा आश्चर्यजनक रूपमा दुर्लभ गुण।
castomo, घर
तपाईंसँग पहिले नै भएको खाता। परिवारको कुनै पनि कुरामा साइन-इन गर्नुभएको छ भने, तपाईं यसमा साइन-इन गरिसक्नुभएको छ — दोस्रो दर्ता छैन, र हराउने दोस्रो पासवर्ड पनि छैन।
"दुवै दिशामा" भनेको वास्तवमा के हो
दुई-दिशा शब्द धेरै प्रयोग हुने शब्द हो, त्यसैले यहाँ ठोस संस्करण छ। यस परिवारको कनेक्टर रात्रिकालीन एक्सपोर्ट होइन। clickSomo ले सिक्वेन्स पठाउँदा र ग्राहकले जवाफ दिँदा, त्यो जवाफ iKonekt को थ्रेडमा हुन्छ, र clickSomo ले पठाउन छोड्न जान्छ — किनकि अब मानिस कुरा गरिरहेको छ। बिक्रेताले यहाँ कुनै काम सक्दा, जसलाई ख्याल छ त्यसलाई एक पटक, क्रममा, भनिन्छ, र त्यसमा कारबाही गर्न सकिन्छ।
कार्यक्षमता सर्दैन। clickSomo सन्देश उत्पादन नै रहन्छ र iKonekt कुराकानी नै। सीमा पार गर्ने कुरा भनेको दुवै पक्षलाई साँच्चै चाहिने थोरै तथ्यहरू हुन्, जुन यति भरपर्दो रूपमा आउँछन् कि कुनै पक्षले अनुमान गर्नु पर्दैन।
यो बनाउँदा भएको एउटा अवलोकन: एकीकरणको कठिन भाग लगभग कहिल्यै पठाउने हुँदैन। कठिन भनेको कुनै वस्तु के हो भन्ने कुरामा सहमत हुनु हो — एउटा उत्पादनको "सम्पर्क" अर्कोमा "लिड" र तेस्रोमा "ग्राहक" हुन्छ कि हुँदैन। एउटै परिवार हुनुको अर्थ यो बहस एक पटक, भित्रै, भयो, र तपाईंको समस्या बनेन।
एउटा खाता, र त्यसबाट निस्कने एउटै बाटो
उत्पादनहरूबीच खाता साझा गर्दा उचित प्रश्न उठ्छ — कसैले आफ्नो डेटा हटाउन चाहँदा के हुन्छ? यस परिवारमा मेटाउने अनुरोध कुनै मेलबक्स नियम होइन — यो जे कुरा भएको छ त्यो राख्ने उत्पादनहरूमा फैलिन्छ, र प्रत्येकले आफ्ना लागि जवाफ दिन्छ। फारम बनाउनुभन्दा यो धेरै कठिन बनाउनु पर्छ, र यही कारणले यसलाई कसैले नपढ्ने नीतिमा होइन, यहाँ उल्लेख गर्न लायक छ।
यदि तपाईं पहिले नै परिवारमा हुनुहुन्छ भने, तपाईंसँग यहाँ पहिले नै खाता छ।
उही साइन-इन, उहै ग्राहक — माइग्रेसनको सप्ताहान्त छैन, र तेस्रो सत्यको संस्करण चुपचाप बनाउने कुनै सिंक्रनाइजेसन कार्य पनि छैन।
“त्यसो भए हामीलाई यसलाई अरू सबैसँग सिंक गर्नुपर्नेछ।”
सिंक गर्न केही छैन।
परिवारभर एउटा खाता, त्यसमुनि एउटा ग्राहक रेकर्ड। सिंक्रनाइजेसन कार्य त्यस्तो मेसिन हो जसको पूरा उद्देश्य दुई झूटलाई सहमत बनाउनु हो; यहाँ भने एउटा मात्र सत्य छ।
प्लेटफर्म हेर्नुहोस् →