Dans cette série d’articles “Comment créer un prix en B2B”, je fais une revue des différentes méthodes de pricing B2B (à ne pas confondre avec les techniques de pricing ou les stratégies de pricing, sujets que j’aborderai dans quelques temps 😉 ). Aujourd’hui c’est le tour du function-based pricing.
Je vous ai donc parlé il y a quelques semaines de cost-based pricing, de competition-based pricing et de mon vélo. Son vélo ? ça y est, il a perdu la tête… Mais non, c’était juste un exemple pour vous illustrer le product-based pricing. Et d’ailleurs je vous promets de reprendre cet exemple dans cet article. Je l’aime mon vélo.
Je vous préviens, les choses vont se compliquer un peu avec le function-based pricing.
“Function-based pricing” Vous allez vous dire “À nouveau il nous parle d’un truc dont personne ne parle” ou “il a encore inventé un terme barbare comme ses pricingliabules“. Et effectivement comme pour le product-based pricing, personne ne parle de function-based pricing. Et pour cause, quasiment aucune entreprise ne l’utilise ou, devrais-je dire, personne n’est conscient de l’utiliser.
Alors pourquoi en parler ? Parce-que cette méthode est bien plus efficace que le cost-based, product-based ou competition-based pricing.
L’efficacité d’une méthode se mesure au rapport entre gains et difficulté de mise en œuvre. En function-based pricing Les gains de marge et volume de vente sont beaucoup plus importants qu’en cost-based ou product-based et la mise en œuvre est bien plus rapide qu’en competition-based. Le retour sur investissement de cette méthode est extrêmement rapide.
En quoi consiste le function-based pricing ?
OK, je vois, vous vous impatientez, alors je lève le rideau sur la scène : le function-based pricing est l’équivalent du product-based pricing mais basé sur les fonctions du produit / service. Ta-dam !!! Voilà tout est dit…
Mais non, je vais aller plus loin, vous dévoiler ce qu’il y a derrière la scène. Et pour illustrer la chose, je vous l’ai promis, je vais à nouveau vous parler de mon vélo.
Je vous disais qu’en product-based pricing ce sont les caratéristiques produit qui sont utilisées. Pour être plus précis, ce sont des caractéristiques techniques. Et j’avais pris la taille des roues pour exemple. Reprenons donc ces roues pour en extraire les caractéristiques fonctionnelles.
En d’autres termes, ces roues servent à quoi ?
- À adhérer au sol (fonction de contrainte pour les puristes de l’analyse fonctionnelle)
- À transmettre un effort entre le reste du vélo et la route. En clair à “mouvoir le vélo” (fonction de transfert)
Mon but n’est pas ici de faire une analyse fonctionnelle complète du vélo. Je m’arrête donc là, mais la roue remplit évidemment d’autres fonctions (amortissement, fixation au reste du vélo…).
Prenons la fonction “transmettre un effort”. Elle peut être caractérisée par
- la puissance à transmettre
- l’énergie à transmettre
Il se trouve que la puissance à transmettre dépend du cycliste et de ses biscottos. Par contre, l’énergie ne dépend pas du cycliste, elle correspond à l’effort qu’il est nécessaire de faire pour parcourir une certaine distance avec mon vélo. Cette énergie dépend de la route (si elle monte il faut plus d’énergie) et de mon vélo. Donc pour une route donnée, elle ne dépend plus que de mon vélo.
À ce stade il est nécessaire de faire un parallèle pour bien comprendre. Quand vous achetez votre voiture, vous regardez combien elle consomme et on vous dit 7l/100km par exemple. Ce 7l/100km correspond à la quantité d’énergie (7l de carburant en l’occurrence) qu’il est nécessaire de dépenser pour faire 100 km. Vous imaginez bien que si c’est 100 km en montée vous allez consommer plus que si c’est 100 km en descente. Voilà pourquoi les fabricants automobiles utilisent ce qu’on appelle un cycle normé (cycle = parcours ici, je préfère préciser, comme je parle de vélo…). C’est sur ce cycle normé commun à tous que l’on peut mesurer 7l/100km.
On peut tout à fait imaginer qu’il existe un jour un cycle normé pour les vélos. Les fabricants nous diraient alors quelle quantité d’énergie il faut dépenser pour mouvoir le vélo sur ce parcours (heps les fabricants de vélo, c’est copyright cette idée 💡 ).
Alors la fonction “Mouvoir le vélo” pourrait être caractérisée par un niveau d’énergie A, B, C, D (comme pour les machines à laver) et en voyant un vélo en vente vous pourriez vous dire : “tiens avec ce vélo qui a l’étiquette A cela sera plus facile de pédaler qu’avec tel autre qui a l’étiquette C”.
Si je vous demandais de choisir entre 2 vélos : l’un a des roues de 22″ et l’autre de 11″. Celui de 11″ vous demande 2 fois moins d’effort que celui de 22″ pour parcourir la même distance à la même vitesse. Lequel choisissez vous ?
Évidemment les vélos ne sont pas vendus de cette manière, nous sommes bien d’accord. Cela illustre bien le fait qu’ils sont vendus en product-based pricing et non en function-based pricing.
Cela a été un peu long, désolé, mais c’était nécessaire pour bien comprendre la différence entre product-based pricing et function-based pricing.
Si les vélos étaient vendus en function-based pricing les prix seraient peut-être dépendants du niveau d’effort pour le mouvoir. Et toutes autres fonctions égales par ailleurs on verrait ce genre de tarif :
- Vélo énergie A : 200 €
- Vélo énergie B : 175 €
- Vélo énergie C : 150 €
- Vélo énergie D : 125 €
Et mon vélo aurait peut-être été plus abordable, parce-qu’il est certes très joli avec ses roues de 22″, mais un peu lourd à mouvoir et demande beaucoup d’énergie. Il aurait peut-être eu l’étiquette C 🙄 .
Si vous cernez désormais peut-être les avantages de ce type de pricing pour les clients, il est encore difficile d’en cerner les avantages pour l’entreprise qui vend ses vélos.
Je vous parlerai donc la semaine prochaine des avantages et faiblesses de cette méthode…