ट्रांसपोर्ट कंपनी के लिए सॉफ़्टवेयर चुनना: फ़ील्ड में क्या परखें

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

वर्कफ़्लो के चरण और सॉफ़्टवेयर को क्या करना चाहिए

• अनुरोध आता है: ग्राहक से, आपके नेटवर्क से, या किसी टेंडर शीट से — एक ही सुबह काम तीन रास्तों से एक साथ आता है: किसी नियमित ग्राहक का फ़ोन, आपके नेटवर्क की किसी कंपनी का सिस्टम से भेजा गया अनुरोध, और सालाना एग्रीमेंट के लिए भरी जाने वाली रूट लिस्ट। पहले किसे देखेंगे, यह उस दिन खाली वाहनों और उन रूटों से तय होता है जिन पर आप असल में चलते हैं। आने वाले सभी अनुरोध एक ही लिस्ट में; रूट, देश और इक्विपमेंट के प्रकार से फ़िल्टर; कुछ नया आते ही टीम को तुरंत नोटिफ़िकेशन। कई रूटों की सीज़नल प्राइसिंग के लिए शीट से एक साथ कोटेशन दर्ज करने की सुविधा। उपयुक्त काम लिस्ट में देर से दिखता है, ग्राहक जवाब के इंतज़ार में रहता है और ट्रक खाली लौटता है। भीड़ भरी रूट लिस्ट हाथ से भरना इतना थकाऊ है कि उस काम पर कभी कोटेशन ही नहीं दिया जाता।
• कीमत बनती है और कोटेशन भेजा जाता है — प्रति वाहन दर, बॉर्डर और कस्टम्स की लागत और वापसी लोड मिलने की संभावना किसी के दिमाग़ में जोड़ी जाती है, और आँकड़ा फ़ोन या ईमेल से बता दिया जाता है। जब ग्राहक मोलभाव करता है, तो दूसरा और कभी-कभी तीसरा आँकड़ा सामने आता है, और कौन-सा मान्य है, यह साफ़ नहीं रहता। प्रति वाहन दर और कुल राजस्व एक ही स्क्रीन पर; कोटेशन में संशोधन की सुविधा, और संशोधन पर पिछला आँकड़ा अपने-आप रद्द; किसने कब क्या कोट किया, इसका रिकॉर्ड, और मापी गई जीत दर। ग्राहक समझ नहीं पाता कि कौन-सा आँकड़ा मौजूदा है, और स्वीकार की गई कीमत इनवॉइस में आई रकम से मेल नहीं खाती। आपको कभी पता नहीं चलता कि कौन-सा रूट कमाता है या आप अपने कितने कोटेशन जीतते हैं, इसलिए प्राइसिंग रणनीति अंदाज़े पर ही चलती रहती है।
• काम मिल गया: ट्रैक्टर यूनिट, ट्रेलर और ड्राइवर का मिलान होता है, या काम सब-कॉन्ट्रैक्ट पर दिया जाता है — आप एक खाली ट्रैक्टर यूनिट, उपयुक्त ट्रेलर और उस रूट पर चलने की अनुमति वाले ड्राइवर का मिलान करते हैं। जब कोई उपयुक्त वाहन उपलब्ध नहीं होता, तो पूरा काम या उसका हिस्सा किसी जान-पहचान वाले ट्रांसपोर्टर को जाता है, और तालमेल फिर से फ़ोन पर लौट आता है। असाइनमेंट के समय पात्रता की जाँच: क्या ड्राइवर के दस्तावेज़ वैध हैं, क्या उसके पास विदेश में बिताने के लिए पर्याप्त दिन बचे हैं, क्या वह उन तारीखों पर पहले से किसी दूसरी ट्रिप पर बुक है? सब-कॉन्ट्रैक्ट करने पर प्रगति लगातार दिखती रहे, जबकि ग्राहक और दर की जानकारी सब-कॉन्ट्रैक्टर से छिपी रहे। एक ही ड्राइवर दो ट्रिप पर बुक हो जाता है; एक्सपायर्ड वीज़ा वाला ड्राइवर निकल पड़ता है और बॉर्डर से लौटा दिया जाता है। सब-कॉन्ट्रैक्ट किया गया काम "चला गया, ख़बर का इंतज़ार है" वाली हालत में पहुँच जाता है, और आप अपने ग्राहक को क्या जवाब देंगे, यह इस पर टिका होता है कि सब-कॉन्ट्रैक्टर फ़ोन उठाता है या नहीं।
• लोडिंग और कागज़ी काम: डिलीवरी नोट, CMR कंसाइनमेंट नोट, पैकिंग लिस्ट, निर्यात डिक्लेरेशन — लोडिंग पॉइंट पर पैकेज की संख्या, वज़न और पैकेजिंग तय होती है, और वही विवरण डिलीवरी नोट (तुर्किये में irsaliye), कंसाइनमेंट नोट, पैकिंग लिस्ट और इनवॉइस पर अलग-अलग लिखा जाता है। अंतरराष्ट्रीय सड़क ढुलाई में CMR कंसाइनमेंट नोट माल के साथ चलता है; नियम के तौर पर यह तीन मूल प्रतियों में बनता है और इस पर भेजने वाले (सेंडर) और वाहक (कैरियर) दोनों के हस्ताक्षर होते हैं। CMR कन्वेंशन के तहत कंसाइनमेंट नोट में दर्ज विवरणों — पक्षों के नाम, पैकेज की संख्या, वज़न और माल का विवरण — की सटीकता की ज़िम्मेदारी आम तौर पर भेजने वाले की होती है, जबकि वाहक की भूमिका पैकेजों की संख्या, उन पर लगे निशान (मार्क्स) और माल की बाहर से दिखने वाली हालत जाँचना और ज़रूरत पड़ने पर आपत्ति (रिज़र्वेशन) दर्ज करना है। कंसाइनमेंट नोट और दूसरे दस्तावेज़ एक ही लोड रिकॉर्ड से तैयार हों; ड्राइवर लोडिंग के समय अपने फ़ोन से दस्तावेज़ों की फ़ोटो जोड़ सके; दस्तावेज़ों के बीच वज़न, पैकेज संख्या या पक्ष के नाम में कोई भी अंतर अपने-आप चिह्नित हो। क्योंकि एक ही विवरण कई दस्तावेज़ों पर हाथ से टाइप होता है, वह कहीं न कहीं बदल जाता है, और यह गड़बड़ी आम तौर पर या तो बॉर्डर पर पकड़ में आती है या बैंक में। फ़ील्ड में खींची गई फ़ोटो किसी ग्रुप चैट में गुम हो जाती है, और ऑफ़िस हफ़्तों बाद उसे ढूँढता फिरता है।
• बॉर्डर, ट्रांज़िट और कस्टम्स पर इंतज़ार — निर्यात डिक्लेरेशन आम तौर पर उस सक्षम कस्टम्स ऑफ़िस में दाखिल किया जाता है जहाँ माल मौजूद है, हालाँकि कौन-सा ऑफ़िस सक्षम है, यह देश, प्रक्रिया और लागू सरलीकरणों पर निर्भर करता है। इसके बाद वाहन उन दस्तावेज़ों के साथ बॉर्डर तक जाता है। बॉर्डर पर निकासी (एग्ज़िट) की औपचारिकताएँ पूरी होती हैं, जहाँ ज़रूरी हो वहाँ ट्रांज़िट दस्तावेज़ (T1 डिक्लेरेशन या TIR कार्नेट) प्रोसेस होता है, और कागज़ात जाँचे जाते हैं। अगर कोई असंगति दिखती है या कोई दस्तावेज़ कम पड़ता है, तो इंतज़ार घंटों में गिना जाता है, और डेमरेज व देरी की लागत बिना किसी योजना के बढ़ती जाती है। शिपमेंट निकलने से पहले दस्तावेज़ों के बीच कंसिस्टेंसी जाँच; कस्टम्स ब्रोकर का उसी फ़ाइल में एक पक्ष के रूप में जुड़ पाना; रवाना होने से पहले कमोडिटी कोड (HS कोड) को गंतव्य देश के शुल्कों और व्यापार उपायों से मिलाकर जाँचने की सुविधा; ड्राइवर की शेंगेन 90/180 दिन की सीमा की अपने-आप गिनती। दस्तावेज़ की कमी बॉर्डर पर जाकर पता चलती है; वाहन रुका रहता है, लागत योजना से आगे निकल जाती है और ग्राहक को दी गई डिलीवरी की तारीख खिसक जाती है। नज़र से छूटा कोई अतिरिक्त शुल्क मुनाफ़े वाली समझी गई ट्रिप को घाटे में बदल देता है, और दिनों की सीमा पार कर चुके ड्राइवर को प्रवेश से मना कर दिया जाता है।
• रास्ते में ट्रैकिंग और ग्राहक को जानकारी देते रहना — ग्राहक दिन में एक-दो बार पूछता है "ट्रक कहाँ है"; आप ड्राइवर को फ़ोन करते हैं, ड्राइवर सड़क पर है और जवाब देर से आता है। दिन भर में एक ही जानकारी तीन लोगों को तीन बार समझाई जाती है। लोकेशन वाहन के नहीं, बल्कि ले जाए जा रहे लोड के रिकॉर्ड के तहत दर्ज हो; हर स्टेटस बदलाव टाइमस्टैम्प के साथ सेव हो; ग्राहक इसे अपनी स्क्रीन से या एक शेयर किए गए लिंक से देख सके; बातचीत हर लोड के हिसाब से रखी जाए और ज़रूरत पड़ने पर अपने-आप अनुवादित हो। पूरा दिन स्टेटस अपडेट देने में निकल जाता है। विवाद होने पर आप साबित नहीं कर पाते कि वाहन कब कहाँ था; विदेशी भाषा का कोई संदेश गलत समझा जाता है और ट्रक गलत पते पर पहुँच जाता है।
• डिलीवरी, POD और इक्विपमेंट की वापसी — माल उतारा जाता है, कंसाइनमेंट नोट की हस्ताक्षरित प्रति और डिलीवरी का प्रमाण लिया जाता है, और ट्रेलर खाली किया जाता है या दूसरे पक्ष के पास छोड़ दिया जाता है। नुकसान (डैमेज) को लेकर बहस आम तौर पर ठीक इसी बिंदु पर शुरू होती है, और ज़िम्मेदारी साबित नहीं हो पाती। ड्राइवर डिलीवरी का प्रमाण सीधे अपने फ़ोन से लोड में जोड़ सके; डिलीवरी का समय और जगह अपने-आप दर्ज हो; ट्रेलर के हाथ बदलने पर फ़ोटो के साथ हैंडओवर रिकॉर्ड, और ज़िम्मेदारी की अवधि (विंडो) की ट्रैकिंग। हस्ताक्षरित कंसाइनमेंट नोट हफ़्तों बाद ऑफ़िस पहुँचता है, तब तक इनवॉइस जारी नहीं हो सकता, और वसूली टल जाती है। चूँकि कोई साबित नहीं कर पाता कि नुकसान किस चरण में हुआ, कटौती आम तौर पर गलत तरीके से आखिरी ड्राइवर पर डाल दी जाती है।
• सेटलमेंट, इनवॉइसिंग, वसूली और खाते बंद करना — ट्रिप खत्म होती है और फ़्रेट इनवॉइस जारी होता है; सब-कॉन्ट्रैक्टर का सेटलमेंट और ड्राइवर के खर्च घटाए जाते हैं। ग्राहक तय अवधि में भुगतान करता है या नहीं करता, और ज़्यादातर कंपनियों में यह पूरा चरण एक बिल्कुल अलग प्रोग्राम में चलता है। इनवॉइस लोड रिकॉर्ड से तैयार हो; वसूली दर्ज करते ही खाते का बैलेंस और प्राप्य राशि की एजिंग अपने-आप अपडेट हो; आपके EU ग्राहक का सिस्टम जिस ई-इनवॉइसिंग फ़ॉर्मेट को स्वीकार करता है, उसका सपोर्ट; ड्राइवर के खर्च सही पक्ष के खाते में दर्ज हों। एक ही आँकड़ा ऑपरेशन, इनवॉइसिंग और अकाउंटिंग में तीन बार दर्ज होता है, और गलतियाँ जुड़ती जाती हैं। ओवरड्यू प्राप्य राशि चुपचाप बढ़ती है और कैश फ़्लो बिगाड़ देती है; फ़ॉर्मेट के कारण खारिज हुआ क्रॉस-बॉर्डर इनवॉइस वसूली को महीनों तक खींच देता है।

