Ce qu'on a trouvé en arrivant
L'entreprise avait une jeune recrue en ops de vente, débrouillarde, qui avait fait du bon travail pour mettre HubSpot en place dans les premiers jours. Les pipelines fonctionnaient. Les contacts étaient suivis. Les transactions avançaient. Pendant un temps, c'était suffisant.
Puis l'entreprise a grandi, et cinq départements se sont tous mis à construire dans le même compte HubSpot. Pas d'architecture partagée. Pas de conventions de nommage. Pas de documentation. Chaque équipe créait ce dont elle avait besoin, quand elle en avait besoin, sans coordination.
Le résultat était prévisible : des propriétés dupliquées entre les objets, des workflows en collision, des automatisations qui déclenchaient des choses qu'elles n'auraient pas dû. HubSpot était devenu un entrepôt où chaque équipe déversait tout.
Les finances ne pouvaient pas faire confiance aux chiffres
Stripe était connecté à HubSpot, mais environ un sync sur trois échouait. Les intégrations personnalisées brisaient en silence. Personne ne pouvait distinguer ce qui avait été synchronisé de ce qui ne l'avait pas été sans vérifier manuellement.
Le pipeline de renouvellement était construit sur les dates de début des transactions. Mais la facturation commençait en réalité à la date du premier paiement. Chaque date de renouvellement dans le système était erronée. Personne ne l'avait remarqué parce que personne n'avait documenté ce que "date de début" était censé signifier.
Les abonnements n'avaient pas de date de fin. Les clients qui signaient pour un an se faisaient facturer au treizième mois et appelaient pour se plaindre. Au pire moment, l'entreprise a traité 60 000$ en remboursements en un seul mois. Le taux de renouvellement stagnait à 10%.
Le directeur financier passait des jours à clôturer chaque mois. Pas parce que le volume était élevé, mais parce que rien ne pouvait être considéré fiable sans contre-vérification manuelle.
Ce qu'on a réussi à corriger
La réconciliation des revenus en fin de mois est passée de jours de vérification manuelle à environ 3 heures, avec des chiffres fiables que le directeur financier pouvait réellement approuver.
Nous avons mis en place un système d'intake structuré comme point unique pour consigner, catégoriser et acheminer les demandes ops afin que l'équipe puisse distinguer les enjeux produit des tâches ops, prioriser correctement et gérer son propre temps. L'équipe ops a récupéré 6 à 8 heures par semaine.
Nous avons documenté les workflows RevOps fondamentaux pour la première fois : la logique de facturation et le comportement de synchronisation Stripe, les déclencheurs de renouvellement et les définitions des étapes du pipeline, le routage des leads et les critères de transfert, l'intake des demandes et les chemins d'escalade, la cartographie des sources de vérité à travers les systèmes.
La vraie leçon
Cette entreprise ne manquait pas d'outils, de budget ou de talent. La recrue ops originale avait construit quelque chose de réel, et avec le bon soutien, la fondation était là pour scaler.
Ce qui manquait, c'était la clarté du leadership. Pas d'organigramme. Pas de modèle de propriété. Pas de volonté de maintenir une décision assez longtemps pour qu'elle prenne effet. Quand tout est la responsabilité de tout le monde, rien ne se règle.
Le RevOps ne peut pas réussir dans le vide. Il a besoin de trois choses de la part du leadership : une propriété définie, une structure stable, et assez de patience pour laisser l'architecture prendre forme avant de rénover à nouveau.
On ne considère pas ceci comme une histoire de succès. Il restait tellement à faire. Mais parfois une bataille ne peut pas être gagnée quand on pousse contre le courant de la culture d'une organisation. Les problèmes n'étaient pas techniques. Ils étaient structurels. Et la structure commence par le sommet.