व्हाइट लेबल या अपना बुकिंग इंजन बनवाना: असली हिसाब

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

कोटेशन ईमानदार है। बस वह काम के उसी हिस्से की कीमत लगाता है जो दिखाई देता है।

कोटेशन असल में किसकी कीमत लगाता है

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

दूसरा आधा हिस्सा वह है जो ब्राउज़र से दिखता ही नहीं: सप्लायर वाला सिरा। साल वहीं खर्च होते हैं।

खर्च इंटरफ़ेस में नहीं, इंटीग्रेशन की गिनती में है

सप्लायर से एक्सेस माँगिए, जवाबी मेल में API key नहीं मिलेगी। मिलेगा एक टेस्ट एनवायरनमेंट, एक सर्टिफिकेशन प्रक्रिया, हर कानूनी इकाई के लिए अलग जारी होने वाले क्रेडेंशियल, नियमों का एक दस्तावेज़, और एक संपर्क व्यक्ति जो अपनी सहूलियत से जवाब देता है। फिर उस सप्लायर की अपनी बोली से परिचय होता है: कहीं स्टैटिक रेट और कहीं लाइव अवेलेबिलिटी, free-sale के बगल में release period वाला allotment, एक cut-off जिसे आपके इंजन को मानना ही है, fare rules जो तय करती हैं कि बदलाव पर चार्ज लगेगा या नहीं, और ऐसा ancillary कैटलॉग जो किसी और से मेल नहीं खाता। अब इसे उन सप्लायरों की संख्या से गुणा कीजिए जिनकी उम्मीद आपके ग्राहक आपसे करते हैं।

एक इंटीग्रेशन एक प्रोजेक्ट है। छह इंटीग्रेशन एक विभाग हैं, और उसका काम कभी खत्म नहीं होता, क्योंकि उन छह में से किसी ने बदलना बंद करने का वादा नहीं किया है।

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

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

वह तुलना जो दूसरे साल में टिकती है

इस टेबल को खरीदार की नहीं, चलाने वाले की नज़र से पढ़िए। हर पंक्ति में सवाल एक ही है: ज़िम्मेदारी किस पर है?

इनमें दो पंक्तियाँ खुद बनवाने के पक्ष में हैं। ये सांत्वना पुरस्कार नहीं हैं: आपका काम अगर सचमुच अलग किस्म का है, तो ये दोनों ऊपर की सब पंक्तियों पर भारी पड़ती हैं।

गलत फैसले की कीमत

खुद बनाए इंजन की नाकामी यह नहीं होती कि प्रोजेक्ट ढह जाए। ढहा हुआ प्रोजेक्ट दिखता है, चुभता है, और झेला जा सकता है। महँगी शक्ल वह है जिसमें सिस्टम चलता है — और फिर धीरे-धीरे रुकने लगता है।

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

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

कब अपना बनवाना वाकई सही है

कभी-कभी सही होता है, और हालात इतने साफ़ हैं कि आप खुद को उन पर परख सकते हैं।

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

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

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

एक सवाल, दोनों से

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

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