Les CRM horizontaux meurent de la page blanche
« Objets personnalisés illimités » sonne comme une fonctionnalité et se comporte comme une facture. Voici pourquoi nous avons bâti une plateforme horizontale et refusé de la livrer vide.
- Publié le
- Lecture
- 6 minutes
- Par
- L’équipe UnifyLoop
Sur cette page 5
Il existe une façon bien précise dont un logiciel flexible échoue, et elle se joue dans les vingt premières minutes. Vous vous inscrivez. On vous dit que vous pouvez tout modéliser. On vous montre un espace de travail vide et un bouton « Créer un objet ». Et vous fermez l’onglet, parce que vous êtes venu résoudre un problème et qu’on vous a donné un exercice de modélisation.
Nous avons bâti une plateforme horizontale : un modèle de données que vous définissez, un seul moteur de requêtes, un seul moteur d’automatisation. Et nous pensons que la livrer sous forme d’espace de travail vide aurait été une erreur, pour des raisons qui méritent d’être explicitées.
La flexibilité est un coût à l’inscription et un atout au sixième mois
La possibilité de tout configurer a une vraie valeur, mais elle arrive tard. Le premier jour, vous ne savez pas de quels champs vous aurez besoin, donc les choisir revient à deviner. Au sixième mois, vous savez exactement ce qui ne va pas dans votre configuration, et à ce stade c’est la rigidité qui vous fait mal.
Les deux façons d’échouer sont donc symétriques. Les produits rigides sont agréables à l’inscription et pénibles au sixième mois, quand vous vous surprenez à stocker un bien immobilier dans un champ appelé Nom de l’affaire. Les produits page blanche sont pénibles à l’inscription et agréables au sixième mois, si vous survivez à l’inscription.
La solution n’est pas de choisir un camp. C’est d’arriver configuré et de rester configurable.
Ce qu’est vraiment un pack
Les packs arrivent bientôt, en commençant par l’immobilier. À l’inscription, nous vous demanderons ce que vend votre entreprise. Répondez « immobilier » et l’espace de travail installera un pack : Biens, Annonces, Acheteurs, Visites et Offres sous forme d’objets avec des champs pertinents, un pipeline acheteurs avec de vraies étapes, et des automatisations de relance déjà en place.
Le point essentiel, c’est qu’un pack est fait de données, pas de code. Tout ce qu’il installe est le même type de configuration que vous auriez pu créer à la main, ce qui veut dire que vous pouvez tout modifier. Renommez un objet, supprimez une étape, reconfigurez une automatisation. Rien n’est un cas particulier qui résiste à la modification parce qu’il serait compilé dans le produit.
C’est aussi le test le plus exigeant pour la plateforme qui se trouve dessous. Si le pack avait besoin d’une seule exception codée en dur, la couche de métadonnées serait incomplète. Construire le produit immobilier sous forme de pack plutôt que de fonctionnalités, c’est notre façon de prouver qu’elle ne l’est pas.
Un espace de travail vide devrait être l’issue de secours, pas le point de départ.
Comment distinguer un vrai pack d’une galerie de modèles
Beaucoup de produits proposent des modèles par secteur. La plupart se résument à quelques champs personnalisés et un pipeline aux étapes renommées. C’est cosmétique, et vous les aurez dépassés en quinze jours. Quatre questions font la différence, et vous pouvez les poser pendant un essai :
- Installe-t-il des objets, ou seulement des champs sur les objets existants ? Un bien qui n’est en réalité qu’une affaire avec des champs en plus produira des rapports sans aucun sens, pour toujours.
- Les automatisations sont-elles réelles et actives, ou ce sont des exemples à construire vous-même ? « Voici un modèle que vous pourriez mettre en place », c’est un document, pas un produit.
- Pouvez-vous supprimer ou renommer tout ce qu’il a installé, y compris les objets ? Si certaines parties résistent à la modification, c’était du code déguisé en configuration.
- L’éditeur construit-il ses propres produits sectoriels de cette façon ? Si son produit phare pour un secteur est codé en dur et que les packs sont une fonction secondaire, les packs resteront toujours de seconde classe.
Pourquoi cela façonne la feuille de route, pas seulement le discours
Miser sur les packs impose des décisions sur l’ordre des travaux qu’il serait sinon facile de repousser. Le format des packs doit être conçu tôt (avant que la place de marché qui les distribuera existe, et avant toute pression extérieure pour le définir), car le premier pack est en cours de construction et chaque raccourci pris aujourd’hui deviendra plus tard une exception codée en dur.
Cela change aussi le coût de l’expansion. Un nouveau secteur, c’est du travail de contenu : modéliser les objets, définir le pipeline, écrire les automatisations, livrer. Il faut un expert du métier et quelques semaines, pas un trimestre d’ingénierie. La rentabilité d’une entrée dans l’assurance ou le recrutement ne dépend plus de la disponibilité de l’équipe plateforme.
Ce que nous n’affirmons pas
Deux limites, en toute honnêteté, car il serait facile ici d’en promettre trop.
Un pack est un solide point de départ, pas une mise en œuvre complète de votre activité. Si votre façon de travailler sort vraiment de l’ordinaire (et si vous êtes bon dans votre métier, une partie l’est), vous changerez des choses. Avec le pack, vous modifiez quelque chose qui fonctionne au lieu de tout assembler à partir de rien.
Et les packs n’auront pas tous la même profondeur. L’immobilier sera le plus complet, parce que c’est là que se trouve notre connaissance du métier et qu’il sert de preuve de concept. Les autres seront solides, mais pas autant éprouvés sur le terrain. Nous préférons le dire maintenant plutôt que de vous laisser le découvrir la troisième semaine.
Le principe général, c’est ce que nous défendrions n’importe où : rendez les vingt premières minutes concrètes, et gardez les six mois suivants modifiables. Presque tous les produits qui meurent de la page blanche ont réussi la première moitié et pris la seconde à l’envers.