सेवा की शर्तें

1. KARODIAL और इन शर्तों के बारे में

Avycore Tech Private Limited द्वारा संचालित KARODIAL वेबसाइट डिज़ाइन कैटलॉग, प्रोजेक्ट पूछताछ और वेबसाइट, AI की सहायता से विकास तथा Android/iOS ऐप से संबंधित सेवाएँ देता है। ये सेवा शर्तें karodial.com इस्तेमाल करने और हमारे माध्यम से काम की चर्चा या आदेश देने के सामान्य नियम बताती हैं। इन्हें गोपनीयता नीति और स्वीकार किए गए प्रस्ताव या प्रोजेक्ट समझौते के साथ पढ़ें। डिज़ाइन देखना, अकाउंट बनाना या प्रश्न पूछना अपने आप सशुल्क विकास का आदेश नहीं है।

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

2. प्रस्ताव और लिखित प्रोजेक्ट समझौते

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

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

3. डिज़ाइन कैटलॉग, पूर्वावलोकन और नमूना सामग्री

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

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

4. अकाउंट, अधिकृत उपयोगकर्ता और सुरक्षित पहुँच

सही अकाउंट और संपर्क विवरण दें तथा संबंधित ईमेल तक पहुँच बनाए रखें। केवल अपना या अधिकृत अकाउंट इस्तेमाल करें। किसी का रूप न धरें, व्यवसाय की ओर से अधिकार का गलत दावा न करें और अनधिकृत व्यक्ति से स्टाफ प्रवेश साझा न करें। Google/Firebase साइन इन पर प्रदाता की प्रमाणीकरण प्रक्रिया और हमारे एप्लिकेशन नियंत्रण दोनों लागू हैं। डिवाइस तथा साइन इन विवरण सुरक्षित रखें और अनधिकृत गतिविधि का संदेह तुरंत बताएं। संवेदनशील अकाउंट विवरण बदलने या निजी प्रोजेक्ट जानकारी देने से पहले अनुपातिक सत्यापन जरूरी हो सकता है।

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

5. केवल डेवलपमेंट सेवा, प्लान और कर

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

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

6. डोमेन का स्वामित्व, पंजीकरण और नवीनीकरण

स्वतंत्र रजिस्ट्रार से डोमेन चुनना, पंजीकृत करना, अपने स्वामित्व में रखना और नवीनीकरण ग्राहक की जिम्मेदारी है। शुल्क, एक्सपायरी, रिकवरी, स्वामित्व विवाद और रजिस्ट्रार की रोक हमारी डेवलपमेंट सेवा के बाहर हैं। डोमेन अपने नियंत्रण वाले अकाउंट में रखें। तय DNS सेटअप में मदद से डोमेन KARODIAL का नहीं होता और रजिस्ट्रार का संचालन हमारी जिम्मेदारी नहीं बनता।

7. होस्टिंग, सर्वर उपलब्धता और इंफ्रास्ट्रक्चर

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

8. ईमेल सर्वर, मेलबॉक्स और संदेश की डिलीवरी

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

9. ऑनलाइन भुगतान और सत्यापन

चेकआउट उपलब्ध हो तो भुगतान इंटरफेस खोलने से पहले ऑर्डर संदर्भ, मूल राशि, कर और कुल जांचें। वैध Razorpay चेकआउट और ऐसा भुगतान तरीका इस्तेमाल करें जिसके लिए आप अधिकृत हैं। पुष्टि के लिए सर्वर पर संबंधित लेनदेन का सत्यापन जरूरी है। केवल ब्राउज़र की सफलता स्क्रीन या स्क्रीनशॉट सही राशि प्राप्त होने का पूरा प्रमाण नहीं हो सकता। भुगतान रिकॉर्ड और विकास का चरण अलग बातें हैं। Received, In progress, Completed, Delivered और Canceled जैसे चरण काम की स्थिति बताते हैं; वे दूसरा भुगतान निर्देश नहीं हैं।

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

10. जरूरतें, बदलाव और अतिरिक्त काम

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

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

11. ग्राहक सामग्री, निर्देश और मंजूरी

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

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

