Здравствуйте, drserg, Вы писали:

D>+3 однозначно! отличные комментарии.
D> Вот правда несколько вопросов:

постараюсь ответить...

MP>>к сожалению, Вы не очень подробно описали суть продукта. Поэтому сложно ответить более-менее однозначно.

D>Продукт — дополнительный модуль к CMS DotNetNuke. Соответственно ставится под веб на стороне клиента. Целевая аудитория — разработчики, саппорт и администраторы CMS.

к сожалению этого маловато, чтоб создалась целостная картина продукта.
тут какая замарочка: utility продукта для юзера должна быть комформна с моделью лизензирования.
А периодические платежи должны быть опрваданны (прежде всего морально, самим юзером и перед самим собой).
То есть польза должна покрывать как жабу, так и неудобства, вызванные сопряженными с лицензией юзерскими активностями.
Модули под CMS бывают разные как по назначению, так и по пользе. Скажем продавать WYSIWYG-редактор или какую-нить фото-галерею по подписке, конечно можно, но значительно менее эффективно, чем по доменам. А вот продавать билинговую систему для онлайн-шопов по подписке во как . При этом и привязка к домену must have!


MP>>В общем случае переход на подписку несет в себе опасность того, что люди начнут "спрыгивать" с продукта. Ибо сами понимаете. Врядли бы Вы стаои платить ежегодные взносы за польхование виндоусом. В некоторых случаях (особенно в таких, когда продукт решает особую, не очень маленькую задачу, которая в свою очередь регулярно, но не чаше 3х раз в месяц, возникает в различных конекстах), подписка имеет смысл.

D>Решает задачи, которые возникают намного чаще чем 3 раза в месяц.

А что за задачи, если не секрет?
Тут дело в том, что задачи по роду своему они разные бывают. Если задача возникает слишком часто, то может быть это не сама задача так часто возникает, а лишь действия, направленные на ее решение. Для прояснения: Например для WYSIWYG-редактора типичная задача в обыкновенном ее понимании будет что-то типа "написание, редактирование и форматирование текстов на сайте". Это действие возникает довольно часто. Задача же, которая на самом деле решается юзером — это наполнение и администрирование контентом информационного сайта по тематике ХУ. Эта задача возникает с момента создания того самого сайта и прекращается только с прекращением его существования (по крайней мере в его задуманном виде). Может быть, я тут подменяю понятия, под задачей имея ввиду что-то другое. Простите меня иносранца — русский словарный запас у меня за годы редкого его использования обнищал. Но думаю, Вы уловили суть.

MP>>Часто бывает эффективнее продавать по подписке не сам продукт, а только саппорт. Возможно последний вариант может оказаться оптимальным решением в Вашем случае. Так вы сократите трудочасы на "устаревших" клиентов.

D>Саппорта очень много, потому что постоянно появляются новые возможности и соответственно вопросы. Хотя не уверен, что саппорт будет продаваться. Но идея хорошая, будем пробовать.

Хех...
если у Вас постоянно появляются новые возможности. То может просто чаще выпускать major версии, делая support discontinued по проществии 6-12 месяцев для прошлых версий? Вот так вот тупо собрать пару новых нужных фич и закатать новую версию. Багфиксы и мелочи можно пропихивать как бесплатный апдейт минора. Апдейт на новый мажор сделать платным. При достаточной регулярности выпусков мажоров получите ту же подписку.


D>>>1) как обеспечить регулярность покупок подписок...
MP>>В этом вопросе не последнюю роль играет периодичность подписки (месяц, 2, 3, год и т.п.). Замечено, что чем ближе "время жизни" подписки к сроку в 12 месяцев, тем регулярнее она продливается. Для большинства людей довольно геморройно суетиться по одной и той же проблеме, скажем, каждые два месяца. Это ведь надо куда-то залогиниться, получить счет, оплатить его. Можно попытаться огранизовать автоматическое продление подписки с автоматическим же снятием денег со счета клиента. Однако, сделать это не будучи предприятием в западной европе или сша, довольно проблематично. В моем варианте я предлагаю три срока на "подписачные" пакеты: скроком на 3, 4 и 12 месяцев. Первые два варианта не продливаются почти никогда. В годовом варианте продлеваются 90% подписок.

