बिज़नेस फ़ॉर्म के डेटा वैलिडेशन नियम जो दोबारा होने वाला काम घटाएँ

बिज़नेस फ़ॉर्म दोबारा होने वाला काम क्यों बढ़ाते हैं

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

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

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

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

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

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

पहले यह तय करें कि लोगों को कौन-सी जानकारी चाहिए

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

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

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

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

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

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

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

ज़रूरी फ़ील्ड सोच-समझकर तय करें

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

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

सबमिट दबाने से पहले दिखाएँ कि कौन-सी फ़ील्ड ज़रूरी हैं। «ईमेल पता (ज़रूरी)» जैसे स्पष्ट लेबल का इस्तेमाल करें और पूरे फ़ॉर्म में एक जैसा तरीका रखें। केवल रंग पर निर्भर न रहें।

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

• «ऑफिस ईमेल (ज़रूरी): [email protected]»
• «ऑर्डर नंबर (ज़रूरी): अपनी रसीद पर दिया गया 8 अंकों का नंबर इस्तेमाल करें»
• «पसंदीदा संपर्क तारीख (ज़रूरी): भविष्य की तारीख चुनें»

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

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

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

टकराव पकड़ने वाली क्रॉस-फ़ील्ड जाँच जोड़ें

कोई फ़ील्ड अपने आप में सही दिख सकती है, लेकिन किसी दूसरे जवाब के साथ मिलकर गलत अनुरोध बना सकती है। क्रॉस-फ़ील्ड वैलिडेशन फ़ॉर्म को आगे बढ़ाने से पहले इन संबंधों की जाँच करता है।

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

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

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

उपयोगी क्रॉस-फ़ील्ड वैलिडेशन नियमों में ये शामिल हैं:

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

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

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

डुप्लिकेट रिकॉर्ड को फैलने से पहले रोकें

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

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

नए रिकॉर्ड सेव करने से पहले उनकी तुलना पुराने रिकॉर्ड से करें। इनवॉइस नंबर, ऑर्डर आईडी और कर्मचारी आईडी के लिए सटीक मिलान अच्छी तरह काम करता है। नाम और पते के लिए थोड़ी लचीली तुलना चाहिए, क्योंकि लोग उन्हें अलग-अलग तरीके से लिखते हैं। «Maya Chen» और «Maya C. Chen» एक ही व्यक्ति हो सकते हैं, लेकिन फ़ॉर्म को यह मानकर नहीं चलना चाहिए।

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

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

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

AppMaster में Data Designer के अंदर यूनिक फ़ील्ड तय कर सकते हैं और रिकॉर्ड बनाने से पहले मिलान खोजने के लिए Business Process का इस्तेमाल कर सकते हैं। यह प्रोसेस वेब या मोबाइल फ़ॉर्म को संभावित मिलान लौटा सकता है और उपयोगकर्ता के अंतर की पुष्टि करने के बाद नया रिकॉर्ड सेव कर सकता है। इससे निर्णय स्पष्ट रहता है और रिकॉर्ड का सेट साफ़ रहता है।

ऐसे सुधार संदेश लिखें जिन पर लोग कार्रवाई कर सकें

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

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

अगली कार्रवाई बताने वाली सरल भाषा इस्तेमाल करें। «ERR-104» जैसे आंतरिक कोड डेवलपर के लिए उपयोगी हो सकते हैं, लेकिन ग्राहक अनुरोध भरने वाले सेल्स कोऑर्डिनेटर के लिए उनका कोई मतलब नहीं।

• «ऑफिस ईमेल डालें, जैसे [email protected]» लिखें, «ईमेल फ़ॉर्मैट अमान्य है» नहीं।
• «अंतिम तारीख शुरुआती तारीख के बराबर या उसके बाद होनी चाहिए» लिखें, «तारीख सीमा में त्रुटि» नहीं।
• «इस ईमेल वाला ग्राहक पहले से मौजूद है। नया रिकॉर्ड बनाने से पहले ग्राहक खोजें» लिखें, «डुप्लिकेट रिकॉर्ड» नहीं।
• «0 से अधिक राशि डालें» लिखें, «मान सीमा से बाहर है» नहीं।

अच्छा संदेश व्यक्ति को दोष दिए बिना समस्या समझाता है। «आपका अनुरोध सेव नहीं हो सका, क्योंकि अकाउंट नंबर में 8 अंक होने चाहिए» यह «आपने गलत अकाउंट नंबर डाला है» से अधिक स्पष्ट है।

