लॉन्च के बाद वेबसाइट समर्थन मूल्य निर्धारण

लॉन्च के बाद वेबसाइट समर्थन में क्या शामिल है

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

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

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

यदि आप लॉन्च के बाद के रखरखाव पर एक व्यापक दृष्टिकोण चाहते हैं, तो इसे एक अलग प्रक्रिया के रूप में स्पष्ट चरणों के साथ देखना भी उपयोगी है, न कि केवल "अतिरिक्त प्रोग्रामर घंटे" के रूप में।लॉन्च के बाद की वेबसाइट समर्थनएक अलग प्रक्रिया के रूप में स्पष्ट चरणों के साथ, केवल "अतिरिक्त प्रोग्रामर घंटे" के रूप में नहीं।

वेबसाइट समर्थन मूल्य निर्धारण को क्या प्रभावित करता है

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

पहला और सबसे स्पष्ट कारक साइट का प्रकार है। कुछ पृष्ठों के साथ एक छोटा ब्रोशर साइट को बनाए रखना एक ऑनलाइन स्टोर की तुलना में आसान है, जहां हर दिन ऑर्डर, स्टॉक स्तर, भुगतान, डिलीवरी और बाहरी सेवा एकीकरण चल रहे होते हैं। एक कॉर्पोरेट वेबसाइट आमतौर पर बीच में कहीं होती है: ब्रोशर साइट से अधिक जटिल, लेकिन हमेशा ई-कॉमर्स की तरह मांग करने वाली नहीं।

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

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

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

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

मासिक वेबसाइट समर्थन: कौन से प्रारूप उपलब्ध हैं

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

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

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

यहां रिटेनर-शैली का समर्थन भी है। इस मामले में, एक टीम स्टैंडबाय पर रहती है और सहमति के दायरे या प्रक्रिया के भीतर छोटे कार्यों के निरंतर प्रवाह को संभालती है। यह उन परियोजनाओं के लिए एक अच्छा विकल्प है जहां वेबसाइट एक महत्वपूर्ण कार्य उपकरण है, लेकिन एक समर्पित इन-हाउस आईटी टीम की आवश्यकता नहीं है।

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

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

विभिन्न मामलों में लॉन्च के बाद वेबसाइट समर्थन की लागत कितनी है

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

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

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

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

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

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

बुनियादी समर्थन में आमतौर पर क्या शामिल नहीं होता

ग्राहक और ठेकेदार के बीच संघर्ष के सबसे सामान्य स्रोतों में से एक बुनियादी समर्थन के चारों ओर धुंधले सीमाएँ हैं। आश्चर्य से बचने के लिए, यह सबसे अच्छा है कि तुरंत समझ लें कि आमतौर पर क्या अलग से बिल किया जाता है।

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

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

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

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

कैसे पता करें कि वेबसाइट समर्थन योजना उचित है

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

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

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

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

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

मासिक समर्थन के लिए ठेकेदार कैसे चुनें

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

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

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

यह भी उपयोगी है कि यह जांचना कि क्या टीम के पास समान परियोजनाओं का अनुभव है। एक साधारण संरचना वाली साइट और कई एकीकरण वाली साइट जिम्मेदारी के विभिन्न स्तर हैं। कभी-कभी, यह बेहतर होता है कि आप एक ठेकेदार का चयन करें जिसने पहले से ही समान आर्किटेक्चर के साथ काम किया है, बजाय इसके कि सबसे कम कीमत का पीछा करें। यह विशेष रूप से उन परियोजनाओं में स्पष्ट होता है जहां बुनियादी ढांचा और सुरक्षा एक प्रमुख भूमिका निभाते हैं, जैसे कि S4M — निजी नेटवर्क बुनियादी ढांचा: VPN और प्रॉक्सी.

गुणवत्ता खोए बिना समर्थन लागत कैसे कम करें

आप समर्थन लागत को कम कर सकते हैं यदि आप प्रक्रिया पर बचत करने की कोशिश नहीं करते हैं, बल्कि इसके चारों ओर अनावश्यक अराजकता को हटा देते हैं। सबसे सरल तरीका अनुरोधों को मानकीकृत करना है। जब संपादन एक स्पष्ट प्रारूप में आते हैं, तो विशेषज्ञ विवरण स्पष्ट करने में कम समय बिताते हैं। यह सब कुछ पर लागू होता है: पाठ, बैनर, नए पृष्ठ, छोटे सुधार।

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

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

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

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