Як і кілька інших згаданих, я є величезним противником ворожості до клієнтів за замовчуванням - те, для чого ліцензійна галузь є горезвісною. Тож я розкрию гарне рішення вашої проблеми, яке також пропонує хороший клієнт UX .
Для початку ви згадали, що у вас є "обмежена" версія свого програмного забезпечення, яку ви використовуєте для того, щоб спробувати перетворити клієнтів на "оновлення" для додаткових функцій. Тож ви шукаєте ліцензії на функції для вашого продукту, наприклад, клієнт може придбати ліцензію на функцію-X або функцію-Y .
Я створив Кеген з таким ліцензуванням на увазі. Keygen - це ліцензійний API REST, який дозволяє керувати обліковими записами користувачів, ліцензіями, а також відстежувати використання машини / асоціації.
Що я б робив, це створити два типи ліцензій ( політика в межах Keygen), де одна є базовою політикою для обмеженої безкоштовної версії, а інша - це політика для платної версії.
Я не впевнений, що ви використовуєте для платежів, але припустимо, що ви використовуєте щось на зразок Stripe (досить стандартний на сьогоднішній день), який пропонує веб-камери . У Keygen також є веб-ручки (ви користуєтесь ним чи ні, все це все ще застосовується). Ви можете інтегрувати Keygen для спілкування зі своїм постачальником платежів, використовуючи веб-каси з обох сторін (подумайте: customer.created-> створити базову ліцензію для клієнта, license.created-> стягувати клієнта з нової ліцензії).
Таким чином, використовуючи веб-каси, ми можемо автоматизувати створення ліцензій для нових клієнтів. То як щодо перевірки ліцензії в самій програмі? Це можна зробити різними способами, але найпопулярніший спосіб - вимагаючи від вашого клієнта ввести довгий ліцензійний ключ у поле введення, яке ви зможете потім перевірити; Я думаю, що це жахливий спосіб вирішити процедуру перевірки ліцензії у вашій заявці.
Чому я вважаю це? Ну, по-перше, ви вимагаєте від свого клієнта ввести нудно довгий ліцензійний ключ, призначений для споживання машини, а по-друге, вам потрібно, щоб ви та ваш клієнт відслідковували зазначений нудно довгий ліцензійний ключ .
Гаразд, то яка альтернатива? Я думаю, що найкраща альтернатива - це щось, до чого звикли всі ваші клієнти: дозволяючи їм створити обліковий запис для вашого продукту за допомогою електронної пошти / пароля . Потім ви можете пов’язати всі їхні ліцензії та їх машини з цим обліковим записом. Тож тепер замість введення ліцензійного ключа вони можуть просто увійти за допомогою своїх облікових даних.
Яку перевагу це дає тобі? По-перше, це позбавляється від необхідності вам і вашим клієнтам відслідковувати ліцензійні ключі, оскільки все це обробляється поза кадром всередині їх облікового запису користувача і найголовніше: тепер ви можете запропонувати своїм клієнтам ліцензію та автономне обслуговування активація! тобто оскільки всі їхні ліцензії та машини пов'язані з їх обліковим записом користувача, ви можете запропонувати їм придбати ліцензію, коли вони подають заявку на нерозпізнану машину.
Тепер на підтвердження ліцензії : щоразу, коли ваш клієнт увійде до вашої програми за допомогою своєї електронної пошти / пароля, ви можете запитати у свого облікового запису користувача про наявні у нього ліцензії, щоб визначити, чи можуть вони використовувати функцію-X або особливість-Y . А оскільки ваша програма тепер самообслуговується , ви можете дозволити своїм клієнтам купувати додаткові функції безпосередньо з вашої програми!
Таким чином, ми внесли тонну автоматизацію в нашу систему ліцензування, ми можемо ліцензувати окремі функції (тобто обмежена порівняно з повною версією), ми запропонували для наших клієнтів приголомшливий UX, і ми також усунули одну з найбільших причин для запитів підтримки: відновлення ліцензійного ключа.
У будь-якому випадку, це довго, але, сподіваємось, це допомагає комусь!