D>Супер! Спасибо! Это именно та информация, которая интересовала. Техническая сторона продления платежа не представляет проблему. Создается recurring subscription и деньги автоматом списываются с карты или PayPal аккаунта. Так как клиенты в основном буржуи, то для них это тоже не является дикостью. Счетов выписывать не нужно, все на автомате. Если нужно так я даже подъеду за деньгами, чтоб клиент не напрягался

Я Вам как закоренелый буржуй скажу: никто не любит самопродляющихся абонементов. Автопродлялка есть веский аргумент против. Вон даже Financial Times прекратила эту практику. Абонемент, конечно остался. Но не продливается автоматом. Ближе к концу срока приходит напминалка с уже заполнеными бланками и маркой на открытке. И все. Усилия "юзера" сведены к решению "опустить открытку в почтовый ящик по дороге на работу или нет?". Аналогичная тенденция наблюдается и с софтом. Схема, которая себя зарекомендовала:
1) Продаем абонемент на год без автоматического продления (последнее акцентируется)
2) За месяц до истечения срока начинаем слать напоминалки
а) за 30 дней
б) за 14 дней
в) за 1 день до истечения срока
В напоминалке стоит, мол от Вас требуется только ответ в неформальной форме, что Вы хотите продлить абонемент.

3) по истечении срока включается 30ти дневный счетчик "защитного" периода, в течении которого клиент может продлить, как буд-то бы он продлил точно в срок. По истечении этого срока, можно только купить "заново". (Тут есть варианты с созданием искусственного барьера на выход — эдакого мотиватора. Например, продлить можно по льготным ценам. Купить — по актуальным, немного более высоким. Можно удалять клиентские данные в веб сервисе (но это не ваш случай) и т.п.)

Вот схема (полу?)годового абонемента, о которой я предлагаю подумать...

D>>>2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке);
MP>>Может все же лучше продавать саппорт? Тогда можно диверсифицировать пакеты на, например, 24/7 priority support incl. tel. hotline, eMail-Support (1-2 hours response guaranteed), eMail-Support (1 Day response), support-forum access, free (гарантированный ответ в течении ) и т.д.

D>Все больше склоняюсь в сторону продажи саппорта. Есть два клиента-монстра, так они за Enterprise версию с исходниками в 399$ за последние два года уже так зае..ли что слов нет. Если саппорт будет платный, то хотя бы будет отбиваться.

Знакомая ситуация. Клиент считает, что раз он заплатил больше всех, то он должен отбить расходы, обращаясь к тебе по всяким пустякам нисколько не подумав перед этим. Решил закапываением телефонного номера в недры сайта, внесением в лицензию пункта типа "саппорт предоставляестя добровольно, сам по себе вообще-то не предмет этого договора, но по желанию может быть оговорен в рамках дополнительного соглашения". Телефонный саппорт только в priority режиме (или для тех кто откопал-таки номер). На емейлы всегда есть, что ответить — база знаний, копи-пейст.

D>>>4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи?
MP>>Если есть уверенность, что новая версия сходу приживется и будет приносить больше, или если структурных изменений в новой версии не так много, что продукт "не узнать", то безусловно надо прибивать. Иначе продукты будут друг друга канибализировать. Если такой уверенности нет и здравый смысл говорит "фиг его знает", то стоит подоить старую корову.

D>Новая версия — это полная переработка с "нуля" старой версии. Соответственно больше функций и возможностей.

На первый взгляд выглядит как "убиваем старую".

Уходя в маркетинг да прочую теорию, можно поспекулировать на тему, а много ль новых фич?
-- не стал ли продукт "тяжелее"?
-- не усложнилось ли юзабилити для мейнстрим-юзеров (которые, как известно довольны меньшей частью функционала).
-- не создается ли впечатление "избыточности" дополнительных возможностей
(если да, то юзеры начнут кричать "а нафига мне фича Х, хочу без нее и дешевле", окрестят вас ИТ-мостром и занесут Вас в один ряд с Adobe да Microsoft. А это черевато упущенной выгодой в мид-класс-сегменте)

Если есть таковая опасность, то имеет смысл диверсифицироваться по версиям с разным объемом функционала и разной ценой.

По уму, конечно надо было бы сделать closed-beta для репрезентативной группы пользователей и капитально распросить их о всех возможных аспектах. А потом и решать.

