HubSpot Service Hub vs Sales Hub : la question de license qui continue de coûter six chiffres

Si vos relationship managers, account managers ou CSMs post-vente sont assis sur des sièges Sales Hub, il y a une chance raisonnable que vous payiez pour un logiciel qui ne matche pas le travail. L'erreur par défaut est de donner à chaque siège commercial portant un quota une license Sales Hub, puis de découvrir, six mois plus tard, que le workflow quotidien, requêtes ouvertes, escalades, timers SLA, routing d'ownership, n'a nulle part où vivre proprement. Le correctif n'est pas plus de Sales Hub. C'est Service Hub pour le workflow RM avec un siège Sales unique au niveau team-lead pour les vrais deals d'upsell. La décision siège en amont du contrat, et à cinquante RMs la différence de coût annuelle dépasse six chiffres.

Pourquoi cela compte maintenant

La net retention est la métrique sur laquelle les investisseurs s'aiguisent, et le modèle opérationnel derrière reçoit enfin la scrutinité que la motion new-logo a eue pendant une décennie. Le cadrage de Jason Lemkin sur les métriques CS que les VCs évaluent vraiment le pose franchement , dépense CS en pourcentage de l'ARR, charge de portefeuille par CSM, et le gap gross-vers-net retention sont maintenant des questions de diligence de premier ordre. Le système dans lequel l'équipe post-vente travaille produit ces chiffres. Si le CRM est configuré pour une motion hunter et que votre équipe fait tourner une motion SLA, les métriques souffrent à des endroits difficiles à débugger depuis un dashboard.

L'erreur par défaut , un siège Sales pour tous ceux avec un quota

Presque chaque rollout HubSpot mid-stage que nous découvrons commence pareil. Les sales reps ont eu Sales Enterprise, correct. Marketing a eu des sièges Marketing, correct. Et l'équipe post-vente: RMs, AMs, CSMs, parfois un rôle hybride renouvellement-et-expansion, a aussi eu des sièges Sales, parce que quelqu'un avait un chiffre dans son plan et procurement avait une seule colonne pour « commercial ». Le siège matche l'organigramme. Il ne matche pas le travail.

Le souci, c'est que l'UI Sales Hub est construite autour d'un Pipeline ouvert de deals new-logo. Elle suppose que l'utilisateur passe sa journée à bouger des records de gauche à droite à travers des stages qu'il possède de bout en bout. La plupart des RMs en vertical régulé ne font pas ça. Ils gèrent un book fixe, réagissent aux requêtes inbound contre des SLAs contractuels, escaladent les items bloqués, et surfacent l'upsell vers un closer qui fait vraiment tourner le deal. Les primitives Sales Hub, Pipelines de Deal, sequences, prospecting workspaces, ne sont pas la surface quotidienne. Les primitives Service Hub le sont.

