La réponse courte
Sales Cloud gère une transaction en cours – une unité de travail qui dure des semaines ou des mois, se mesure par sa probabilité de clôture et aboutit une fois clôturée. Service Cloud gère une demande résolue – une unité de travail qui dure des heures ou des jours, se mesure par son temps de réponse et de résolution, et aboutit une fois clôturée rapidement et sans récidive.
C'est cette différence, et non la liste des fonctionnalités, qui détermine le choix. Si vous gérez un pipeline, optez pour Sales Cloud. Si vous gérez une file d'attente avec un SLA, optez pour Service Cloud. Si vous gérez un client qui achète et se plaint, utilisez les deux, sur le même Compte.
La différence en termes opérationnels
| Dimension | Sales Cloud | Service Cloud |
|---|---|---|
| Objet central | Opportunité | Requête |
| Cycle de vie | Semaines à mois | Heures à jours |
| Indicateur clé | Taux de réussite, Précision des prévisions | Première réponse, Taux de résolution au premier contact (FCR), Satisfaction client (CSAT) |
| Mécanisme d'attribution | Propriété individuelle à long terme | Routage dynamique selon la disponibilité |
| Source de charge | Nombre d'affaires actives | Pics imprévus sur les canaux |
| Composant de connaissance | Playbooks et tarification | Base de connaissances intégrée |
La ligne la plus importante est le mécanisme d'attribution. Dans la vente, la propriété individuelle est une valeur – le client souhaite un contact permanent. Dans le service, la propriété individuelle est un problème – elle crée des files d'attente personnelles qui se bloquent lorsqu'un agent est en congé.
Quand le choix est évident
Sales Cloud uniquement convient à une organisation qui vend via un processus continu et dont le support après-vente est minimal ou géré par un partenaire – par exemple, un fournisseur d'équipement qui vend par l'intermédiaire de revendeurs et ne gère pas de centre d'appels.
Service Cloud uniquement convient à une organisation dont toute l'interaction avec le client consiste à traiter des demandes – une entreprise de services opérationnelle, une entité publique ou un fournisseur d'infrastructure avec des contrats existants.
Les deux sont nécessaires en cas de renouvellement, d'Upsell ou de rétention : dès qu'un représentant du service client doit savoir que le client est en cours de renouvellement, et qu'un représentant des ventes doit savoir que le client a ouvert trois incidents graves ce mois-ci, la séparation devient un obstacle.
Comment connecter sans dupliquer les données
C'est le point où les implémentations combinées échouent. La règle : Compte et Contact sont une seule couche partagée. Il n'y a pas de "client de vente" et de "client de service" séparés.
Trois décisions en découlent :
- Propriété de l'enregistrement client - Qui met à jour les coordonnées, l'adresse et la structure organisationnelle. Généralement le service, car il communique plus fréquemment avec le client.
- Visibilité mutuelle - L'agent de service voit les transactions ouvertes en mode lecture seule ; l'agent commercial voit les requêtes ouvertes et l'indicateur de satisfaction. Les deux directions sont définies dans le modèle de partage, pas par copie de champs.
- Déclencheurs inter-domaines - Une requête critique chez un client en renouvellement génère une alerte pour le responsable de compte. Ce mécanisme est plus précieux que n'importe quel tableau de bord consolidé.
Une explication approfondie sur les permissions et la visibilité est disponible dans Modèle de partage et visibilité dans Salesforce.
Licences: ce qu'il faut savoir avant de comparer les prix
La licence Service Cloud est supra-catégorielle : elle inclut les fonctionnalités de base de Sales Cloud. Par conséquent, un utilisateur ayant besoin des deux n'a pas besoin de deux licences distinctes. L'inverse n'est pas vrai : une licence Sales n'inclut pas la gestion des requêtes (Case management), les droits (Entitlements) ou la base de connaissances (Knowledge).
La signification pratique : un calcul de coût correct commence par la cartographie des utilisateurs en fonction de ce qu'ils font réellement, et non du département auquel ils appartiennent. Un agent qui accède occasionnellement à une transaction deux fois par an n'est pas un utilisateur de Sales.
Ordre d'implémentation lorsque les deux sont nécessaires
Une implémentation parallèle peut sembler efficace, mais en réalité, elle double les risques : deux processus qui évoluent simultanément, deux groupes d'utilisateurs en formation, et l'impossibilité d'attribuer une amélioration ou un échec à une source précise.
L'ordre recommandé est de commencer par le côté présentant la douleur la plus mesurable – généralement le service, car le temps de réponse et le taux d'attrition sont déjà mesurés – et d'ajouter l'autre côté après deux mois de fonctionnement stable. La couche partagée (Compte, Contact, permissions) est construite dès la première vague, même si un seul côté est mis en production, sinon la deuxième vague exigera une refonte.
Résumé
La question n'est pas de savoir quel produit est le meilleur, mais quelle unité de travail l'organisation gère : une transaction en cours ou une requête résolue. La plupart des organisations matures gèrent les deux, et la véritable décision n'est alors pas quoi acheter, mais comment maintenir une couche client unique sous les deux.