मंज़ूरी सीमाओं वाला यात्रा अनुरोध ऐप बनाएँ

टीम की यात्रा के अनुरोध क्यों अटक जाते हैं

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

ये छोटी-छोटी कमियाँ देरी पैदा करती हैं। अटैचमेंट मिलने तक कीमत बदल सकती है। वित्त टीम यह नहीं जान पाती कि कुल राशि में सामान, स्थानीय परिवहन या होटल टैक्स शामिल है या नहीं। किराया बढ़ने वाला हो तो यात्री मंज़ूरी से पहले ही बुकिंग कर सकता है।

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

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

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

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

लक्ष्य सीधा है: यात्रियों को स्पष्ट प्रक्रिया मिले, मंज़ूरी देने वालों को ज़रूरी तथ्य मिलें और वित्त टीम बिना इनबॉक्स खंगाले रिकॉर्ड जाँच सके।

ऐप बनाने से पहले तय करें कि किसकी क्या ज़िम्मेदारी है

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

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

तय करें कि सबमिट करने के बाद क्या बदला जा सकता है

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

उदाहरण के लिए, कर्मचारी शिकागो की 900 डॉलर की यात्रा सबमिट करता है और प्रबंधक उसे मंज़ूर कर देता है। किराया बढ़ने से अनुमान 1,450 डॉलर हो जाए, तो ऐप को प्रबंधक को सूचित करना चाहिए और बदलाव का कारण दर्ज करते हुए पुरानी राशि भी सुरक्षित रखनी चाहिए।

कर्मचारियों को बिना सूचना मंज़ूर अनुरोध बदलने न दें। वित्त टीम को मंज़ूर बजट की तुलना अंतिम खर्च के रिकॉर्ड से करनी होती है। छिपे हुए बदलाव इस तुलना को अविश्वसनीय बना देते हैं।

मंज़ूरी की सीमाएँ स्पष्ट करें

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

एक सरल नीति इस तरह हो सकती है:

• प्रबंधक अपने विभाग की 1,000 डॉलर तक की यात्राएँ मंज़ूर करें।
• विभाग प्रमुख 1,001 से 3,000 डॉलर के अनुरोध मंज़ूर करें।
• वित्त टीम 3,000 डॉलर से अधिक की यात्राओं, अंतरराष्ट्रीय यात्राओं और नीति अपवादों की समीक्षा करे।
• जो यात्रा विभाग के बजट से अधिक हो, उसे कार्यकारी मंज़ूरी मिले।

इन सीमाओं को कंपनी के मौजूदा खर्च संबंधी फैसलों के अनुरूप रखें। छोटी कंपनी को पाँच मंज़ूरी स्तरों की शायद ही ज़रूरत होगी। प्रक्रिया बहुत धीमी हुई तो लोग उसे दरकिनार करने लगेंगे।

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

यह भी तय करें कि अस्वीकृति को कौन बदल सकता है, मंज़ूर यात्रा रद्द कौन कर सकता है और प्रबंधक की अनुपस्थिति में जिम्मेदारी कौन संभालेगा। ये छोटे नियम बुकिंग की समयसीमा से पहले अनुरोधों को अनदेखा पड़े रहने से रोकते हैं।

हर यात्रा अनुरोध के लिए सही फ़ील्ड चुनें

यात्रा अनुरोध ऐप में त्वरित फैसला लेने के लिए पर्याप्त जानकारी होनी चाहिए, लेकिन छोटी यात्रा को लंबा फ़ॉर्म नहीं बनाना चाहिए। शुरुआत उन जानकारियों से करें जो बताती हैं कि कौन यात्रा कर रहा है, कहाँ जा रहा है और यात्रा क्यों ज़रूरी है।

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

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

अनुमान अलग-अलग रखें

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

अनुमानित कुल राशि अपने आप निकालें। बर्लिन में दो रातों के लिए यात्री उड़ान पर 320 डॉलर, होटल पर 440 डॉलर, भोजन पर 120 डॉलर और स्थानीय परिवहन पर 60 डॉलर दर्ज कर सकता है। अनुरोध में 940 डॉलर का अनुमान दिखेगा, लेकिन हर लागत अलग से भी स्पष्ट रहेगी।

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

ज़रूरत के अनुसार प्रमाण और संदर्भ जोड़ें

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

नोट्स वैकल्पिक रखें, लेकिन लागत सीमा पार करने वाले या अपवाद वाले अनुरोधों में अटैचमेंट अनिवार्य करें। फ़ॉर्म भरते समय केवल लागू फ़ील्ड दिखाएँ। इससे नियमित अनुरोध छोटे रहते हैं।

