2012-09-17 11 views
6

हमारे पास ऐसी साइट है जहां ग्राहक (एक कंपनी) अपने कर्मचारियों के लिए एक्स उपयोगकर्ता लाइसेंस खरीदेंगे। इन कंपनियों के बीच बड़ी, आवर्ती समस्याओं में से एक खाता साझा करना है।खाता साझा करना

हम पहले से ही इस में से कुछ कम करने के लिए कुछ कदम उठाए हैं:

  • हम एक समय में उन 1 sessionid को सीमित
  • हम नियमित रूप से परिवर्तन करने के लिए उपयोगकर्ता के लिए मजबूर (जबरन पुराने लॉग आउट) उनका पासवर्ड (हर 4 महीने)
  • साइट के आसपास कुछ संकेत हैं और ई-मेल हम उपयोगकर्ताओं को याद दिलाने के लिए भेजते हैं कि शेयरिंग
  • पकड़े जाने पर, हम उन्हें "शिक्षित" करने की कोशिश करते हैं कि वे इसे फिर से न करें

लेकिन इन उपायों ने समस्या में भी कोई दिक्कत नहीं डाली है। कई उपयोगकर्ता, खासकर छोटी कंपनियों (जो 1 लाइसेंस खरीदते हैं और डब्ल्यू/5-10 लोगों को साझा करते हैं) पर एक ही समय में साइट का उपयोग न करने के लिए एक दूसरे के साथ समन्वय करते हैं। समझा जा सकता है कि व्यक्तिगत कर्मचारियों की परवाह नहीं है, और सिर्फ अपनी नौकरी करना चाहते हैं।

प्रबंधन हमें इसे हल करने के लिए कुछ करने के लिए कह रहा है।

  • अधिकांश लॉगिन एक इमारत से एक आईपी पते के साथ हैं। तो हम बस आईपी द्वारा पता नहीं लगा सकते हैं।

  • अधिकांश उपयोगकर्ताओं द्वारा पास काम करते हैं, ताकि वे जल्दी से जानकारी साझा कर सकते हैं (पासवर्ड ई-मेल किया जा सकता है, को संदेश भेजा, कहा जाता है, या सिर्फ उन्हें के बगल में बैठे व्यक्ति के लिए कहा था)

  • वहाँ एक रास्ता है मैक पता प्राप्त करें और इसका उपयोग करें? हम उपयोगकर्ताओं को एक समय में 2 या 3 डिवाइसों तक सीमित कर सकते हैं (लैपटॉप & टैबलेट के लिए खाते में)

  • या शायद कुछ जावास्क्रिप्ट/कुकी संयोजन का उपयोग करें?

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

क्या कोई और साइट w/समान उपयोगकर्ता स्थितियों को चलाता है? आप समस्या को कैसे संभालेंगे?

+1

समर्थन करने के लिए अगर मैं एक छोटी सी कंपनी थी और आप सेल फोन प्रमाणीकरण मैं करूंगा की आवश्यकता होती है की तरह एक बेवकूफ स्टंट खींच लिया एक सस्ता ($ 20) भुगतान-जैसा-आप-फोन खरीदें और उसे पंजीकृत करें। यह समन्वय साझाकरण को भी आसान बनाता है: केवल लॉगिन फोन वाले व्यक्ति को साइट का उपयोग करने की अनुमति है। – zebediah49

उत्तर

2

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

+0

कंपनी का आकार एक अच्छा मीट्रिक नहीं है, क्योंकि कभी-कभी 30 व्यक्ति कंपनियां 5 लाइसेंस चाहते हैं, और 500 व्यक्ति कंपनियां 2 चाहती हैं। इसके अलावा मेरे पास बदलने के लिए शून्य शक्ति है ... – DOOManiac

1

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

3

जैसा कि अन्य ने ध्यान दिया है, यह वास्तव में एक तकनीकी निर्णय से अधिक व्यवसाय निर्णय है।

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

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

आप (या, और अधिक संभवतः, आपकी कंपनी के प्रबंधन) को यह तय करने की आवश्यकता है कि नए लाइसेंस से बढ़ी हुई राजस्व वास्तव में ग्राहकों को छोड़ने से राजस्व हानि के लिए पर्याप्त होगी। यह कुछ हद तक हमेशा आपके बाजार जनसांख्यिकी और प्रतिस्पर्धा की सीमा पर निर्भर करेगा, लेकिन, मेरे सिर के शीर्ष से बाहर, मेरा व्यक्तिगत अनुमान "नहीं" होगा। आखिरकार, आपके मौजूदा खाता-साझा करने वाले ग्राहक पहले से ही काफी असुविधाजनक हो रहे हैं, जो संभवतः ऐसा नहीं करेंगे अगर वे आपके सॉफ़्टवेयर के लिए अधिक भुगतान करने में सक्षम और सक्षम हों।

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

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

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

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

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

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

1

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

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

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

और जब प्रबंधन आप इस चालाक समाधान के लिए एक बोनस देता है, इसका इस्तेमाल एक ओपन सोर्स प्रोजेक्ट ;-)