वाहन किराया प्रबंधन सॉफ़्टवेयर: आधुनिक रेंटल फ़्लीट्स को क्या चाहिए

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

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

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

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

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

सिर्फ़ उपलब्धता नहीं, यूटिलाइज़ेशन भी

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

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

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

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

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

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

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

हर रिटर्न साफ़-सुथरा नहीं होता। जब वाहन ऐसी क्षति के साथ लौटता है जिसे सिर्फ़ दर्ज करने के बजाय ठीक करने की ज़रूरत होती है, तो रिटर्न पर लिया गया कंडीशन रिपोर्ट सिर्फ़ डिपॉज़िट का दस्तावेज़ नहीं रह जाता और वर्कशॉप के काम की शुरुआत बन जाता है।

यहीं पर Renttix का Workshop Command Centre काम में आता है: मरम्मत शेड्यूल करने के लिए ड्रैग-एंड-ड्रॉप टेक्नीशियन बोर्ड, जब क्षति का शुल्क वापस लगाया जाना हो तो ग्राहक द्वारा स्वीकृत मरम्मत अनुमान, सप्लायर कैटलॉग से लिए गए पार्ट्स, और एक रिटर्न-इंस्पेक्शन गेट जो यह जाँचता है कि वाहन को उपलब्धता सूची में वापस फ़िट मार्क करने से पहले मरम्मत असल में पूरी हो चुकी है। फ़र्स्ट-टाइम-फ़िक्स और MTBF (मीन टाइम बिटवीन फ़ेल्योर्स) के आँकड़े फ़्लीट मैनेजर को यह समझने में मदद करते हैं कि क्या कोई ख़ास वाहन, या किसी ख़ास तरह की खराबी, बार-बार सामने आ रही है।

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

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

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

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

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

घर्षण बिंदु साफ़ है: एक वैन जिसकी सर्विस अगले 800 किलोमीटर में ड्यू है, उसे पाँच दिन के किराए के लिए बुक कर दिया जाता है जो उसे उस सीमा से काफ़ी आगे ले जाएगा। जब फ़्लीट उपलब्धता और मेंटेनेंस शेड्यूलिंग एक ही वाहन रिकॉर्ड से काम करते हैं, तो वह वैन बुकिंग कन्फ़र्म होने से पहले फ़्लैग हो जाती है, बाद में नहीं, जिससे कोऑर्डिनेटर को सर्विस पहले करा लेने, कोई दूसरी वैन देने, या किराया स्वीकार कर वापसी वाले दिन सर्विस शेड्यूल करने का विकल्प मिलता है। यही फ़्लीट कभी-कभार किसी डैमेज विवाद से भी निपटती है, जैसे किराए के दौरान टूटा साइड मिरर जिसके बारे में ग्राहक कहता है कि वह पहले से ढीला था; कलेक्शन और रिटर्न, दोनों पर लिया गया कंडीशन रिकॉर्ड इसे किसी भी दिशा में सुलझा देता है, बजाय इसके कि यह इस पर निर्भर हो कि कौन ज़्यादा भरोसे से दलील देता है।

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