चयन मानदंड

• डिस्पैच का मूल: असाइनमेंट के पल में ड्राइवर और वाहन की पात्रता की जाँच — ट्रांसपोर्टर का दिन यह तय करने में जाता है कि कौन क्या कहाँ चलाएगा। अगर कोई सिस्टम उस असाइनमेंट को सिर्फ़ दर्ज करता है, तो वह बस रजिस्टर रख रहा है; अगर असाइन करते समय वह ड्राइवर के दस्तावेज़ों की वैधता, विदेश में उसके बचे दिन और वाहन की उपलब्धता जाँचता है, तो वह डिस्पैच कर रहा है। इन दोनों के बीच का फ़र्क वह ट्रक है जो यार्ड से निकल जाने के बाद बॉर्डर से लौटा दिया जाता है। एक ऐसा ड्राइवर सेट करें जिसका वीज़ा जल्द एक्सपायर होने वाला हो और विदेश में रहने के दिनों की सीमा लगभग खत्म हो चुकी हो, फिर उसे एक नई ट्रिप पर असाइन करने की कोशिश करें: क्या चेतावनी असाइनमेंट स्क्रीन पर ही दिखती है, या उसे देखने के लिए आपको दस्तावेज़ों का अलग पेज खोलना पड़ता है? फिर ऐसी दूसरी ट्रिप के साथ दोहराएँ जिसकी तारीखें ओवरलैप करती हों, और ठीक-ठीक नोट करें कि सिस्टम क्या कहता है।
• फ़ील्ड का वह चरण जिसे ड्राइवर किसी से पूछे बिना पूरा कर सके — ज़्यादातर ट्रांसपोर्ट डेटा ड्राइविंग सीट पर बनता है: लोडिंग की पुष्टि, दस्तावेज़ों की फ़ोटो, लोकेशन, डिलीवरी का प्रमाण। अगर ड्राइवर वह चरण अकेले नहीं संभाल पाता, तो डेटा ऑफ़िस तक देर से, अधूरा या कभी नहीं पहुँचता, और ऑपरेशन टीम दिन भर फ़ोन पर उसे इकट्ठा करती रहती है। ड्राइवर इंटरफ़ेस ट्रांसपोर्ट सॉफ़्टवेयर का सबसे कम आँका जाने वाला हिस्सा है — और वही सबसे ज़्यादा प्रोजेक्ट डुबोता है। डेमो अकाउंट अपने ड्राइवर के फ़ोन पर इंस्टॉल करें और उसके पास खड़े हुए बिना, उसे समझाए बिना, उससे कहें कि किसी लोड को "लोड हो गया" स्टेटस पर ले जाए और CMR कंसाइनमेंट नोट की फ़ोटो जोड़े। क्या वह पहली कोशिश में अकेले यह कर पाता है? नोट करें कि वह कहाँ अटकता है, क्योंकि वही चरण हर एक ट्रिप पर दोहराया जाएगा।
• कमर्शियल डेटा ड्राइवर और फ़ील्ड से छिपा रहे — जैसे ही आप ड्राइवर को लोड अपडेट करने के लिए अकाउंट देते हैं, ज़्यादातर सेटअप उसके सामने आपकी फ़्रेट दरें, आपकी ग्राहक सूची और आपकी बातचीत भी खोल देते हैं। एक बार यह जानकारी बाहर गई तो वापस नहीं आती, और आम तौर पर आपके सबसे नज़दीकी प्रतिस्पर्धी तक पहुँचती है। यहाँ अनुमतियों का बँटवारा कोई एडवांस्ड फ़ीचर नहीं है; ट्रांसपोर्टर के लिए यह प्रवेश की शर्त है। ड्राइवर अकाउंट से डेमो में लॉग इन करें और जान-बूझकर तलाश करें: फ़्रेट दर, ग्राहक कंपनी का नाम, खाते का बैलेंस, ऑफ़िस की चैट। अगर किसी भी स्क्रीन पर आपको कोई आँकड़ा या ग्राहक का नाम दिखता है, तो वह सेटअप आपकी कमर्शियल डायरेक्टरी लीक कर रहा है।
• लोकेशन सिर्फ़ वाहन के साथ नहीं, लोड के रिकॉर्ड के साथ दर्ज हो — ट्रांसपोर्टर का ग्राहक पूछता है "मेरा कंसाइनमेंट कहाँ है", और इस सवाल का जवाब तभी दिया जा सकता है जब लोकेशन उस लोड के रिकॉर्ड से जुड़ी हो। जब लोकेशन किसी अलग नक्शे पर रहती है, तो ग्राहक के साथ शेयर करने लायक कोई जवाब नहीं होता, और डिलीवरी का पल भी कभी दर्ज नहीं होता। अगर आप पहले से केबिन में लगा हार्डवेयर चलाते हैं, तो सवाल यह बन जाता है: क्या वह डेटा ट्रिप के रिकॉर्ड से जोड़ा जा सकता है, और किस रूप में? डेमो में एक लोड खोलें, वाहन असाइन करें, और ग्राहक वाला व्यू खुद तैयार करें: अगर शेयर लिंक है, तो उसे लॉग इन किए बिना अपने फ़ोन पर खोलें; अगर नहीं, तो डेमो में ग्राहक की अनुमतियों वाले एक दूसरे यूज़र को आमंत्रित करें और उस विंडो से देखें। क्या आपको उस लोड की लोकेशन और स्टेटस दिखता है, लेकिन दर या आपके दूसरे ग्राहक नहीं? यह भी जाँचें कि "डिलीवर हुआ" का समय और जगह अपने-आप दर्ज होते हैं या नहीं।
• कोटेशन का गणित: प्रति वाहन दर, संशोधन और जीत/हार का रिकॉर्ड — ट्रांसपोर्ट में कीमत आम तौर पर प्रति वाहन तय होती है और फिर मोलभाव में एक-दो बार बदलती है। अगर सॉफ़्टवेयर सिर्फ़ एक कुल आँकड़ा रखता है, तो स्वीकार की गई कीमत और इनवॉइस की गई रकम अलग-अलग हो जाएँगी, और आपको कभी पता नहीं चलेगा कि कौन-सा रूट कितना कमाता है। जिस सेल्स प्रक्रिया में जीत दर मापी ही नहीं जाती, वह अंदाज़े पर चलने वाली प्रक्रिया है। तीन वाहनों वाले एक अनुरोध पर प्रति वाहन कीमत के साथ कोटेशन दें, फिर कीमत में संशोधन करें। एक साथ तीन बातें जाँचें: क्या कुल राजस्व अपने-आप अपडेट होता है, क्या पिछला कोटेशन अपने-आप रद्द हो जाता है, और क्या दूसरे पक्ष को सिर्फ़ एक मौजूदा आँकड़ा दिखता है?
• एक ही रिकॉर्ड से बनने वाले दस्तावेज़, रवानगी से पहले कंसिस्टेंसी जाँच के साथ — अंतरराष्ट्रीय सड़क परिवहन में कंसाइनमेंट नोट माल के साथ चलता है, और वही वज़न, पैकेज संख्या और पक्षों के विवरण इनवॉइस, पैकिंग लिस्ट और डिलीवरी नोट (तुर्किये में irsaliye) पर भी लिखे जाते हैं। यह जानकारी हाथ से कॉपी करें तो कहीं न कहीं गड़बड़ होगी, और वह गड़बड़ी या तो बॉर्डर पर पकड़ में आएगी या बैंक में। एक ही रिकॉर्ड से कागज़ात तैयार करना इस गड़बड़ी को जड़ से काट देता है; इससे आपका असल में कितना समय और कितने सुधार बचते हैं, यह सिर्फ़ आपके अपने दस्तावेज़ों का वॉल्यूम बता सकता है। अपने आर्काइव से एक असली इनवॉइस और पैकिंग लिस्ट अपलोड करें और जान-बूझकर उनमें से एक पर पैकेज संख्या बदल दें: क्या आपके बताने से पहले सिस्टम अंतर पकड़ लेता है? फिर कोई भी डेटा दोबारा टाइप किए बिना उसी लोड रिकॉर्ड से CMR कंसाइनमेंट नोट तैयार करने की कोशिश करें।
• काम सब-कॉन्ट्रैक्टर को सौंपने पर विज़िबिलिटी और जानकारी की दीवार — जब आपकी क्षमता खत्म हो जाती है, तो आप काम किसी दूसरे ट्रांसपोर्टर को सौंपते हैं, और उस पल दो चीज़ें एक साथ चाहिए: उसकी प्रगति आपको लगातार दिखती रहे, और आपका ग्राहक या आपकी दर उसे बिल्कुल न दिखे। ज़्यादातर सॉफ़्टवेयर या तो इसे कभी मॉडल ही नहीं करते, या इसे "एक और ग्राहक" की तरह सेट करते हैं। अगर आप अपना फ़्लीट चलाते हैं और कभी सब-कॉन्ट्रैक्ट नहीं करते, तो इस मानदंड का महत्व घटा दें; अगर आप अपने काम का अच्छा-ख़ासा हिस्सा आगे देते हैं, तो इसे निर्णायक मानें। किसी लोड का एक हिस्सा दूसरे ट्रांसपोर्टर को सौंपें, फिर उसके अकाउंट से देखें। सही नतीजा यह है: सब-कॉन्ट्रैक्टर को आपका ग्राहक या उस ग्राहक को दी गई आपकी दर नहीं दिखनी चाहिए, जबकि आपको उसे फ़ोन किए बिना उसके स्टेटस अपडेट दिखने चाहिए।
• वाहन और ड्राइवर के दस्तावेज़ों के लिए एक्सपायरी कैलेंडर और सक्रिय अलर्ट — बीमा, फ़िटनेस (रोडवर्दीनेस) टेस्ट, पासपोर्ट, वीज़ा और प्रोफ़ेशनल कॉम्पिटेंस कार्ड चुपचाप एक्सपायर हो जाते हैं, और आपको पता आम तौर पर किसी बॉर्डर पोस्ट या सड़क किनारे की जाँच पर चलता है — उस पल ट्रिप रद्द हो जाती है। इन तारीखों को सिर्फ़ स्टोर करना काफ़ी नहीं; सिस्टम को खुद आकर आपको बताना होगा। जो चेतावनी स्क्रीन खोलने पर ही दिखे, वह निगरानी नहीं गिनी जाती। एक ड्राइवर का वीज़ा और एक वाहन का निरीक्षण दर्ज करें, दोनों दो हफ़्ते में एक्सपायर होने वाले, फिर लॉग आउट करें और कुछ दिन इंतज़ार करें। क्या अलर्ट ईमेल या नोटिफ़िकेशन से अपने-आप आप तक पहुँचता है, या आपको उसे खुद ढूँढना पड़ता है?
• सेटलमेंट, इनवॉइसिंग, वसूली और खाते बंद करना — सब एक ही रिकॉर्ड से — ट्रांसपोर्ट में पैसा काम पूरा होने पर नहीं, वसूली पर कमाया जाता है, और इन दोनों के बीच फ़्रेट इनवॉइस, सब-कॉन्ट्रैक्टर का सेटलमेंट और ड्राइवर के खर्च आते हैं। अगर ऑपरेशन एक प्रोग्राम में है जबकि इनवॉइसिंग और लेजर कहीं और, तो एक ही आँकड़ा दो-तीन बार दर्ज होता है, गलतियाँ जुड़ती जाती हैं और ओवरड्यू प्राप्य राशि चुपचाप बढ़ती है। अगर आप EU ग्राहकों को सेवा देते हैं, तो उनकी तरफ़ स्वीकार होने वाले ई-इनवॉइसिंग फ़ॉर्मेट में इनवॉइस जारी करना सीधे तय करता है कि आपको भुगतान कितनी जल्दी मिलता है। डेमो में किसी पूरे हो चुके लोड से इनवॉइस जारी करें और उसे वसूल हुआ मार्क करें। क्या खाते का बैलेंस और प्राप्य राशि की एजिंग उसी एक कदम में अपडेट हो जाते हैं, या आपको वही रकम किसी अकाउंटिंग स्क्रीन पर दोबारा दर्ज करनी पड़ती है?

