Refondre la grille tarifaire à partir de l'usage réel

Le problème

Le churn remontait un motif récurrent, « offre non adaptée ». Certains clients payaient pour des fonctionnalités qu'ils n'ouvraient jamais. D'autres coûtaient cher à servir, parce que leurs demandes spécifiques étaient traitées gratuitement par les équipes CS et Data.

Définir la cible avant les offres

Avant de toucher à la grille, j'ai construit quatre personas et leurs cas d'usage, à partir d'un premier défrichage des données d'usage. L'ICP en est sorti. Il a tranché deux questions : comment compartimenter les offres et quel client adresser. La cible Sales a écarté les grands industriels pour se concentrer sur les PME.

Le cadre du business model existait déjà à mon arrivée. Le travail portait sur la structure des offres.

Arbitrer par la donnée

Trois signaux ont décidé de ce qui restait dans le socle, de ce qui devenait une option et de ce qui ne serait plus gratuit :

• le churn sur le motif « offre non adaptée » ;
• l'usage réel confronté au prix payé, pour les clients qui n'utilisaient pas la moitié des fonctionnalités ;
• le coût de run par client, qu'il fallait faire baisser.

Les demandes spécifiques sont devenues des options payantes.

Migrer les clients existants

J'ai porté moi-même la bascule des clients en place. Ils ont conservé une grande partie de leurs droits acquis, avec certaines limites. Chaque cas croisait deux lectures, ce qu'ils avaient signé et ce qu'ils utilisaient réellement, pour limiter la sensation de perte quand on retire du fonctionnel.

Le produit n'avait aucun système de limitation. J'ai spécifié les quotas par forfait (nombre de contributeurs, nombre d'imports) et leurs règles de gestion. Un import tombé en échec, par exemple, ne décompte pas du quota.