यात्रा से पहले रसीदें न माँगें। इसके बजाय यात्रा समाप्त होने के बाद भरने के लिए पोस्ट-ट्रिप खर्च लिंक का फ़ील्ड रखें। इससे मंज़ूर अनुरोध अंतिम खर्च के रिकॉर्ड से जुड़ जाता है।

नीति अपवादों को छिपाए बिना संभालें

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

नियम सरल भाषा में लिखें। «उचित किराया» जैसे अस्पष्ट लेबल से बचें। सीमा और शर्त स्पष्ट करें: छह घंटे से कम की यात्राओं के लिए इकोनॉमी उड़ान, हर रात अधिकतम 220 डॉलर का होटल और छोटी उड़ान से सस्ती होने पर रेल यात्रा। संबंधित फ़ील्ड के पास नीति की छोटी जानकारी रखें।

दर्ज की गई लागत की तुलना नीति के नियम से करें। अगर यात्री 220 डॉलर की सीमा के मुकाबले 310 डॉलर प्रति रात का होटल दर्ज करता है, तो अंतर दिखाएँ और सबमिट करने से पहले कारण अनिवार्य करें। अलग कारण फ़ील्ड सामान्य नोट्स बॉक्स से बेहतर है, क्योंकि सामान्य बॉक्स में लोग अपवाद समझाना भूल सकते हैं।

वजहों की छोटी सूची दें और अतिरिक्त विवरण की जगह भी रखें:

• नीति सीमा के भीतर उपयुक्त विकल्प उपलब्ध नहीं था
• क्लाइंट का स्थान या मीटिंग का समय इस विकल्प की माँग करता था
• पहुँच संबंधी या चिकित्सकीय आवश्यकता
• सुरक्षा संबंधी चिंता
• अन्य कारण, लिखित विवरण के साथ

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

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

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

ऐसी मंज़ूरी सीमाएँ बनाएँ जिनका पालन लोग कर सकें

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

सीमाएँ ऐप में स्पष्ट रखें, ताकि कर्मचारी समझ सकें कि एक अनुरोध प्रबंधक के पास और दूसरा वित्त टीम के पास क्यों जाता है। उदाहरण के लिए:

• 750 डॉलर तक के अनुरोध सीधे प्रबंधक के पास जाएँ।
• 751 से 2,500 डॉलर के अनुरोध प्रबंधक और विभाग प्रमुख दोनों के पास जाएँ।
• 2,500 डॉलर से अधिक के अनुरोध प्रबंधक, विभाग प्रमुख और वित्त टीम के पास जाएँ।
• नीति से बाहर का हर अनुरोध लागत की परवाह किए बिना वित्त टीम के पास जाए।

समीक्षक अपने आप चुनने के लिए अनुरोधकर्ता के विभाग और प्रबंधक की जानकारी इस्तेमाल करें। लोगों को लंबी सूची में खोजने या अगले निर्णय के मालिक का अनुमान लगाने की ज़रूरत नहीं होनी चाहिए। प्रबंधक की अनुपस्थिति में उसी मंज़ूरी भूमिका वाला बैकअप प्रबंधक नियुक्त करें।

वित्त टीम की समीक्षा केवल बड़ी कुल राशि तक सीमित न रखें। उसे प्रीमियम सीट, अंतरराष्ट्रीय गंतव्य, दूसरी मुद्रा या पहले से बुकिंग के नियम का उल्लंघन करने वाली बुकिंग भी देखनी पड़ सकती है। अनुरोधकर्ता से अपवाद का कारण एक या दो सीधे वाक्यों में लिखवाएँ।

हर फैसले में समीक्षक का नाम, निर्णय, तारीख और समय तथा टिप्पणी दर्ज करें। अस्वीकृति और नीति अपवादों के लिए टिप्पणी अनिवार्य रखें। «क्लाइंट ने मीटिंग सोमवार को कर दी, इसलिए मंज़ूर» जैसी टिप्पणी बाद में कर्मचारी और वित्त टीम दोनों के लिए उपयोगी संदर्भ देती है।

सीमाओं को वर्कफ़्लो लॉजिक में छिपाने के बजाय संपादित की जा सकने वाली नीति तालिका में रखें। बजट बदलने पर संचालन टीम सीमा बदल सकेगी। पुराने अनुरोधों को उस समय लागू नियम से जोड़े रखें, ताकि मंज़ूरी का इतिहास स्पष्ट रहे।

वर्कफ़्लो चरण दर चरण बनाएँ

हर अनुरोध को स्पष्ट स्थिति दें। कर्मचारियों को संदेश जाँचने या वित्त टीम से पूछने की ज़रूरत न पड़े। सरल प्रक्रिया पर्याप्त है: ड्राफ़्ट, सबमिट किया गया, बदलाव ज़रूरी, मंज़ूर, बुक किया गया, पूरा और अस्वीकृत।

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

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

