TwitterL’expérience montre que la plupart des éditeurs SaaS se préoccupent du sujet pricing sur le tard. C’est pourtant une problématique clé qui impacte l’application elle-même et son architecture.
Plusieurs raisons peuvent expliquer cette faiblesse : Vision à long terme défaillante, tâtonnements dans l’élaboration du business model, priorité axée sur une mise en ligne le plus rapidement possible du service, difficultés techniques à surmonter. En reportant ce sujet, on s’expose à des difficultés difficilement surmontables par la suite.
Est-ce raisonnable de risquer une situation de blocage à un moment clé de l’expansion d’un projet ? Lorsque un produit atteint un niveau de maturité intéressant pouvant séduire de nouveaux profils, on découvrirait ce nouveau sujet devenu absurdement complexe ? à savoir :
1) Quel modèle de prix mettre en place ?
2) comment l’intégrer à l’application existante ?
Concernant le point 1), la plupart des éditeurs ont (espérons-le) une expérience solide de l’élaboration de modèles de prix. Cependant, difficile de passer sans douleur d’un modèle archaïque (1 transaction ponctuelle) à un modèle s’inspirant des opérateurs télécoms, où la grande valeur de l’éditeur réside dans la capacité de fidélisation de ses clients.
Pas facile non plus de trouver l’unité de comptage la plus pertinente. Sur ce point, mieux vaut rechercher la plus simple, même si elle est imparfaite (Basecamp – tarification au nombre de projets, Message Business – tarification au nombre d’emails envoyés…)
Pour le point 2) Une fois esquissés les contours de ce modèle de prix de type abonnement, vient la problématique – ardue – de l’intégration du système de facturation. Les impacts sur l’application elle-même sont nombreux, des incohérences de fond pouvant alors émerger. Je pense notamment à un cloisonnement des données absent ou au contraire trop important qui donnerait du fil à retordre aux traitement de facturation. En définissant en amont les informations clés liées à la facturation, on gagne grandement en souplesse par la suite – on évite en prime quelques casses-têtes et maux de têtes… -.
Le mieux reste de mettre en place toute l’infrastructure de son système de facturation dès la version beta de son service. Plus facile à dire qu’à faire, étant donné que cette période est riche de problématique techniques à résoudre. D’OÙ l’intérêt de systèmes out-sourcés, qui peuvent se plugger sur un service SaaS, solution que j’évoquais il y a quelques semaines.
Cyrille
L’expérience montre que la plupart des éditeurs SaaS se préoccupent du sujet pricing sur le tard. C’est pourtant une problématique clé qui impacte l’application elle-même et son architecture.
Plusieurs raisons peuvent expliquer cette faiblesse : Vision à long terme défaillante, tâtonnements dans l’élaboration du business model, priorité axée sur une mise en ligne le plus rapidement possible du service, difficultés techniques à surmonter. En reportant ce sujet, on s’expose à des difficultés difficilement surmontables par la suite.
Est-ce raisonnable de risquer une situation de blocage à un moment clé de l’expansion d’un projet ? Lorsque un produit atteint un niveau de maturité intéressant pouvant séduire de nouveaux profils, on découvrirait ce nouveau sujet devenu absurdement complexe ? à savoir :
1) Quel modèle de prix mettre en place ?
2) comment l’intégrer à l’application existante ?
Concernant le point 1), la plupart des éditeurs ont (espérons-le) une expérience solide de l’élaboration de modèles de prix. Cependant, difficile de passer sans douleur d’un modèle archaïque (1 transaction ponctuelle) à un modèle s’inspirant des opérateurs télécoms, où la grande valeur de l’éditeur réside dans la capacité de fidélisation de ses clients.
Pas facile non plus de trouver l’unité de comptage la plus pertinente. Sur ce point, mieux vaut rechercher la plus simple, même si elle est imparfaite (Basecamp – tarification au nombre de projets, Message Business – tarification au nombre d’emails envoyés…)
Pour le point 2) Une fois esquissés les contours de ce modèle de prix de type abonnement, vient la problématique – ardue – de l’intégration du système de facturation. Les impacts sur l’application elle-même sont nombreux, des incohérences de fond pouvant alors émerger. Je pense notamment à un cloisonnement des données absent ou au contraire trop important qui donnerait du fil à retordre aux traitement de facturation. En définissant en amont les informations clés liées à la facturation, on gagne grandement en souplesse par la suite – on évite en prime quelques casses-têtes et maux de têtes… -.
Le mieux reste de mettre en place toute l’infrastructure de son système de facturation dès la version beta de son service. Plus facile à dire qu’à faire, étant donné que cette période est riche de problématique techniques à résoudre. D’OÙ l’intérêt de systèmes out-sourcés, qui peuvent se plugger sur un service SaaS, solution que j’évoquais il y a quelques semaines.
Cyrille
19 comments - add a comment