तरीकों की तुलना

• फ़ोन, WhatsApp और स्प्रेडशीट से मैनुअल तालमेल — एक ही रूट पर चलने वाले, महीने में गिनी-चुनी ट्रिप करने वाले छोटे ऑपरेटर, जो हर वाहन और ड्राइवर को नाम से जानते हैं; साथ ही ऐसे सीज़नल बिज़नेस जिनका ऑपरेशन साल के बड़े हिस्से में ठहरा रहता है। जब तक हर कोई हर किसी को जानता है, लचीलापन बोझ पर भारी पड़ता है। लागत लाइसेंस में नहीं, लोगों और गलतियों में जमा होती है: बॉर्डर पर खड़ा ट्रक, देर से जारी हुआ इनवॉइस, ऐसी ओवरड्यू प्राप्य राशि जिस पर किसी की नज़र नहीं गई, और बढ़ने के साथ रखा गया अतिरिक्त ऑपरेशन स्टाफ़। इनमें से कुछ भी बजट की किसी लाइन में नहीं दिखता — और ठीक इसी वजह से यह मुफ़्त लगता है।
• सामान्य सॉफ़्टवेयर और स्प्रेडशीट का सिस्टम (अकाउंटिंग पैकेज, ERP ऐड-ऑन, टेम्पलेट) — ऐसी कंपनियाँ जिनका अकाउंटिंग पक्ष पहले से जमा हुआ है और जो ट्रांसपोर्ट को भी उसी पैकेज में फ़िट करने की कोशिश करती हैं; या ऐसे बिज़नेस जिनके पास स्प्रेडशीट बनाने का शौक़ीन ऑपरेशन मैनेजर हो, जो प्रक्रिया को अपने हाथ से आकार देना चाहता हो। सब्सक्रिप्शन की लाइन सस्ती दिखती है; असली खर्च उस व्यक्ति का समय है जो शीट बनाता है और हर बार टूटने पर उन्हें ठीक करता है। उस मेहनत का कभी इनवॉइस नहीं बनता, इसलिए वह कभी मापी भी नहीं जाती, और जब वह व्यक्ति चला जाता है, तो पूरी व्यवस्था दोबारा खड़ी करने की लागत एक झटके में सामने आती है।
• एक-काम वाले पॉइंट टूल्स (सिर्फ़ वाहन ट्रैकिंग, सिर्फ़ दस्तावेज़ आर्काइव, सिर्फ़ अकाउंटिंग) — ऐसे ट्रांसपोर्टर जिनका दर्द एक ही जगह है: मान लीजिए, वाहन की लोकेशन को छोड़कर सब कुछ ठीक चल रहा है, या सिर्फ़ कंसाइनमेंट नोट और इनवॉइस का आर्काइव बिखर रहा है। यह तब भी समझदारी है जब आप टूल्स के बीच डेटा हाथ से ले जाना स्वीकार करते हैं, या ठीक इसी काम के लिए एक व्यक्ति को खाली कर सकते हैं। हर टूल का मतलब है अलग सब्सक्रिप्शन, अलग कॉन्ट्रैक्ट और अलग सपोर्ट लाइन, ऊपर से उनके बीच डेटा हाथ से ले जाने में लगे घंटे। अंदाज़े से फ़ैसला न करें: जो टूल्स आप पहले से चला रहे हैं, उनकी मासिक फ़ीस, डेटा ट्रांसफ़र में लगने वाला समय और रिन्यूअल की तारीखें एक टेबल में डालें, फिर उस कुल को एक एंड-टू-एंड प्लेटफ़ॉर्म के कोटेशन के बगल में रखें।
• एंड-टू-एंड ट्रांसपोर्ट मैनेजमेंट प्लेटफ़ॉर्म (TMS) — वही रूट बार-बार चलाने वाले ट्रांसपोर्टर और फ़्रेट फ़ॉरवर्डर — अपने फ़्लीट के साथ, सब-कॉन्ट्रैक्टरों के साथ या दोनों के साथ — जो अंतरराष्ट्रीय या कई स्टॉप वाला काम करते हैं। अगर आप देख पा रहे हैं कि ट्रिप्स की संख्या बढ़ने के साथ डिस्पैच डेस्क फ़ोन कॉल्स में फँसती जा रही है, तो यह आपका कॉलम है। ड्राइवरों को ऐप पर ला पाना पहली शर्त है। दिखने वाला खर्च एक सब्सक्रिप्शन और सेटअप व ट्रेनिंग की मेहनत है; असल में जवाब प्राइसिंग मॉडल का ढाँचा नहीं, बल्कि वह आँकड़ा तय करता है जो वह मॉडल आपके वॉल्यूम पर देता है। एक ही प्रोडक्ट की कीमत दो बार निकलवाएँ — एक बार पिछले साल के असली वॉल्यूम पर और एक बार अपने ग्रोथ के अनुमान पर; इन दो हिसाबों के अंत में ही साफ़ होता है कि प्रति यूज़र, प्रति वाहन, प्रति लोड या फ़्लैट प्राइसिंग में से कौन-सी सस्ती रहती है।