फ़ॉर्म में त्रुटि मिलने पर सही भरी हुई जानकारी सुरक्षित रखें। जिसने 14 फ़ील्ड भर दी हों, उसे केवल गलत फ़ील्ड ठीक करनी पड़े। वैलिडेशन त्रुटि के बाद पूरा पेज खाली कर देना 20 सेकंड के सुधार को बार-बार होने वाले काम में बदल देता है।

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

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

वैलिडेशन नियम चरण-दर-चरण बनाएँ

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

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

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

हर परीक्षण के बाद देखें कि क्या होता है। क्या फ़ॉर्म ठीक उसी फ़ील्ड की ओर संकेत करता है? क्या पहले से भरी जानकारी सुरक्षित रहती है? क्या उपयोगकर्ता किसी सहकर्मी से पूछे बिना सुधार समझ सकता है?

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

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

ऐसी गलतियाँ जो फ़ॉर्म इस्तेमाल करने वालों को परेशान करती हैं

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

हर फ़ील्ड को अनिवार्य बनाना

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

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

बिना मार्गदर्शन के लोगों को रोकना

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

«ऑफिस का ईमेल पता डालें, जैसे [email protected]» लिखें, «ईमेल में त्रुटि» नहीं। अगर अंतिम तारीख शुरुआती तारीख से पहले है, तो कहें, «शुरुआती तारीख के बराबर या उसके बाद की अंतिम तारीख चुनें।» ऐसे निर्देश दोबारा कोशिश करने और सपोर्ट अनुरोधों को कम करते हैं।

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

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

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

प्रकाशित करने से पहले तुरंत की जाने वाली जाँचें

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

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

एक-दूसरे पर निर्भर फ़ील्ड का वास्तविक संयोजनों के साथ परीक्षण करें। डिलीवरी की अंतिम तारीख शुरुआती तारीख से पहले नहीं होनी चाहिए। अगर उपयोगकर्ता पसंदीदा संपर्क तरीके के रूप में «ईमेल» चुनता है, तो ईमेल पता फ़ील्ड अनिवार्य हो जानी चाहिए।

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

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

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

विफल परीक्षणों को लिखें और रिलीज़ से पहले उन्हें ठीक करें। वास्तविक परिस्थितियों में दस मिनट की जाँच फ़ॉर्म लाइव होने के बाद घंटों की सफ़ाई रोक सकती है।

उदाहरण: ग्राहक अनुरोध फ़ॉर्म

एक सेल्स कोऑर्डिनेटर को Northline Foods से कॉल आती है। यह कंपनी सर्विस कोट चाहती है। वह ग्राहक अनुरोध फ़ॉर्म खोलती है और कंपनी का नाम, संपर्क व्यक्ति का नाम, माँगी गई सर्विस, डिलीवरी की तारीख और छोटा विवरण भरती है।

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

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

फ़ॉर्म ग्राहक रिकॉर्ड बनाने से पहले कंपनी के नाम, ईमेल डोमेन और फ़ोन नंबर की मौजूदा रिकॉर्ड से डुप्लिकेट जाँच करता है। उसे उसी मुख्य फ़ोन नंबर वाला «Northline Food Ltd» मिलता है। फ़ॉर्म मौजूदा ग्राहक दिखाता है और कोऑर्डिनेटर को विकल्प देता है कि वह रिकॉर्ड खोलकर उसमें अनुरोध जोड़े या यह पुष्टि करे कि यह अलग कानूनी इकाई या संपर्क नंबर वाला नया ग्राहक है।

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

अपने अगले फ़ॉर्म में बेहतर वैलिडेशन जोड़ें

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

लिखें कि खराब एंट्री सबमिट होने के बाद क्या होता है। शायद सपोर्ट एजेंट को अकाउंट नंबर के लिए अनुरोधकर्ता को ईमेल करना पड़ता है या वित्त टीम को स्वीकृत अवधि से बाहर की तारीख वाले दावे लौटाने पड़ते हैं। सबसे आम सुधारों को बिज़नेस फ़ॉर्म के लिए स्पष्ट डेटा वैलिडेशन नियमों में बदलें।

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

फ़ॉर्म प्रकाशित करने के बाद देखें कि उपयोगकर्ताओं को कौन-सी त्रुटियाँ दिखाई देती हैं। बार-बार आने वाली त्रुटि का मतलब यह हो सकता है कि नियम काम कर रहा है, लेकिन यह भी संभव है कि लेबल, निर्देश या फ़ील्ड का क्रम लोगों को भ्रमित कर रहा हो। अगर बहुत से लोग ज़रूरी ऑफिस ईमेल की जगह व्यक्तिगत ईमेल डालते हैं, तो सबमिशन के बाद उसे अस्वीकार करने के बजाय पहले ही कहें, «अपनी कंपनी का ईमेल पता डालें।»

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

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

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