12. समय सीमा, निर्भरताएँ और प्रोजेक्ट बातचीत

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

13. प्रोजेक्ट रिकॉर्ड और अधिकृत बातचीत

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

14. संशोधन, परीक्षण और स्वीकृति

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

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

15. दो भाषाओं की वेबसाइट और कंटेंट की जिम्मेदारी

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

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

16. Android, iOS, वेबव्यू और ऐप स्टोर समीक्षा

लिखित दायरे के अनुसार ऐप मूल प्लेटफॉर्म पर, साझा तकनीक से या वेबव्यू आधारित आवरण के रूप में बनाया जा सकता है। इनके सामर्थ्य और सीमाएँ अलग हैं। डेस्कटॉप ब्राउज़र में वेबसाइट चलने से मोबाइल ऐप में समान व्यवहार की गारंटी नहीं मिलती, खासकर प्रमाणीकरण, फाइल अपलोड, भुगतान, डाउनलोड, अनुमति और बाहरी लिंक में। विकास से पहले जरूरी मूल सुविधाएँ, ऑपरेटिंग सिस्टम संस्करण और परीक्षण डिवाइस तय करें। वेबव्यू रूपांतरण Google Play या Apple App Store की मंजूरी का वादा नहीं है।

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

17. AI, Firebase, SMS और बाहरी इंटीग्रेशन

प्रोजेक्ट में Google/Firebase प्रमाणीकरण, संपर्क फॉर्म, SMS प्राप्ति संदेश, भुगतान गेटवे, WeBot या तय इंटीग्रेशन हो सकते हैं। हर सुविधा प्रदाता के अकाउंट नियम, तकनीकी सीमा, उपलब्धता और शर्तों पर निर्भर है। AI के टेक्स्ट, कोड और चैटबॉट उत्तर गलत या अधूरे हो सकते हैं और समीक्षा जरूरी है। वे पेशेवर कानूनी, चिकित्सा या वित्तीय सलाह या व्यावसायिक परिणाम की गारंटी नहीं हैं।

प्रदाता API बदले या सुविधा बंद करे तो सहमत माइग्रेशन या अतिरिक्त विकास चाहिए हो सकता है। SMS पहुंचना नेटवर्क, सही नंबर और संदेश संबंधी आवश्यकताओं पर निर्भर है। भेजने की तकनीकी सुविधा अनचाहे, अवैध या भ्रामक संदेश की अनुमति नहीं देती।

18. बाहरी सदस्यताएँ और उपयोग शुल्क

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

19. स्वामित्व, लाइसेंस और दी गई सामग्री

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

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

20. स्रोत कोड, प्रकाशन और सुपुर्दगी

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

21. प्रकाशन की पहुँच, माइग्रेशन और संचालन सुपुर्दगी

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

22. सहायता, रखरखाव और भविष्य के अपडेट

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

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

23. गोपनीयता, निजता और सुरक्षा सहयोग

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

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

24. स्वीकार्य उपयोग और प्रतिबंधित गतिविधि

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

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

25. रद्द करना, विराम और शेष जिम्मेदारियाँ

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

26. डेवलपमेंट भुगतान पर रिफंड नहीं

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

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

27. उपलब्धता, परिणाम और सीमाएँ

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

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

28. जिम्मेदारी, उपाय और विवाद

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

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

29. बदलाव, लागू कानून और संपर्क

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

उचित मंच लागू कानून से तय होता है और कानूनी तथा उपभोक्ता उपाय सुरक्षित हैं। किसी शर्त का भाग लागू न हो सके तो उसका असर और बाकी शर्तें कानून के अनुसार देखी जाएँ, अनिवार्य संरक्षण हटाने के लिए नहीं। प्रश्न, प्रोजेक्ट चिंता या शिकायत के लिए support@karodial.com पर लिखें या संपर्क पेज इस्तेमाल करें। KARODIAL, प्रोजेक्ट या ऑर्डर संदर्भ, स्पष्ट विवरण और अपेक्षित समाधान बताएं। पासवर्ड या गैरजरूरी संवेदनशील संलग्नक न भेजें। व्यक्तिगत जानकारी के उपयोग के लिए गोपनीयता नीति पढ़ें।