Готовим к публикации новую версию продукта (веб). Старая версия (текущая версия) поставлялась в виде 30 дневной пробной версии и соответственно дальнейшей покупки лицензии. Лицензия выдавалась на домен. Цены:
1) Лицензия на домен 57.95$;
2) Дополнительная лицензия +1 домен 14.99$ (доступна только после покупки первой лицензии за 57.95$)
3) Лицензия на неограниченное количество доменов 299$
4) Неограниченное количество доменов + исходники 399$
Срок действия лицензии не был ограничен (начиная с 2006 года). В этом очень есть большая проблема, потому что клиенты продолжают пользоваться старой версией (которая получилась на удивление стабильной). Поддержка соответственно занимает время и не приносит доходов (учитывая только новые продажи)
Как результат было принято решение выпустить новую версию в виде подписки. Соответственно поддержку и обновления будут получать только те, кто оплатил подписку. Сейчас возникли серьезные вопросы:
1) как обеспечить регулярность покупок подписок. Ведь клиент может купить подписку только когда нужно обновление (выходят одним пакетом — кумулятивно) или нужно что-то спросить, отсюда вытекает реальных 1-3 месяца оплаты из 12 возможных (конечно же буржуи в основном правильные и платят аккуратно, но есть и недобросовестные);
2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке);
3) стоит ли брать базовую плату за новую версию, как за продажу? или же базовую стоимость продукта делать 0$, а окупаться за счет подписки на продукт? (пусть даже 50% скидки для существующих клиентов за новую версию)
4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи?
5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени
Здравствуйте, drserg, Вы писали:
D>Уважаемые, коллеги!
D>Готовим к публикации новую версию продукта (веб). Старая версия (текущая версия) поставлялась в виде 30 дневной пробной версии и соответственно дальнейшей покупки лицензии. Лицензия выдавалась на домен. Цены:
D>1) Лицензия на домен 57.95$; D>2) Дополнительная лицензия +1 домен 14.99$ (доступна только после покупки первой лицензии за 57.95$) D>3) Лицензия на неограниченное количество доменов 299$ D>4) Неограниченное количество доменов + исходники 399$
D>Срок действия лицензии не был ограничен (начиная с 2006 года). В этом очень есть большая проблема, потому что клиенты продолжают пользоваться старой версией (которая получилась на удивление стабильной). Поддержка соответственно занимает время и не приносит доходов (учитывая только новые продажи)
Молиться что бы перешли на новую версию
D>Как результат было принято решение выпустить новую версию в виде подписки. Соответственно поддержку и обновления будут получать только те, кто оплатил подписку. Сейчас возникли серьезные вопросы:
D>1) как обеспечить регулярность покупок подписок. Ведь клиент может купить подписку только когда нужно обновление (выходят одним пакетом — кумулятивно) или нужно что-то спросить, отсюда вытекает реальных 1-3 месяца оплаты из 12 возможных (конечно же буржуи в основном правильные и платят аккуратно, но есть и недобросовестные);
Если это сторонние инсталляции то стоимость обновления сделать в зависимости от коеффициента разници версий, чем чаще обновляется клиент тем дешевле ему это должно стоить
D>2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке);
Сделать базовые пакеты бесплатной поддержки, остальная платная с коеффициентом важности клиента.
D>3) стоит ли брать базовую плату за новую версию, как за продажу? или же базовую стоимость продукта делать 0$, а окупаться за счет подписки на продукт? (пусть даже 50% скидки для существующих клиентов за новую версию)
Когда есть подписка то обновления обычно бесплатные( в случае если обновления касаються ваших серваков, а не серваков клиента), токо дополнительные аддоны могут стоить денег(типа на установку) + таже подписка.
D>4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи?
Не положено, сразу надо было думать. Могут и в суд подать
D>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени
Полностью фри на протяжении триала, нужно быть лояльным к новым клиентам
D>Благодарность за любые комментарии.
Если все лицензии крутитяться на ваших серваках то учет делать несложно, а вот если установки на сторону то муторно все учитывать и поддерживать.
D>Сергей
Re[2]: Переход на новый тип цен, по подписке. Как лучше сдел
Здравствуйте, Аноним, Вы писали:
D>>1) как обеспечить регулярность покупок подписок. Ведь клиент может купить подписку только когда нужно обновление (выходят одним пакетом — кумулятивно) или нужно что-то спросить, отсюда вытекает реальных 1-3 месяца оплаты из 12 возможных (конечно же буржуи в основном правильные и платят аккуратно, но есть и недобросовестные);
А>Если это сторонние инсталляции то стоимость обновления сделать в зависимости от коеффициента разници версий, чем чаще обновляется клиент тем дешевле ему это должно стоить
Спасибо за идею, будем думать.
D>>4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи? А>Не положено, сразу надо было думать. Могут и в суд подать
В договоре на продажу не было оговорено срок поддержки старой версии.
D>>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени А>Полностью фри на протяжении триала, нужно быть лояльным к новым клиентам
Да уж, удержание старого клиента как всегда намного дешевле привлечения нового.
А>Если все лицензии крутитяться на ваших серваках то учет делать несложно, а вот если установки на сторону то муторно все учитывать и поддерживать.
D>1) как обеспечить регулярность покупок подписок. Ведь клиент может купить подписку только когда нужно обновление (выходят одним пакетом — кумулятивно) или нужно что-то спросить, отсюда вытекает реальных 1-3 месяца оплаты из 12 возможных (конечно же буржуи в основном правильные и платят аккуратно, но есть и недобросовестные);
Подпиской на год?
D>2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке);
Программа стоит Х (как у вас выше) дает год подписки со старта, дальше через год надо продлять подписку за 0.Y * X (вся цееновая диференцация будет дейтсвовать)
D>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени
Если при таких ценах есть не единичные продажи — нанять саппортера?
D>Благодарность за любые комментарии
p.s. чисто теоретические рассуждения.
Здравствуйте, Begemot_, Вы писали:
D>>2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке); B_>Программа стоит Х (как у вас выше) дает год подписки со старта, дальше через год надо продлять подписку за 0.Y * X (вся цееновая диференцация будет дейтсвовать)
Не уверен, но лично для меня предпочтительнее получать ежемесячную оплату по подписке (ну или раз в квартал). Таким образом обеспечивается регулярность платежей и не возникает большой задолженности перед клиентами.
D>>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени B_>Если при таких ценах есть не единичные продажи — нанять саппортера?
Кстати, сколько стоит такое удовольствие? И как оценивать, если могут быть дни без запросов вообще, а может быть вал из 8-12 писем/звонков?
D>>Благодарность за любые комментарии B_>p.s. чисто теоретические рассуждения.
Все равно спасибо
Re[3]: Переход на новый тип цен, по подписке. Как лучше сдел
От:
Аноним
Дата:
16.01.09 13:38
Оценка:
Здравствуйте, drserg, Вы писали:
D>>>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени B_>>Если при таких ценах есть не единичные продажи — нанять саппортера?
D>Кстати, сколько стоит такое удовольствие? И как оценивать, если могут быть дни без запросов вообще, а может быть вал из 8-12 писем/звонков?
Думаю девочка которая будет посылать всех общими фразами вам не пможет, а скорее всего вам нужны 2 прогера которые будут в теме с разделением труда: 4h development + 4h bug fixing & support(первый саппортит в первой половине дня другой во второй половине дня). Кстати development должен быть обязательно, потому что найти программиста токо на bugfix & support не реально, потому как терять квалификацию нормальный прогер не захочет.
Re: Переход на новый тип цен, по подписке. Как лучше сделать
Здравствуйте, drserg, Вы писали:
D>Уважаемые, коллеги!
D>Готовим к публикации новую версию продукта (веб). Старая версия (текущая версия) поставлялась в виде 30 дневной пробной версии и соответственно дальнейшей покупки лицензии. Лицензия выдавалась на домен. Цены:
D>1) Лицензия на домен 57.95$; D>2) Дополнительная лицензия +1 домен 14.99$ (доступна только после покупки первой лицензии за 57.95$) D>3) Лицензия на неограниченное количество доменов 299$ D>4) Неограниченное количество доменов + исходники 399$
D>Срок действия лицензии не был ограничен (начиная с 2006 года). В этом очень есть большая проблема, потому что клиенты продолжают пользоваться старой версией (которая получилась на удивление стабильной). Поддержка соответственно занимает время и не приносит доходов (учитывая только новые продажи)
D>Как результат было принято решение выпустить новую версию в виде подписки. Соответственно поддержку и обновления будут получать только те, кто оплатил подписку. Сейчас возникли серьезные вопросы:
к сожалению, Вы не очень подробно описали суть продукта. Поэтому сложно ответить более-менее однозначно.
В общем случае переход на подписку несет в себе опасность того, что люди начнут "спрыгивать" с продукта. Ибо сами понимаете. Врядли бы Вы стаои платить ежегодные взносы за польхование виндоусом. В некоторых случаях (особенно в таких, когда продукт решает особую, не очень маленькую задачу, которая в свою очередь регулярно, но не чаше 3х раз в месяц, возникает в различных конекстах), подписка имеет смысл.
Часто бывает эффективнее продавать по подписке не сам продукт, а только саппорт. Возможно последний вариант может оказаться оптимальным решением в Вашем случае. Так вы сократите трудочасы на "устаревших" клиентов.
D>1) как обеспечить регулярность покупок подписок. Ведь клиент может купить подписку только когда нужно обновление (выходят одним пакетом — кумулятивно) или нужно что-то спросить, отсюда вытекает реальных 1-3 месяца оплаты из 12 возможных (конечно же буржуи в основном правильные и платят аккуратно, но есть и недобросовестные);
В этом вопросе не последнюю роль играет периодичность подписки (месяц, 2, 3, год и т.п.). Замечено, что чем ближе "время жизни" подписки к сроку в 12 месяцев, тем регулярнее она продливается. Для большинства людей довольно геморройно суетиться по одной и той же проблеме, скажем, каждые два месяца. Это ведь надо куда-то залогиниться, получить счет, оплатить его. Можно попытаться огранизовать автоматическое продление подписки с автоматическим же снятием денег со счета клиента. Однако, сделать это не будучи предприятием в западной европе или сша, довольно проблематично. В моем варианте я предлагаю три срока на "подписачные" пакеты: скроком на 3, 4 и 12 месяцев. Первые два варианта не продливаются почти никогда. В годовом варианте продлеваются 90% подписок.
Но это всего лишь один из аспектов. Регулярность продления, конечно же определяется важностью продукта для решения своих задач и переодичностью, с которой эти задачи возникают.
D>2) как поступать со стимостью подписки для одной и нескольких лицензий? Ведь вопросов по 1 лицензии соответственно будет меньше, чем у Enterprise клиента (которые могут по 2-3 часа сидеть на трубке);
Может все же лучше продавать саппорт? Тогда можно диверсифицировать пакеты на, например, 24/7 priority support incl. tel. hotline, eMail-Support (1-2 hours response guaranteed), eMail-Support (1 Day response), support-forum access, free (гарантированный ответ в течении ) и т.д.
D>3) стоит ли брать базовую плату за новую версию, как за продажу? или же базовую стоимость продукта делать 0$, а окупаться за счет подписки на продукт? (пусть даже 50% скидки для существующих клиентов за новую версию)
это как жаба скажет. На мой взгляд, все причуды с базовой стоимостью трудно понятны клиентуре (не интуитивны они) и привязываться надо к продукту. Это ИМХО, спорить тут можно долго.
D>4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи?
Если есть уверенность, что новая версия сходу приживется и будет приносить больше, или если структурных изменений в новой версии не так много, что продукт "не узнать", то безусловно надо прибивать. Иначе продукты будут друг друга канибализировать. Если такой уверенности нет и здравый смысл говорит "фиг его знает", то стоит подоить старую корову.
D>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени
То, что тестовый саппорт отнимает так много времени, говорит о том, что Ваш продукт есть experience good.
Задайте себе вопрос "изменятся ли продажи, если не оказывать поддержку тестовым пользователям".
Если ответ однозначно да, то эти 50% времени есть ничто иное, как Ваш маркетинговый бюджет. Так к нему и относитесь.
Наймите для этих целей саппортера, заведите в общем доступе саппорт-форум (если Вы этого еще не сделали).
Если ответ "нет", то ограничте тестовый саппорт только форумом.
+3 однозначно! отличные комментарии. Вот правда несколько вопросов:
MP>к сожалению, Вы не очень подробно описали суть продукта. Поэтому сложно ответить более-менее однозначно.
Продукт — дополнительный модуль к CMS DotNetNuke. Соответственно ставится под веб на стороне клиента. Целевая аудитория — разработчики, саппорт и администраторы CMS.
MP>В общем случае переход на подписку несет в себе опасность того, что люди начнут "спрыгивать" с продукта. Ибо сами понимаете. Врядли бы Вы стаои платить ежегодные взносы за польхование виндоусом. В некоторых случаях (особенно в таких, когда продукт решает особую, не очень маленькую задачу, которая в свою очередь регулярно, но не чаше 3х раз в месяц, возникает в различных конекстах), подписка имеет смысл.
Решает задачи, которые возникают намного чаще чем 3 раза в месяц.
MP>Часто бывает эффективнее продавать по подписке не сам продукт, а только саппорт. Возможно последний вариант может оказаться оптимальным решением в Вашем случае. Так вы сократите трудочасы на "устаревших" клиентов.
Саппорта очень много, потому что постоянно появляются новые возможности и соответственно вопросы. Хотя не уверен, что саппорт будет продаваться. Но идея хорошая, будем пробовать.
D>>1) как обеспечить регулярность покупок подписок... MP>В этом вопросе не последнюю роль играет периодичность подписки (месяц, 2, 3, год и т.п.). Замечено, что чем ближе "время жизни" подписки к сроку в 12 месяцев, тем регулярнее она продливается. Для большинства людей довольно геморройно суетиться по одной и той же проблеме, скажем, каждые два месяца. Это ведь надо куда-то залогиниться, получить счет, оплатить его. Можно попытаться огранизовать автоматическое продление подписки с автоматическим же снятием денег со счета клиента. Однако, сделать это не будучи предприятием в западной европе или сша, довольно проблематично. В моем варианте я предлагаю три срока на "подписачные" пакеты: скроком на 3, 4 и 12 месяцев. Первые два варианта не продливаются почти никогда. В годовом варианте продлеваются 90% подписок.
Супер! Спасибо! Это именно та информация, которая интересовала. Техническая сторона продления платежа не представляет проблему. Создается recurring subscription и деньги автоматом списываются с карты или PayPal аккаунта. Так как клиенты в основном буржуи, то для них это тоже не является дикостью. Счетов выписывать не нужно, все на автомате. Если нужно так я даже подъеду за деньгами, чтоб клиент не напрягался
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 (гарантированный ответ в течении ) и т.д.
Все больше склоняюсь в сторону продажи саппорта. Есть два клиента-монстра, так они за Enterprise версию с исходниками в 399$ за последние два года уже так зае..ли что слов нет. Если саппорт будет платный, то хотя бы будет отбиваться.
D>>4) стоит ли убивать старую версию, которая все еще приносит неплохие продажи? MP>Если есть уверенность, что новая версия сходу приживется и будет приносить больше, или если структурных изменений в новой версии не так много, что продукт "не узнать", то безусловно надо прибивать. Иначе продукты будут друг друга канибализировать. Если такой уверенности нет и здравый смысл говорит "фиг его знает", то стоит подоить старую корову.
Новая версия — это полная переработка с "нуля" старой версии. Соответственно больше функций и возможностей.
D>>5) извечный вопрос: как быть с поддержкой для пробной версии? де-факто поддержка пользователей, которые еще не купили продукт занимает 50% времени MP>То, что тестовый саппорт отнимает так много времени, говорит о том, что Ваш продукт есть experience good. MP>Задайте себе вопрос "изменятся ли продажи, если не оказывать поддержку тестовым пользователям".
Однозначно упадут, уже пробовали.
MP>Если ответ однозначно да, то эти 50% времени есть ничто иное, как Ваш маркетинговый бюджет. Так к нему и относитесь. MP>Наймите для этих целей саппортера, заведите в общем доступе саппорт-форум (если Вы этого еще не сделали).
Форум и база знаний есть, саппортера стремно, какие-то некачественные только попадались, пришлось отказаться.
MP>Если ответ "нет", то ограничте тестовый саппорт только форумом.
Скорее всего так и сделаем.
Здравствуйте, 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>Сергей
почему-то только сейчас увидел линк на Ваш сайт в профиле.
(признайтесь — Вы его только что туда выставили?!)
По типу продукта — подписка 100% прокатит. Даже не думайте.
Для клиентов типа eLocomotive (они ведь строят сайты для других?)
стоит, однако, разработать отдельную модель — чтобы они в свою очередь
не грузили своих клиентов Вашими подписками. Тут, пожалуй подойдет,
site лицензия + опциональный договор на саппорт.
Честно говоря, ушел в глубокий шок! Такой подробного ответа мне еще никогда не писал (кроме жены до свадьбы). Спасибо огромное!
MP>Модули под CMS бывают разные как по назначению, так и по пользе. Скажем продавать WYSIWYG-редактор или какую-нить фото-галерею по подписке, конечно можно, но значительно менее эффективно, чем по доменам. А вот продавать билинговую систему для онлайн-шопов по подписке во как . При этом и привязка к домену must have!
Модуль для работы с базой данных: новые формы для пользователей, экспорт, импорт данных, утилиты для администраторов.
MP>>>В общем случае переход на подписку несет в себе опасность того, что люди начнут "спрыгивать" с продукта. Ибо саMP>А что за задачи, если не секрет? MP>Тут дело в том, что задачи по роду своему они разные бывают. Если задача возникает слишком часто, то может быть это не сама задача так часто возникает, а лишь действия, направленные на ее решение. Для прояснения: Например для WYSIWYG-редактора типичная задача в обыкновенном ее понимании будет что-то типа "написание, редактирование и форматирование текстов на сайте". Это действие возникает довольно часто. Задача же, которая на самом деле решается юзером — это наполнение и администрирование контентом информационного сайта по тематике ХУ. Эта задача возникает с момента создания того самого сайта и прекращается только с прекращением его существования (по крайней мере в его задуманном виде). Может быть, я тут подменяю понятия, под задачей имея ввиду что-то другое. Простите меня иносранца — русский словарный запас у меня за годы редкого его использования обнищал. Но думаю, Вы уловили суть.
Русский отличный! Задачи возникают регулярно, сайты ведь нужно поддерживать.
MP>Хех... MP>если у Вас постоянно появляются новые возможности. То может просто чаще выпускать major версии, делая support discontinued по проществии 6-12 месяцев для прошлых версий? Вот так вот тупо собрать пару новых нужных фич и закатать новую версию. Багфиксы и мелочи можно пропихивать как бесплатный апдейт минора. Апдейт на новый мажор сделать платным. При достаточной регулярности выпусков мажоров получите ту же подписку.
Совесть не позволяет
D>>Супер! Спасибо! Это именно та информация, которая интересовала. Техническая сторона продления платежа не представляет проблему. Создается recurring subscription и деньги автоматом списываются с карты или PayPal аккаунта. Так как клиенты в основном буржуи, то для них это тоже не является дикостью. Счетов выписывать не нужно, все на автомате. Если нужно так я даже подъеду за деньгами, чтоб клиент не напрягался MP>Я Вам как закоренелый буржуй скажу: никто не любит самопродляющихся абонементов. Автопродлялка есть веский аргумент против. Вон даже Financial Times прекратила эту практику. Абонемент, конечно остался. Но не продливается автоматом. Ближе к концу срока приходит напминалка с уже заполнеными бланками и маркой на открытке. И все. Усилия "юзера" сведены к решению "опустить открытку в почтовый ящик по дороге на работу или нет?". Аналогичная тенденция наблюдается и с софтом. Схема, которая себя зарекомендовала: MP>1) Продаем абонемент на год без автоматического продления (последнее акцентируется) MP>2) За месяц до истечения срока начинаем слать напоминалки MP>а) за 30 дней MP>б) за 14 дней MP>в) за 1 день до истечения срока MP>В напоминалке стоит, мол от Вас требуется только ответ в неформальной форме, что Вы хотите продлить абонемент.
+3 Однозначно, эта информацяи была неизвестна. Учтём. Скорее всего тогда нужно пускать чаще новые версии, прийдется бороться с совестью.
D>>Все больше склоняюсь в сторону продажи саппорта. Есть два клиента-монстра, так они за Enterprise версию с исходниками в 399$ за последние два года уже так зае..ли что слов нет. Если саппорт будет платный, то хотя бы будет отбиваться. MP>Знакомая ситуация. Клиент считает, что раз он заплатил больше всех, то он должен отбить расходы, обращаясь к тебе по всяким пустякам нисколько не подумав перед этим. Решил закапываением телефонного номера в недры сайта, внесением в лицензию пункта типа "саппорт предоставляестя добровольно, сам по себе вообще-то не предмет этого договора, но по желанию может быть оговорен в рамках дополнительного соглашения". Телефонный саппорт только в priority режиме (или для тех кто откопал-таки номер). На емейлы всегда есть, что ответить — база знаний, копи-пейст.
Будем продавать саппорт дополнительно и отдельно от продукта. Все больше людей советуют продавать именно саппорт. Глупый вопрос: саппорт стоит дороже разработки? или дешевле? как правильно делать почасово или за решение поставленной задачи?
MP>Уходя в маркетинг да прочую теорию, можно поспекулировать на тему, а много ль новых фич? MP>-- не стал ли продукт "тяжелее"? MP>-- не усложнилось ли юзабилити для мейнстрим-юзеров (которые, как известно довольны меньшей частью функционала). MP>-- не создается ли впечатление "избыточности" дополнительных возможностей MP>(если да, то юзеры начнут кричать "а нафига мне фича Х, хочу без нее и дешевле", окрестят вас ИТ-мостром и занесут Вас в один ряд с Adobe да Microsoft. А это черевато упущенной выгодой в мид-класс-сегменте)
С новой версией все ок. Пользователи очень довольны (отзывы позитивные), пинают ногами чтобы быстрее выпускали с Беты в живую.
Ах, да. Забыл сказать. Новая версия выходит как продукт с новым названием (так получилось). Все клиенты в курсе и вроде как ничего против не имеют.
MP>Если есть таковая опасность, то имеет смысл диверсифицироваться по версиям с разным объемом функционала и разной ценой.
Возможно чуть позже, сейчас не хватает ресурсов
MP>По уму, конечно надо было бы сделать closed-beta для репрезентативной группы пользователей и капитально распросить их о всех возможных аспектах. А потом и решать.
Внедрили прямо в модуль форму для отправки отзывов, запросов и идей. Пишут вроде активно. Это имелось в виду?
MP>Может кстати выясниться, что будет уместно переименовать старую дойную корову и доить ее пока есть силы. Или захардкодить в нее ад-вордс да пустить в свободное плавание для ознакомления широкой публики с Вашим брендом.
Тогда однозначно нужно будет поменять цену для старой версии.
MP>>>Задайте себе вопрос "изменятся ли продажи, если не оказывать поддержку тестовым пользователям". D>>Однозначно упадут, уже пробовали. MP>На самом деле это повод задуматься... MP>Я, конечно, не знаю всех деталей Вашего продукта и бизнеса, но был бы менее решителен, что касается "отмены" тест-саппортра в описанной ситуации.
Тест-пользователей будем поддерживать только через форум.
MP>Однако, студент имеет одну очень положительную черту — он энергичен и пронырлив, а главное дешев. MP>Кроме того он склонен к халяве, но чувстителен к методу кнута да пряника.
Будем пробовать
MP>С тех пор регулярно практикую второй студенческий вариант. MP>Хозяйке на заметку: юноши получаются компетентнее девушек. Не ведитесь на чары юных дам и не тешьте себя мыслью, что женская особь разбавит ваш мужской коллектив и скрасит ваши програмерские будни (господа, всем молчать я имел ввиду другое). Все это пустые, ничем не оправданные надежды. Общаться с девушками, конечно, приятно. Только вот дела из этого толком не выходит. Берите студентку на саппорт, только если Вы (или кто-то из Вашей команды) твердо намеряны на ней жениться (кстати не такой уж и плохой вариант — дома всегда будет о чем поговорить и полное понимание. Правда придется запастить агрументами, почему ее карьерный рост в Вашей фирме невозможен. Слишком много инволвмента — плохо.).
Согласен. С девушками работали. Из них получаются отличные дизайнеры, но кодеры, тестеры или саппортеры НИКАКИЕ
MP>не преувеличивайте мои заслуги. MP>Что там — всего одна книжка по маркетингу. Докторская степень светит только через два года. Да и в клиентах кроме Microsoft и Deutsche Telekom даже похвастать толком нечем. Разве что EADS, Bertelsmann или TyssenKrup — да кто их знает. MP>(эко я так невзначай отрекламировался )
О! Ушел в глубокий ступор! Книга на английском есть? Или только на немецком?
Здравствуйте, marx paul, Вы писали:
MP>почему-то только сейчас увидел линк на Ваш сайт в профиле. MP>(признайтесь — Вы его только что туда выставили?!)
Не совсем, вроде как зарегистрировался в 2006.
MP>По типу продукта — подписка 100% прокатит. Даже не думайте. MP>Для клиентов типа eLocomotive (они ведь строят сайты для других?) MP>стоит, однако, разработать отдельную модель — чтобы они в свою очередь MP>не грузили своих клиентов Вашими подписками. Тут, пожалуй подойдет, MP>site лицензия + опциональный договор на саппорт.
marx paul Спасибо! В понедельник будем пускать пробу
. При этом и привязка к домену must have! 
)