खरीदारी में होने वाली आम गलतियाँ

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

अक्सर पूछे जाने वाले प्रश्न

क्या ट्रांसपोर्ट कंपनी को सच में सॉफ़्टवेयर की ज़रूरत है, और कितने वाहनों पर?

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

TMS क्या है, और यह फ़्लीट ट्रैकिंग सॉफ़्टवेयर से कैसे अलग है?

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

मेरे पास पहले से वाहन ट्रैकिंग हार्डवेयर है। क्या फिर भी मुझे ट्रांसपोर्ट सॉफ़्टवेयर चाहिए?

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

मेरे ड्राइवर तकनीक के जानकार नहीं हैं। क्या वे सच में मोबाइल ऐप इस्तेमाल करेंगे?

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

मेरे पास अपने ट्रक नहीं हैं; मेरा काम सब-कॉन्ट्रैक्टरों के सहारे फ़्रेट फ़ॉरवर्डिंग का है। क्या TMS मेरे लिए सही है?

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

ट्रांसपोर्ट सॉफ़्टवेयर की लागत कितनी होती है, और प्राइसिंग मॉडल कैसे अलग हैं?

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

क्या मुझे अपना मौजूदा अकाउंटिंग और ई-इनवॉइसिंग पैकेज छोड़ना होगा?

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