Может кстати выясниться, что будет уместно переименовать старую дойную корову и доить ее пока есть силы. Или захардкодить в нее ад-вордс да пустить в свободное плавание для ознакомления широкой публики с Вашим брендом.


D>>>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени
MP>>То, что тестовый саппорт отнимает так много времени, говорит о том, что Ваш продукт есть experience good.
MP>>Задайте себе вопрос "изменятся ли продажи, если не оказывать поддержку тестовым пользователям".

D>Однозначно упадут, уже пробовали.

На самом деле это повод задуматься...
Я, конечно, не знаю всех деталей Вашего продукта и бизнеса, но был бы менее решителен, что касается "отмены" тест-саппортра в описанной ситуации.

MP>>Если ответ однозначно да, то эти 50% времени есть ничто иное, как Ваш маркетинговый бюджет. Так к нему и относитесь.
MP>>Наймите для этих целей саппортера, заведите в общем доступе саппорт-форум (если Вы этого еще не сделали).

D>Форум и база знаний есть, саппортера стремно, какие-то некачественные только попадались, пришлось отказаться.

+1

Качественный персонал — он всегда проблема. Еще большая проблема в саппорте софта для разработчиков.
Сапортер для софта должен быть из числа либо продвинутых юзеров, либо разработчиков самого софта, то есть из людей с большим инволвментом в отношении продукта. Нанять студента или просто Васю для качаственного саппорта получится только если он кроме всего прочего пройдет практику на вашем предприятии. Иначе учить саппортера задолбаешься.
У меня довольно сносно получилось со студентом. Сначала я сделал из него эдакого технического писателя — заставил писать полную доку и править ошибки в форуме. Чел таким образом "самообразовался", набрался нужной информации и терминологии. Получился хороший и компетентный саппортер. Второй сапортер прошел через другие медные трубы — дал ему реализовывать проект по типу того, что делают юзеры, с небольгими заковырками. Поставил ему довольно короткие (но реальные) сроки. Дал доку и форум в руки. Через месяц имел второго компетентного.
Но студент — дело не постоянное и рано или поздно ухоит в свой карьерный рост, с тобой не связанный
Однако, студент имеет одну очень положительную черту — он энергичен и пронырлив, а главное дешев.
Кроме того он склонен к халяве, но чувстителен к методу кнута да пряника.

С тех пор регулярно практикую второй студенческий вариант.
Хозяйке на заметку: юноши получаются компетентнее девушек. Не ведитесь на чары юных дам и не тешьте себя мыслью, что женская особь разбавит ваш мужской коллектив и скрасит ваши програмерские будни (господа, всем молчать я имел ввиду другое). Все это пустые, ничем не оправданные надежды. Общаться с девушками, конечно, приятно. Только вот дела из этого толком не выходит. Берите студентку на саппорт, только если Вы (или кто-то из Вашей команды) твердо намеряны на ней жениться (кстати не такой уж и плохой вариант — дома всегда будет о чем поговорить и полное понимание. Правда придется запастить агрументами, почему ее карьерный рост в Вашей фирме невозможен. Слишком много инволвмента — плохо.).

MP>>Если ответ "нет", то ограничте тестовый саппорт только форумом.
D>Скорее всего так и сделаем.

У Вас вся информация — Вам виднее.
С моего пригорка видно мало

Если серьезно, то про саппорт подумайте. Помотрите на конверсию до и после его отключения. Пары недель — месяца должно хватить, чтобы понять, что выгоднее. В конце-концов, Вы ведь на рынок вышли не на один день. На рынке всегда есть с кем и с чем бороться, а главное — за что. А еще можно на нем ставить эксперименты. Не очень удачные эксперименты довольно быстро забываются. Удачные, кстати тоже. Так что не пугайтесь экспериментов. Едиственное перед экспериментом сделайте заначку — на случай если он провалится. Все-таки наверстывание упущенной выгоды требует некоторого времени.

D>Еще раз Большое Спасибо за отличные комментарии!

не преувеличивайте мои заслуги.
Что там — всего одна книжка по маркетингу. Докторская степень светит только через два года. Да и в клиентах кроме Microsoft и Deutsche Telekom даже похвастать толком нечем. Разве что EADS, Bertelsmann или TyssenKrup — да кто их знает.
(эко я так невзначай отрекламировался )

D>Сергей

Удачи Вам, Сергей!