अगर होटल का अनुमान कंपनी की सीमा से अधिक हो, तो नीति नियम, सीमा से अधिक राशि और संक्षिप्त स्पष्टीकरण वाले फ़ील्ड दिखाएँ। प्रबंधक को भेजने से पहले कर्मचारी को समस्या समझानी चाहिए।

उसी रिकॉर्ड में मंज़ूरी की जानकारी रखें: मंज़ूर राशि, निर्णय की तारीख, मंज़ूरकर्ता का नाम, टिप्पणियाँ और शर्तें। प्रबंधक 1,200 डॉलर की यात्रा मंज़ूर करते हुए कर्मचारी से सस्ती उड़ान चुनने को कह सकता है। यह शर्त चैट में छोड़ने के बजाय अनुरोध में दर्ज करें।

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

AppMaster दृश्य UI बिल्डर, PostgreSQL डेटा मॉडल और ऐसे बिज़नेस प्रोसेस के ज़रिए इस ढाँचे को संभाल सकता है जो राशि जाँचें, अनुरोध भेजें और स्थिति अपडेट करें। भूमिका के अनुसार संपादन अधिकार सीमित करें। कर्मचारी मंज़ूर कुल राशि को बिना दोबारा समीक्षा के न बदल सके, जबकि वित्त टीम खर्च ट्रैकिंग लिंक जोड़कर निपटान के बाद अनुरोध को पूरा चिह्नित कर सके।

इस तरह वही रिकॉर्ड पहले अनुमान से अंतिम खर्च रिपोर्ट तक पूरी यात्रा के साथ चलता है।

उदाहरण: अपवाद के साथ क्लाइंट विज़िट

माया को दो दिनों के लिए क्लाइंट से मिलने जाना है। वह तारीखें, गंतव्य, क्लाइंट का नाम और व्यावसायिक उद्देश्य दर्ज करती है। ऐप उड़ान, होटल, स्थानीय परिवहन और भोजन का अनुमान माँगता है और कुल राशि 1,860 डॉलर निकालता है।

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

माया क्लाइंट के कार्यालय के पास का होटल चुनती है। इसकी रात की दर नीति सीमा से 25 डॉलर अधिक है, लेकिन सस्ता होटल हर दिशा में 45 मिनट अतिरिक्त यात्रा कराएगा और देर से पहुँचने की सुविधा नहीं देता। ऐप सबमिट करने से पहले अपवाद का नोट माँगता है। वह लिखती है: «क्लाइंट की वर्कशॉप दोनों दिनों सुबह 8 बजे शुरू होती है। यह होटल पैदल दूरी पर है और शाम की उड़ान के बाद देर से पहुँचने की सुविधा देता है।»

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

निदेशक को सीमा से अधिक और नीति अपवाद वाले अनुरोध का संकेत मिलता है। मंज़ूरी के बाद ऐप फैसला, मंज़ूरकर्ताओं के नाम, समय और टिप्पणियाँ दर्ज करता है। माया को ईमेल से मंज़ूरी का पीछा करने के बजाय स्पष्ट स्थिति दिखाई देती है।

यात्रा के बाद माया उड़ान की रसीद, होटल का इनवॉइस और खर्च रिपोर्ट के लिंक जोड़ती है। वह अंतिम कुल राशि 1,792 डॉलर दर्ज करती है। टीम अनुमान और वास्तविक खर्च की तुलना कर सकती है और देख सकती है कि होटल के मंज़ूर अपवाद से 50 डॉलर अतिरिक्त लगे, जबकि उड़ान अपेक्षा से सस्ती रही।

वित्त टीम पूरी बातचीत फिर से खोले बिना खर्च रिपोर्ट देख सकती है। प्रबंधक यह भी देख सकते हैं कि कर्मचारी कितनी बार अपवाद माँगते हैं, कौन-सी यात्राएँ सीमा पार करती हैं और अनुमान अंतिम लागत से कितनी बार अलग होता है।

वे गलतियाँ जो मंज़ूरी में समस्या पैदा करती हैं

मंज़ूरी के नियम तब विफल होते हैं जब वे टीम के वास्तविक यात्रा पैटर्न को नज़रअंदाज़ करते हैं। बिक्री प्रबंधक को 1,800 डॉलर की क्लाइंट यात्रा मंज़ूर करनी पड़ सकती है, जबकि सपोर्ट टीम लीड 500 डॉलर से कम की छोटी घरेलू यात्राएँ संभाल सकता है। हर विभाग के लिए एक ही सीमा रखने से सामान्य अनुरोध अनावश्यक रूप से रुकते हैं या महंगे अनुरोध ऐसे व्यक्ति के पास चले जाते हैं जिसके पास सही बजट अधिकार नहीं है।