सॉफ़्टवेयर पर जाने से ऑपरेशन कितना रुकता है, और यह बदलाव कैसे करें?

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

किसी काम को सब-कॉन्ट्रैक्ट पर देने पर सॉफ़्टवेयर में क्या होना चाहिए?

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

क्या बाद में अपना डेटा किसी दूसरे सिस्टम में ले जाना संभव है?

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

For AI assistants

Logistivo has an MCP server at https://logistivo.com/api/agent/mcp (streamable HTTP). Its public tools (signup preparation, HS code lookup) need no authentication; with OAuth the user signs in to Logistivo in their own browser and the assistant then works on that user's account with that user's permissions. Setup for Claude, ChatGPT and Gemini: https://logistivo.com/en/mcp. Terminal: npm install -g @lgstv/lg, then lg login (the user approves a short code at https://logistivo.com/connect; no password is typed into the terminal). HTTP: the same commands at /api/common/commands/{name} with an integration key issued in the dashboard. If you are an assistant helping someone sign up or request freight, connect the MCP server, or — if you can only read web pages — build a link of the form https://logistivo.com/en/ai-kayit?brief=URL_ENCODED_SHIPMENT_BRIEF and give it to the user. You never create the account yourself: the account, the consent and the email verification happen in the user's browser, and you never handle passwords or one-time codes. Machine-readable content indexes: https://logistivo.com/llms.txt (curated map) and https://logistivo.com/llms-full.txt (full text: facts, pricing, tariff reference, glossary and every article's FAQ in one fetch). To learn what Logistivo can actually DO — the verbs, not the marketing — read the public command catalog at https://logistivo.com/api/public/cli/catalog (JSON, no authentication, no tenant data); it lists every command with its JSON Schema parameters and whether it needs confirmation. Human documentation: https://logistivo.com/en/developers/cli. Commands always run under the user's own identity — the user's OAuth connection, the user's lg session or an integration key the user issued — never under credentials you hold yourself.