Ce que les relationship managers font réellement (ce n'est pas vendre)

Le diagnostic à poser à toute équipe sur le point d'acheter des sièges Sales pour sa fonction post-vente , dans une journée typique, qu'ouvre le RM en premier ? Si la réponse est « la file de requêtes », « la boîte de réception » ou « les items ouverts d'hier », le workflow est de forme service. Si c'est « le Pipeline », c'est de forme sales. À travers les services financiers DACH et le B2B SaaS high-touch, le workflow RM se décompose en quatre jobs :

• Faire tourner l'horloge SLA. Requêtes ouvertes contre fenêtres de réponse contractuelles ou implicites. Le RM possède time-to-first-response et time-to-resolution contre un book défini.
• Router et escalader. Cas dépassant des seuils, complexité ou autorité vont à un team lead, file spécialiste ou owner de processus régulé. Le routing est piloté par règles, pas par Deal.
• Tenir l'historique relationnel. Chaque touchpoint RM: notes d'appel, threads d'emails, outcomes de réunion, s'attache au record client pour que la prochaine interaction démarre depuis le contexte.
• Surfacer l'upsell. Quand la conversation révèle une opportunité d'expansion, le RM tend le Lead qualifié à un closer avec un siège Sales. Le RM fait rarement tourner le Deal de bout en bout.

Trois de ces quatre jobs sont nativement Service Hub. Un est nativement Sales Hub, et c'est la plus petite tranche de temps hebdomadaire.

Les primitives Service Hub dont le workflow RM a vraiment besoin

Tickets, pas Deals

Les tickets dans Service Hub sont le bon objet pour un work item ouvert avec une fenêtre de réponse, un owner, un statut et une fermeture. Les Deals sont le mauvais objet, ils déforment le reporting de vélocité, polluent les forecasts de Pipeline, et cachent le SLA. La première décision d'architecture est de bouger la surface de travail quotidienne hors de l'objet Deal vers les tickets. Les motions de renouvellement sont l'exception qui mérite de rester sur les Deals ; le travail RM réactif non.

Politiques SLA, files et routing

Service Hub livre des politiques SLA (fenêtres de réponse et de résolution par type ou priorité de ticket), des inboxes partagées avec routing skill-based, et des vues de file. Ce sont les primitives dont les RMs ont besoin chaque jour. Il n'y a pas de timer SLA natif sur un record Deal. Les équipes qui boulonnent le tracking SLA aux Deals finissent par écrire des propriétés custom, des valeurs calculées et des workflows pour recréer ce que Service Hub vous donne au jour un.

Routing de conversations et inboxes partagées

La plupart des équipes RM en vertical régulé opèrent contre une inbox partagée , le client écrit à une seule adresse, et le routing décide quel RM, spécialiste ou file d'escalade prend. Cette primitive vit proprement dans Service Hub. Boulonnée à Sales Hub, elle devient un workflow d'assignation fragile sans UI de triage native.

Le modèle hybride , sièges Service pour les RMs, un siège Sales au niveau team-lead

Le pattern qui tient sous audit est hybride. Les RMs siègent sur des sièges Service Hub Professional ou Enterprise avec accès complet aux tickets, SLA et inbox. Le team lead, ou un closer d'upsell dédié unique par pod, porte un siège Sales Hub et fait tourner tout deal qui passe un seuil d'expansion. Le handoff RM-vers-closer est lui-même un workflow , un ticket flaggé « upsell qualified » crée un Deal associé sur le Pipeline du team-lead avec historique de conversation pré-attaché. Le RM n'ouvre jamais le Deal. Le closer n'ouvre jamais la file de tickets. Les deux touchent le même record client.

Ce qu'il ne faut pas faire, c'est doubler la license. Donner à chaque RM à la fois un siège Service et un siège Sales « au cas où » est la forme la plus chère de la même erreur, ça double le coût de siège sans résoudre la question du workflow. Le diagnostic reste , qu'est-ce que l'utilisateur ouvre en premier ?

Cas observé sur le terrain

Une équipe DACH services financiers avec un book de cinquante RMs a hérité d'une configuration HubSpot qui mettait chaque RM sur Sales Hub Enterprise. Le constat d'audit était qu'aucun RM n'avait bougé un stage de Deal le trimestre précédent, chaque record qu'ils touchaient était une requête de service modélisée comme un Deal, avec des propriétés custom essayant de répliquer timers SLA et routing de file. La reconstruction a bougé le workflow RM vers Service Hub Professional avec politiques SLA propres, inboxes partagées et un pipeline de tickets miroir de la logique d'escalade réelle. Trois sièges Sales Hub sont restés au niveau team-lead et upsell dédié. Le delta de coût annuel a dépassé un confortable six chiffres, le reporting de temps de réponse a enfin été rattaché à un champ natif au lieu d'un calcul custom, et le premier onboarding RM sous le nouveau schéma a pris environ un tiers du temps que la cohorte précédente avait nécessité. Le travail n'a pas changé. Le système a cessé de le combattre.

Résolution , un playbook pour la décision de siège

Avant le renouvellement ou le cycle de procurement pour toute équipe post-vente :

1. Auditez le workflow avant le siège. Asseyez-vous avec deux RMs une journée entière. Regardez ce qu'ils ouvrent, dans quel ordre. Si c'est la file ou les items ouverts d'hier, vous achetez Service Hub.
2. Mappez les quatre jobs. SLA, routing, historique, upsell. Écrivez le pourcentage de temps RM hebdomadaire contre chacun. La décision de siège tombe des pourcentages, pas du titre.
3. Bougez la surface quotidienne hors de l'objet Deal. Tickets pour le travail réactif ; Deals seulement pour les vraies motions de renouvellement et expansion. Construisez le pipeline de tickets pour mirorer la logique d'escalade RM.
4. Définissez le handoff d'upsell comme workflow. Un ticket flaggé pour expansion crée un Deal associé sur le Pipeline d'un closer avec historique de conversation pré-attaché. Documentez le trigger, l'owner et le SLA sur le handoff lui-même.
5. Dimensionnez correctement les sièges Sales. Team leads et rôles d'upsell dédiés ont Sales Hub. La plupart des RMs non. Résistez à la double-license « au cas où ».
6. Câblez le reporting contre des champs natifs. Temps de réponse et de résolution doivent se résoudre vers des champs SLA Service Hub, pas des calculs custom sur un Deal. Les champs natifs survivent aux renouvellements et aux passations admin.
7. Refaites tourner l'audit à chaque renouvellement. Les comptes de sièges dérivent. Les rôles changent de forme. Traitez la décision de siège comme une revue trimestrielle contre la carte des quatre jobs.

Si la décision de siège matche le travail, le renouvellement est une conversation budgétaire. Sinon, le renouvellement est un projet de migration.

Là où Checkpoint intervient

L'essentiel du travail CRM post-vente que nous menons chez Checkpoint commence par ce diagnostic exact , une équipe qui a acheté des sièges Sales Hub pour un workflow qui avait besoin de primitives Service Hub, et qui paie pour le mismatch depuis un an. Le déroulement touche licensing de sièges, architecture d'objet, reporting et formation d'équipe. Si votre équipe post-vente fait tourner des tickets-en-tant-que-Deals, parlez-nous avant le prochain renouvellement, l'audit se rembourse en un trimestre. Voyez aussi nos services RevOps et customer success operations pour le modèle opérationnel derrière la décision de siège.

Sources

• Lemkin, Jason. « The Top 10 Customer Success Metrics Investors Really Care About in 2025 with Gainsight's CEO Nick Mehta. » SaaStr. saastr.com
• Blake, Dave. « 100 customer success leaders weigh in on the most important metrics to measure. » OpenView, 10 juillet 2017. openviewpartners.com