यूज़र को दूसरा मौका देने के दो तरीके - सिर्फ़ फेल हुए स्टेप्स की resubmission मांगें, या नया सेशन शुरू करें। कौन सा इस्तेमाल करें, यह सेशन के स्टेटस पर है।

संक्षिप्त उत्तर

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

समीक्षा में, अस्वीकृत, स्वीकृत, छोड़ा गया, KYC समाप्त या दोबारा जमा किया गया.

किसी को दूसरा मौका देने के दो तरीके हैं: फेल हुए स्टेप्स की resubmission मांगना, या शुरू से एक नया सेशन बनाना। कौन सा चाहिए यह सेशन के मौजूदा स्टेटस पर निर्भर करता है।

#विकल्प 1: Resubmission मांगें

Resubmission वही सेशन और हिस्ट्री बनाए रखता है, और व्यक्ति से सिर्फ़ वही खास स्टेप्स दोबारा करने को कहता है जो फेल हुए थे - पूरी वेरिफिकेशन नहीं।

समीक्षा में, अस्वीकृत, स्वीकृत, छोड़ा गया, KYC समाप्त या दोबारा जमा किया गया.

Didit कंसोल: किसी को दोबारा वेरिफिकेशन आज़माने देना
एक retry सेशन से ही शुरू किया जाता है।
  1. सेशन खोलें

    Business Console में, Verifications पर जाएं और सेशन खोलें।

  2. Resubmission मांगें

    Actions मेन्यू खोलें और Request Resubmission चुनें। वे स्टेप्स चुनें जो व्यक्ति को दोबारा करने हैं - कोई भी स्टेप जो अप्रूव नहीं हुआ।

  3. व्यक्ति को सूचित करें (वैकल्पिक)

    अगर आपके पास उनका ईमेल है, तो आप उन्हें अपने आप resubmission वाले लिंक पर भेज सकते हैं। आप उस ईमेल की भाषा भी सेट कर सकते हैं।

  4. दोबारा मूल्यांकन का इंतज़ार करें

    इंतज़ार के दौरान सेशन का स्टेटस बदलकर Resubmitted हो जाता है। व्यक्ति के मांगे गए स्टेप्स पूरे करने के बाद, सिस्टम अपने आप दोबारा मूल्यांकन करता है और सेशन को Approved, Declined, या In Review पर ले जाता है।

एक ही सेशन पर resubmission एक से ज़्यादा बार मांगी जा सकती है - हर राउंड आपके रिकॉर्ड के लिए सेशन की हिस्ट्री में रखा जाता है। डेवलपर update session status API के ज़रिए भी यही ट्रिगर कर सकते हैं।

#विकल्प 2: एक नया सेशन बनाएं

सत्र खोलने से पहले समाप्त हो गया हो तो और कार्रवाइयाँ → इस व्यक्ति के लिए नया सत्यापन या API से नया सत्र बनाएँ। इस विकल्प के लिए vendor_data चाहिए; इसके बिना विकल्प अक्षम रहता है। उसी व्यक्ति के प्रयास जोड़ने के लिए वही मान रखें।

#कौन सा इस्तेमाल करना चाहिए?

Resubmissionनया सेशन
Session IDवहीनई
हिस्ट्रीएक ही जगह साथ रखीअलग, सिर्फ़ vendor_data से जुड़ी
व्यक्ति क्या दोबारा करता हैसिर्फ़ फेल हुए स्टेप्ससब कुछ
काम करता हैसमीक्षा में, अस्वीकृत, स्वीकृत, छोड़ा गया, KYC समाप्त या दोबारा जमा किया गयाकोई भी स्थिति; मुख्यतः खोलने से पहले समाप्त हुए सत्र
कीमतसिर्फ़ वे स्टेप्स जो दोबारा चलें और पूरे होंवर्कफ़्लो का हर स्टेप फिर से

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

#एक retry की कीमत क्या होती है

बिलिंग हर पूरे हुए फीचर पर होती है, इसलिए:

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

एक ठीक की जा सकने वाली फेलियर पर एक नए सेशन की बजाय resubmission चुनने की यही व्यावहारिक वजह है। देखें बिल होने लायक चेक क्या गिना जाता है।

#किसी व्यक्ति को कितने प्रयास मिलें यह नियंत्रित करना

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

महत्वपूर्ण

retry को पूरी तरह हटाने में सावधानी बरतें। कुछ कैप्चर फेलियर व्यक्ति की गलती नहीं, डिवाइस की होती हैं - जैसे कोई कैमरा जिसने फ़्रेम छोड़ दिया या कोई फ़ोन जो NFC चिप को स्थिर नहीं रख पाया। retry हटाने से ये असली यूज़र के स्थायी decline बन जाते हैं।

#संबंधित

अभी भी अटके हैं? किसी व्यक्ति से बात करें।

अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।

सपोर्ट से संपर्क करें