राइट-बैक लेयर: इनसाइट्स को सिस्टम्स ऑफ एक्शन में रूट करना

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

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

एक इनसाइट जिस पर कोई एक्ट नहीं करता वह सिर्फ एक लागत है

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

व्यवहार में इसका मतलब है कुछ मंज़िलें। CRM फील्ड्स और व्यूज़, ताकि हेल्थ स्कोर, नेक्स्ट बेस्ट एक्शन्स और अट्रिब्यूटेड पाइपलाइन वहां दिखें जहां रेप्स और मैनेजर्स पहले से देखते हैं। अलर्ट्स, जैसे ओनर को Slack मैसेज जब कोई अकाउंट churn-risk थ्रेशोल्ड पार करता है। एक्टिवेशन प्लेटफॉर्म्स, जहां एक कंप्यूटेड सेगमेंट ad या मार्केटिंग टूल में एक लाइव ऑडियंस बन जाता है। और ऑटोमेटेड वर्कफ़्लोज़, जहां एक स्कोर बिना किसी इंसान के रिले किए एक रूटिंग रूल या अप्रूवल ट्रिप कर देता है।

इन सबके नीचे का सिद्धांत है लोगों से उन सिस्टम्स में मिलना जो वे पहले से इस्तेमाल करते हैं बजाय इसके कि उनसे एक और चेक करने को कहा जाए। एक इनसाइट को अपनाने की दर हर अतिरिक्त क्लिक के साथ तेज़ी से गिरती है जो इसे ढूंढने में लगता है।

लिखना पढ़ने से ज़्यादा मुश्किल है

इनजेशन गलतियां माफ करता है। राइट-बैक नहीं करता। तीन चीज़ें इसे सचमुच एक ज़्यादा मुश्किल इंजीनियरिंग प्रॉब्लम बनाती हैं।

पहले इडेमपोटेंसी। राइट्स को दोबारा ट्राई करने में सेफ होना चाहिए। अगर एक सिंक आधे में फेल हो जाता है और फिर से चलता है, तो इसे डुप्लिकेट टास्क नहीं बनाने चाहिए या एक ही अपडेट को दो बार अप्लाई नहीं करना चाहिए। हर राइट को एक स्टेबल की और अपसर्ट सिमेंटिक्स चाहिए ताकि "इसे फिर से चलाओ" हमेशा एक सेफ बात हो। इसके बिना, एक अस्थायी फेलियर परमानेंट खराब डेटा बन जाता है।

फिर कॉन्फ्लिक्ट रिज़ॉल्यूशन। जिस फील्ड को आप लिखने वाले हैं उसे किसी इंसान ने आपके आखिरी बार पढ़ने के बाद एडिट किया हो सकता है। बिना सोचे-समझे ओवरराइट करें और आप किसी के जजमेंट को नष्ट कर देते हैं; बिना सोचे-समझे स्किप करें और आप अपनी ही इनसाइट फेंक देते हैं। आपको एक स्पष्ट पॉलिसी चाहिए, और इसे हर फील्ड के हिसाब से तय होना चाहिए, ग्लोबली नहीं। Last-write-wins, system-of-record precedence, field-level ownership। इनमें से कोई भी सही हो सकता है। खामोशी कभी सही नहीं होती।

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

ये वही रिलायबिलिटी चिंताएं हैं जो शेयर्ड डेटा लेयर को पॉइंट-टू-पॉइंट इंटीग्रेशन से बेहतर बनाती हैं। राइट लॉजिक को सेंट्रलाइज़ करने का मतलब है आप इडेमपोटेंसी और कॉन्फ्लिक्ट्स को हर एक नाज़ुक डायरेक्ट कनेक्शन में बजाय एक बार सुलझाते हैं।

कैडेंस

हर इनसाइट को एक ही रिदम पर वापस नहीं लिखा जाना चाहिए, और इसे गलत करने से या तो स्टेल डेटा मिलता है या नॉइज़। एक "अभी हॉट लीड" अलर्ट एक घंटा देर से बेकार है। हर पांच मिनट में लिखा गया एक नाइटली अकाउंट-हेल्थ रिफ्रेश सिर्फ फील्ड हिस्ट्री में चर्न और टीम में अलर्ट फटीग पैदा करता है। राइट कैडेंस को इससे मैच करें कि टारगेट को कैसे कंज्यूम किया जाता है, रियल-टाइम बनाम बैच: कब रेवेन्यू डेटा फ्रेशनेस मायने रखती है जैसी ही per-flow रीजनिंग इस्तेमाल करके।

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

इसे इस तरह बनाना कि यह चीज़ें न तोड़े

एक राइट-बैक लेयर जिस पर आप भरोसा कर सकें उसमें कुछ ऐसे गुण होते हैं जो ऑप्शनल नहीं हैं।

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

एक और बात। आप जो लिखते हैं वह उतना ही अच्छा है जितना कि जिससे आपने इसे कंप्यूट किया। गंदे डेटा पर बना एक स्कोर CRM में पुश करें और आपने किसी की मदद नहीं की; आपने खराब डेटा को लॉन्डर किया है और उसे अथॉरिटी दे दी है। अपस्ट्रीम RevOps डेटा हाइजीन एक पूर्वशर्त है डाउनस्ट्रीम राइट-बैक के लिए जिस पर आप भरोसा कर सकें।

मुख्य बातें

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

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