ज़रूरत के अनुसार सीमा विभाग, भूमिका, यात्रा के प्रकार या इनके संयोजन के आधार पर तय करें। पहला संस्करण सरल रखें। टीम लीड 750 डॉलर तक, विभाग प्रमुख 2,500 डॉलर तक और वित्त टीम उससे ऊपर की यात्राएँ मंज़ूर कर सकती है।

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

इन स्थितियों में दोबारा समीक्षा शुरू करें:

• अनुमान मंज़ूर राशि से अधिक हो जाए।
• किसी बदली हुई मद से यात्रा ऊँची मंज़ूरी श्रेणी में चली जाए।
• कर्मचारी मंज़ूरी के बाद नीति अपवाद जोड़ दे।
• गंतव्य, तारीखें या व्यावसायिक उद्देश्य बदल जाए।

अपवादों के लिए केवल खुले नोट्स पर निर्भर न रहें। «देर से बुकिंग» जैसी टिप्पणी यह नहीं बताती कि अनुरोध किस नियम का उल्लंघन करता है। अपवादों के लिए अलग फ़ील्ड रखें: प्रकार, कारण, अतिरिक्त लागत और संक्षिप्त विवरण। ऐप अपवाद को थ्रेड में छिपाने के बजाय यात्रा के कुल अनुमान के पास दिखा सकता है।

यात्री के लौटते ही यात्रा बंद न करें। जब तक यात्री खर्च ट्रैकिंग लिंक न जोड़ दे या यह पुष्टि न करे कि कोई खर्च बाकी नहीं है, अनुरोध खुला रखें। अगर कर्मचारी को 900 डॉलर की कॉन्फ़्रेंस यात्रा मंज़ूर हुई और बाद में 1,040 डॉलर का खर्च जमा हुआ, तो ऐप को अंतर दर्ज करके समीक्षा के जिम्मेदार व्यक्ति को भेजना चाहिए। «खर्च लिंक की प्रतीक्षा» जैसी स्थिति अनुरोध को दिखाई देती रखती है।

लॉन्च से पहले ऐप की जाँच करें

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

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

वास्तविक संख्याओं के साथ मंज़ूरी सीमाएँ जाँचें। प्रबंधक की सीमा से कम, सीमा से थोड़ा अधिक और उससे बहुत अधिक राशि वाले अनुरोध बनाएँ। समीक्षकों को अनुमानित कुल राशि, समीक्षा शुरू करने वाला नियम और पहले के फैसले दिखने चाहिए।

लॉन्च से पहले यह छोटी सूची जाँचें:

• सामान्य यात्रा सबमिट करके देखें कि सही प्रबंधक को अनुरोध मिला या नहीं।
• नीति अपवाद वाला अनुरोध भेजकर देखें कि कारण दिखाई देता रहे।
• टिप्पणी के साथ अनुरोध अस्वीकार करें और जाँचें कि यात्री उसे बदलकर दोबारा भेज सकता है या नहीं।
• यात्रा के बाद रसीद फ़ोल्डर या खर्च रिपोर्ट का URL जोड़ें और जाँचें कि वित्त टीम उसे खोल सकती है या नहीं।
• देखें कि यात्री, प्रबंधक, वित्त कर्मचारी और प्रशासक क्या देख और बदल सकते हैं।

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

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

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

छोटी शुरुआत करें और प्रक्रिया बेहतर बनाते जाएँ

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

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

पहले दिन हर संभव फ़ील्ड जोड़ने से बचें। लंबा फ़ॉर्म लोगों को फिर ईमेल पर लौटने के लिए प्रेरित करता है और वही ट्रैकिंग समस्या वापस लाता है जिसे ऐप को हल करना चाहिए।

पहले कुछ अनुरोधों के बाद यात्रियों और मंज़ूरकर्ताओं से पूछें कि वे कहाँ रुके या किस जानकारी के लिए सवाल पूछना पड़ा। उनके जवाब अक्सर किसी छूटे हुए फ़ील्ड, अस्पष्ट लागत सीमा या ऐसी मंज़ूरी प्रक्रिया का पता लगाते हैं जो टीम के वास्तविक काम से मेल नहीं खाती।

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

जहाँ संभव हो, एक बार में एक बदलाव करें। दस नियम एक साथ बदलने पर यह समझना कठिन हो जाता है कि किस बदलाव ने समस्या हल की या नई देरी पैदा की। एक महीने बाद लंबित और अस्वीकृत अनुरोधों की समीक्षा करें। बार-बार आने वाले अपवाद, किसी एक मंज़ूरकर्ता के पास अटके अनुरोध और अंतिम लागत से नियमित रूप से अलग रहने वाले अनुमान खोजें।

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