наверное, многим людям не нравится, когда их принудительно заставляют обновляться в неудобное им время...

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

думаю, многое упирается в эргономику в данном вопросе... что касается стабильности - это для многих домашних пользователей выгодная сделка, даже если подвиснет игра и они потеряют недавнее сохранение, это не настолько страшная трагедия всё же как в случае с корпоративными системами 🙂 стабильность работы важных крупных систем в целом в интересах общества, пусть лучше зависают игры у домашних пользователей, чем произойдёт какой-нибудь выброс на заводе из-за невовремя зависшей системы

но если пользователи недовольны (а какая-то часть всегда будет недовольна), важно чтобы был выбор - чтобы они могли изменить условия сделки, отказавшись от данного продукта/услуги или перейти на другой тарифный план с другими условиями предоставления услуги, я, например, пользуюсь macOS и на ОС от Microsoft возвращаться не планирую, плачу только за их офис

Это вопрос удобства. Если сравнивать с macos, там у меня есть полный контроль над тем, когда машина включена или выключена. Там у меня открыты нужные мне программы в нужном порядке. На винде ночью будет перезагрузка, и часть этого удобства я теряю. Можно, конечно, купить про версию и поковырять групповые политики, но это уже другая история

Тоже перешёл на мак четыре года назад и возвращаться не планирую

А оправдывать экономию коммерческой компании на управлении качеством интересами общества - что-то во мне восстает против такого подхода :)

в macOS тоже были принудительные обновления, кстати)

пруфов с моей стороны не будет, но что-то такое я помню, у них была дыра и они её принудительно патчили

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

мне эта схема напоминает ту же CoreOS или, скажем, какой-нибудь браузер с его дев, бета и стабл-каналами

но есть 2 важных нюанса: 1. не надо скрывать уровень стабильности от пользователя 2. давать выбор пользователю

оххх

Все что ты предлагаешь, saas-индустрией уже давно изучено, просчитано... и выкинуто в мусор.

1) клиенты за 5 баксов в месяц нерентабельны. LTV едва перевешивает затраты а еще они заебывают саппорт.
2) freemium (бесплатный план) тоже не работает. И вообще повышение узнаваемости бренда засчет дешевого входа - миф.
3) есть такой термин value metric. От него должна зависеть цена. Условно говоря, когда бизнес твоего клиента растет - выручка от него тоже должна расти. Для ХД-систем самая очевидная value-метрика - количество саппорт агентов.
4) у нас цена для "фрилансеров" специально большая. Чтобы не покупали.

все вышесказанное относится к self-funded компаниям. Если есть фандинг и твоя бизнес-модель - раунд-раунд-раунд-IPO можно быть убыточным и на выручку плевать.

я написал не совсем то, на что ты отвечаешь)

1) я согласен, но выше было предложение - не саппортить их
2) это зависит от продукта, полагаю, фримиум везде не нужен точно, бесплатный триал обычно нужен как пробная версия (вместо демо)
3) в случае с хелпдеском можно заменить количество агентов на количество тикетов в работе за месяц и будет явно лучше с позиции справедливой оплаты, потому как это могут быть part-time агенты, а не офисные сотрудники по 8 часов/день
4) это, видимо, связано с тем, что вы их саппортите)

> все вышесказанное относится к self-funded компаниям. Если есть фандинг и твоя бизнес-модель - раунд-раунд-раунд-IPO можно быть убыточным и на выручку плевать.

с этим тоже согласен, я не писал ничего противоречащего этому выше)

3) ой знаешь, не факт. у нас есть небольшие клиенты, типа маленькая сеть отелей, у которых тонна тикетов, генерящихся из букинг систем и все эти тикеты процессятся вообще без участия людей - с помощью наших nocode тулзов. И рулит всем один человек

Почему value-метрика количество саппорт агентов, а не поток тикетов в единицу времени?  В моем случае было мало тикетов, но хотелось чтобы все инженеры (7 человек) были агентами.

я там выше написал, возможно стоит попробовать. Но для такого эксперимента надо много кодить(

хотим ХД as a Platform. Условно, мы с @antonrevyako делаем новые каналы, а инфраструктура и процессинг тикетов ваш

Кастомные поля у вас есть, workflow есть, права есть, нотификации есть… Это же Lotus Notes - пиши любой бизнес софт  где есть необходимость в workflow

любое гос учереждение должно в очередь за таким становиться

вообще, зависит от уровня серьёзности и кастомизированности под задачи) на базовом уровне helpdesk можно сделать через Zapier и Airtable (и прочие nocode инструменты) одним сервисом формы делаются, другой используется как хранилище, третим уведомления, четвёртым данные гоняются между ними

так не нужно ограничивать себя helpdesk. это же просто документы которые ходят между различными состояниями. тикет хелпдеска это просто один из возможных “документов”

я знаю, сейчас в моде no code/low code платформы типа bubble, мб у них что-нибудь получится...

вообще, проблема с превращением хорошего продукта в конструктор в том, что продукт усложняется и это плохо влияет на пользовательский опыт

есть даже мнение о том, что хороший продуктолог - это не тот, кто фичи добавляет, а тот, кто их удаляет из продукта))

но есть и хорошие примеры, например, salesforce - из CRM в конструктор и из конструктора обратно в CRM