Sur cette page
Une période d’essai vous demande d’évaluer un produit au rythme de l’entreprise. Ce n’est pas idéal lorsqu’on développe le soir, qu’on reprend un ancien projet ou qu’on cherche simplement à voir si l’outil convient à sa manière de travailler.
Je veux qu’un petit espace Bisonflow reste utile sans compte à rebours. J’ai aussi besoin que les offres payantes couvrent le coût du service. Prétendre que ces deux objectifs ne se heurtent jamais donnerait un joli texte et de mauvaises décisions tarifaires.
Voici la logique d’une nouvelle offre envisagée. Elle n’est pas implémentée. Les offres, le paiement et les abonnements actuels s’appliquent toujours ; cet article ne change le prix de personne.
Free doit permettre de commencer un vrai projet
La proposition prévoit une offre Free permanente pour une personne, deux projets et un petit volume de création. La limite de travail envisagée est de 200 créations de tâches sur toute la vie de l’espace. Ce n’est délibérément pas une limite de 200 tâches ouvertes.
Une limite qui se recharge quand on supprime du travail incite à détruire l’historique que le produit est censé conserver. Je préfère annoncer clairement l’allocation plutôt qu’encourager ce comportement.
Atteindre un quota doit bloquer l’action suivante qui le dépasse. Cela ne doit ni cacher le travail existant ni transformer l’export en prise d’otage. Il reste à implémenter et tester ces règles, notamment les relances, les imports et le décompte des projets conservés.
Il faudra aussi des limites claires sur le stockage et l’IA, qui ont un coût réel. Je n’annoncerai pas d’usage illimité avec une politique encore indécise.
Partager ne devrait pas exiger l’offre standard la plus chère
La distinction actuelle entre Individual et Team est trop grossière pour la direction du produit. Un petit groupe peut avoir besoin d’un espace partagé sans rôles configurables ni structure d’équipes.
Basic inclurait le workflow principal et la collaboration pour les petits groupes. Business ajouterait budgets, groupes et permissions configurables. Enterprise resterait une discussion sur des exigences et des services convenus.
La séparation doit être visible dans le produit. Avant d’inviter quelqu’un, il faut comprendre la limite concernée. Un propriétaire doit pouvoir gérer la sécurité, retirer un membre et transférer la propriété sans acheter une offre supérieure pour de l’administration élémentaire.
Les noms des offres n’aident que si ces limites se comprennent dans l’usage quotidien.
Pas de tableau tarifaire avant d’avoir fixé les règles
La proposition contient des tarifs provisoires, mais un prix sans unité de facturation précise reste incomplet. Quels membres comptent ? Que deviennent les invitations en attente ? Comment se passe une rétrogradation ? Comment un abonné actuel passe-t-il à la nouvelle offre ?
Ces questions changent une facture. Il faut y répondre avant qu’une belle carte tarifaire laisse penser que tout est arrêté.
La direction envisagée est une facturation par membre pour les offres payantes en libre-service, mensuelle ou annuelle. Les tarifs finaux, allocations, critères et conditions de transition accompagneront l’offre implémentée. Enterprise passerait par un contrat annuel convenu.
D’ici là, la page tarifaire actuelle décrit ce qui est disponible. Elle ne doit pas changer silencieusement parce qu’un article introduit un nouveau nom.
Les abonnements existants demandent une transition distincte
Renommer Individual en Basic dans un document ne permet pas de modifier la facture d’un client. Même chose pour Team et Business.
L’implémentation doit préserver les correspondances d’abonnement, tester les changements d’offre dans les deux sens et annoncer explicitement toute transition proposée. Le travail qui dépasse les limites d’une offre inférieure doit rester accessible. Une rétrogradation ne doit pas supprimer projets, documents ou personnes pour faire rentrer les chiffres.
Avant tout changement client, il faut vérifier le comportement réel des factures et communiquer les conditions applicables. C’est une release à part entière, même si elle suit la refonte 2.0.
Ce que je veux encourager
Free doit laisser à un développeur indépendant assez de place pour comprendre si Bisonflow l’aide. Basic doit rendre la collaboration raisonnable. Business doit justifier sa place lorsque l’organisation a besoin des contrôles et du suivi financier supplémentaires.
Je préfère perdre une montée en gamme que la provoquer en compliquant l’accès à un projet existant. Le produit aide à conserver le travail ; son modèle commercial doit suivre cette logique.
Il reste du chemin entre cette proposition et une offre disponible à la souscription. J’en partage la direction maintenant parce que les raisons méritent d’être discutées avant de changer le paiement, pendant que les règles peuvent encore évoluer.
