Dans le monde des affaires d’aujourd’hui, où tout va vite, pouvoir assembler des produits et services de manière rapide et exacte est un gros avantage.

Salesforce, un leader mondial des outils pour gérer les clients (CRM), propose ainsi une solution adaptée : le Configurateur Avancé de Revenue Cloud. Cette nouveauté, mise en avant dans la version « Spring ’25 », promet de changer la façon dont les entreprises créent, préparent et vendent leurs offres.

Cet article va explorer en détail ce que le Configurateur Avancé peut faire, de quelles manières il utilise son langage spécial (CML), et les différents types de règles qu’il permet de créer pour s’assurer que les produits restent configurés correctement et sans erreur.

1/ Qu’est-ce que le Configurateur Avancé ?

Le Configurateur Avancé est un moteur puissant. Son but est de trouver rapidement la meilleure solution en cherchant des objectifs et en gérant des règles. C’est un grand pas en avant pour les entreprises qui vendent beaucoup de produits différents, des ensembles de produits (bundles) et des offres que l’on peut personnaliser.

Au cœur de cette solution, il y a le Constraint Modeling Language (CML). C’est un langage de programmation fait pour décrire comment les produits sont configurés (les produits eux-mêmes, leurs catégories, leurs caractéristiques, et les règles de configuration). Il offre une grande souplesse et une grande précision.

La façon de configurer les produits se base sur des modèles de contraintes. Ce sont des groupes de types de produits liés. Chaque type contient des caractéristiques (attributs), des liens (relations) avec d’autres produits, et des règles. Le CML permet de créer des hiérarchies de types, de réutiliser des éléments (héritage) et de modifier des règles (surcharge). Cela rend la gestion des produits complexes plus facile.

2/ Les Bases : CML, types, attributs et relations

Pour bien comprendre le Configurateur Avancé, il faut connaître ses idées principales :

• CML : Il s’agit du langage de base. Il sert à décrire les règles et la structure des produits de manière claire.
• Modèle de contraintes : Cela constitue un ensemble de types de produits qui dépendent les uns des autres.
• Type : C’est une chose que l’on peut configurer (un produit, un ensemble de produits). Il a des caractéristiques (attributs) et des liens (relations). Par exemple, une Boîte de Chocolats est un type, et Chocolat Noir, Chocolat Blanc, Emballage sont des types liés.
• Attribut : Cela concerne une caractéristique du produit (par exemple, Taille pour un T-shirt). Chaque attribut a des valeurs possibles (par exemple, S, M, L pour la taille).
• Relation : Cela représente un lien qui montre comment des types sont connectés à l’intérieur d’un autre type. Cela sert à créer des structures imbriquées, comme une Boîte de Chocolats qui a une relation avec Chocolat Noir et Chocolat Blanc.

La configuration commence souvent par importer les informations sur les produits et les ensembles de produits depuis le système de gestion de catalogue de Salesforce (PCM) vers la structure CML. Cela garantit que les définitions de produits sont cohérentes et prépare le modèle pour la création des règles.

3/ Types de règles et contraintes du Configurateur Avancé Salesforce Revenue Cloud

Le Configurateur Avancé propose de nombreuses règles et contraintes pour gérer les configurations les plus compliquées. Voici les principaux types, avec des exemples pour mieux comprendre.

1. Règles simples (basic logic constraints)

Ces règles agissent comme des barrières, elles s’assurent que les choix respectent toujours des limites claires. Elles disent qu’une condition doit toujours être vraie. Si ce n’est pas le cas, le système essaie de corriger les choses ou explique pourquoi ça ne va pas.

Objectif pour l’entreprise : empêcher les vendeurs de créer des produits qui ne respectent pas les règles de base.

Exemple : assurer qu’une Table de Jardin est toujours en bois si elle est vendue avec des Chaises Assorties.

type TableDeJardin {

@(defaultValue = "Métal")

string Matériau = ["Bois", "Métal", "Plastique"];

boolean ChaisesAssorties;

constraint (ChaisesAssorties == true -> Matériau == "Bois", "La table doit être en bois pour les chaises assorties");

}

Explication : Si un vendeur essaie de choisir des chaises assorties avec une table en métal, le système affichera le message « La table doit être en bois pour les chaises assorties », l’empêchant de valider ce choix incorrect.

2. Règles conditionnelles (conditional logic constraints)

Ces règles ajoutent une condition : si une première chose est vraie, alors une deuxième chose doit aussi l’être.

But pour l’entreprise : aider les vendeurs à faire les bons choix en fonction de ce qu’ils ont déjà choisi.

Exemple : si un client choisit un Forfait Téléphonique « Illimité », il doit aussi prendre l’Option « Appels Internationaux »

type ForfaitTéléphonique {

    string TypeDeForfait = ["Basique", "Standard", "Illimité"];

    boolean AppelsInternationaux;

    constraint (TypeDeForfait == "Illimité" -> AppelsInternationaux == true, "Le forfait illimité inclut les appels internationaux.");

}

Explication : Si le vendeur sélectionne le forfait illimité, le système s’assurera que l’option appels internationaux est automatiquement activée. S’il tente de la désactiver, un message d’erreur apparaîtra.

3. Règles de préférence (preference rules)

Contrairement aux règles simples, celles-ci ne sont pas obligatoires. Elles proposent des conditions qui peuvent être vraies, mais l’utilisateur peut les changer. Le système apprend si une préférence est ignorée, et ne la propose pas à nouveau pour cette fois.

But pour l’entreprise : proposer des choix par défaut ou des suggestions que l’utilisateur peut modifier.

Exemple : si un client achète un Vélo de Course, la Couleur par défaut suggérée est rouge vif.

type VéloDeCourse {

    string Couleur = ["Bleu Océan", "Vert Forêt", "Rouge Vif", "Noir Mat"];

    preference (true -> Couleur == "Rouge Vif"); // Une préférence simple sans pré-condition complexe

}

Explication : Si un vendeur choisit un vélo de course, la couleur rouge vif sera proposée, mais il pourra la changer s’il le souhaite.

4. Règles de message (message rules)

Ces règles servent à afficher des messages à l’utilisateur selon certaines conditions. Les messages peuvent être de différents niveaux : info (information), warning (avertissement) ou error (erreur). Ils n’empêchent pas la configuration mais donnent des informations utiles.

But pour l’entreprise : donner des conseils, des avertissements ou signaler des erreurs aux vendeurs en direct.

Exemple : si un client choisit un Livre « Science-Fiction » et qu’il n’a pas encore choisi de Genre Préféré, afficher un message info pour lui suggérer de le faire.

type Livre {

    string Genre = ["Fantaisie", "Science-Fiction", "Thriller"];

    string GenrePréféré; // Peut être vide

    message (Genre == "Science-Fiction" && GenrePréféré == null, "Pensez à définir votre genre préféré pour des recommandations futures !", "Info");

}

Explication : Ce message informe le client d’une suggestion sans bloquer son achat.

5. Règles d’obligation (require rules)

Les règles dites d’obligation forcent l’ajout automatique de certains éléments si des conditions sont remplies. Cela rend la configuration plus rapide et réduit les erreurs.

But pour l’entreprise :s’assurer que les éléments nécessaires sont toujours inclus dans un ensemble.

Exemple : si un Kit de Bricolage est sélectionné, un Manuel d’Instructions est automatiquement ajouté.

type KitDeBricolage {

    relation ManuelInstructions ManuelInstructions;

    require (true, ManuelInstructions[ManuelInstructions]); // Toujours ajouter le manuel

}

Explication : Dès qu’un vendeur ajoute un kit de bricolage, le manuel est automatiquement inclus, évitant ainsi un oubli.

6. Règles d’exclusion (exclude rules)

Ces règles forcent la suppression de certains éléments si des conditions sont remplies.

But pour l’entreprise : empêcher les combinaisons de produits qui ne vont pas ensemble.

Exemple : si un client choisit un Menu « Végétarien », la Boisson « Lait » est exclue.

type CommandeRepas {

    string MenuType = ["Standard", "Végétarien", "Vegan"];

    string Boisson = ["Eau", "Jus", "Lait"];

    exclude (MenuType == "Végétarien", Boisson == "Lait");

}

Explication : Un menu végétarien n’inclut pas de lait, donc cette règle assure que le lait n’est pas proposé par erreur.

7. Enchaînement de règles (rule chaining)

L’enchaînement de règles permet de créer des suites logiques, quand une règle s’active, elle en déclenche une autre. Cela fonctionne avec tous les types de règles (exclusion, obligation, préférence, simple, conditionnelle).

But pour l’entreprise : rendre automatiques des suites de configurations compliquées.

Exemple d’enchaînement conditionnel :

1. Si un Billet de Train est de Première Classe, le Repas doit être “gourmet”.
2. Si le Repas est “gourmet”, la Boisson doit être “vin”.

type BilletDeTrain {

    string Classe = ["Économique", "Première Classe"];

    string Repas = ["Standard", "Gourmet"];

    string Boisson = ["Eau", "Jus", "Vin"];

    constraint (Classe == "Première Classe" -> Repas == "Gourmet", "La Première Classe inclut un repas Gourmet.");

    constraint (Repas == "Gourmet" -> Boisson == "Vin", "Le repas Gourmet est accompagné de vin.");

}

Explication : Choisir la première classe active automatiquement le repas gourmet, qui à son tour active le choix du vin.

Exemple d’enchaînement d’obligation :

1. Si un Appareil Photo est sélectionné, un Objectif est obligatoire.
2. Si un Objectif est sélectionné, une Carte Mémoire est obligatoire.

type CommandePhoto {

    relation AppareilPhoto AppareilPhoto;

    relation Objectif Objectif;

    relation CarteMémoire CarteMémoire;

    require (AppareilPhoto[AppareilPhoto], Objectif[Objectif]);

    require (Objectif[Objectif], CarteMémoire[CarteMémoire]);

}

Explication : Ajouter un appareil photo entraîne l’ajout automatique de l’objectif, puis de la carte mémoire.

8. Règles par tableau (table constraints)

Ces règles permettent de créer des tableaux de combinaisons possibles pour les caractéristiques des produits. Cela montre comment les caractéristiques dépendent les unes des autres.

But pour l’entreprise : gérer des dépendances compliquées entre plusieurs caractéristiques en utilisant un tableau.

Exemple : définir les combinaisons valides de Taille de T-shirt et de Type de Coupe.

type TShirt {

    string Taille = ["S", "M", "L", "XL"];

    string TypeDeCoupe = ["Slim Fit", "Regular Fit", "Oversize"];

    constraint(table(Taille, TypeDeCoupe,

        {"S", "Slim Fit"},

        {"M", "Slim Fit"},

        {"M", "Regular Fit"},

        {"L", "Regular Fit"},

        {"L", "Oversize"},

        {"XL", "Oversize"}

    ));

}

Explication : Cette règle n’autorise que les combinaisons taille/coupe spécifiées, évitant les choix non disponibles.

9. Règles au niveau de la commande globale (transaction scope rules)

Ces règles permettent de définir des conditions et des actions qui s’appliquent à l’ensemble de la commande (le devis), affectant plusieurs ensembles ou produits.

But pour l’entreprise : appliquer des règles générales qui dépassent les limites de chaque ensemble de produits.

Exemple : ajouter automatiquement un Service d’Installation si un Système de Chauffage est ajouté au devis.

@(virtual = true)

type Devis {

    @(sourceContextNode="SalesTransaction.SalesTransactionItem")

    relation systemeChauffage SystemeChauffage [0..10];

    @(sourceContextNode="SalesTransaction.SalesTransactionItem")

    relation serviceInstallation ServiceInstallation [0..10];

    require (systemeChauffage[SystemeChauffage], serviceInstallation[ServiceInstallation], "Le système de chauffage nécessite une installation.");

}

Explication : Dès qu’un système de chauffage est ajouté à la commande, un service d’installation est automatiquement inclus.

10. Règles pour cacher des options (hide attribute values rule)

Cette règle permet de cacher certaines options d’une caractéristique en fonction d’une condition.

But pour l’entreprise : rendre l’interface plus simple et éviter les choix inutiles.

Exemple : quand Type de Matériau est « plastique » pour un Jouet, cacher toutes les options de Couleur sauf « bleu » et « jaune ».

type Jouet {

    string TypeDeMatériau = ["Bois", "Plastique", "Métal"];

    string Couleur = ["Rouge", "Bleu", "Vert", "Jaune"];

    rule (TypeDeMatériau == "Plastique", "Couleur", "value", "hide", "attribute", ["Rouge", "Vert"]);

}

Explication : Si un jouet en plastique est choisi, seules les couleurs « bleu » et « jaune » restent visibles pour le vendeur.

11. Règles pour désactiver des éléments (disable components rule)

Cette règle permet d’empêcher les modifications sur des éléments enfants spécifiques.

But pour l’entreprise : éviter les changements non voulus sur certains éléments une fois qu’une condition est remplie.

Exemple : si un Abonnement « Premium » est sélectionné, toute modification sur l’Option « Support Téléphonique » est désactivée.

type AbonnementService {

    relation AbonnementPremium AbonnementPremium;

    relation SupportTéléphonique SupportTéléphonique;

    rule (AbonnementPremium[AbonnementPremium], "disable", "relation", "SupportTéléphonique", "type", "SupportTéléphonique");

}

Explication : Une fois l’abonnement premium choisi, l’option de support téléphonique associée ne peut plus être modifiée (désélectionnée ou sa quantité changée).

12. Règles par catégorie de produit (product class rules)

On peut écrire des règles pour une catégorie de produits. Tous les produits de cette catégorie suivront automatiquement ces règles.

But pour l’entreprise : appliquer les mêmes règles à un groupe de produits similaires.

Exemple : restreindre tous les produits de la catégorie Boissons à n’avoir qu’un Type de Contenant « bouteille ».

type Boisson {

    @(defaultValue = "Canette")

    string TypeDeContenant = ["Bouteille", "Canette", "Verre"];

    constraint (TypeDeContenant == "Bouteille", "Seules les boissons en bouteille sont autorisées dans cette catégorie.");

}

Explication : Peu importe la boisson spécifique (eau, jus, soda), si elle appartient à la catégorie Boissons, elle sera contrainte à être en « bouteille ».

13. Règles pour options spécifiques (dynamic options rules)

Ces règles permettent de créer des conditions sur des options qui peuvent être ajoutées dynamiquement à un ensemble, même si elles font partie d’une catégorie.

But pour l’entreprise : ajouter automatiquement des options spécifiques basées sur les choix de caractéristiques.

Exemple : si un Ordinateur « Gaming » a un Disque Dur de « 2 to SSD », un Jeu Vidéo « Populaire » est automatiquement ajouté à partir de la catégorie Logiciels.

type OrdinateurGaming {

    relation DisqueDur DisqueDur;

    relation Logiciels Logiciels; // Supposons que JeuVidéoPopulaire est un type sous la classe Logiciels

    require (DisqueDur[DisqueDur].Capacité == "2 To SSD", Logiciels[JeuVidéoPopulaire]);

}

Explication : Cette règle garantit que si un client choisit un ordinateur de gaming avec un certain type de disque dur, le jeu vidéo correspondant est automatiquement inclus.

14. Règles de quantité (quantity rules)

Ces règles permettent de vérifier et de changer la quantité de n’importe quel produit via des règles.

But pour l’entreprise : appliquer des logiques basées sur le nombre d’articles configurés.

Exemple : si le nombre de Tickets de Concert est supérieur à 4, le Type de Siège doit être « VIP ».

type CommandeConcert {

    relation Ticket Ticket;

    relation Siège Siège;

    message(Ticket[Ticket]>4 && Siège[Siège].TypeDeSiège != "VIP",

            "Pour plus de 4 tickets, les sièges doivent être VIP.", "Error");

}

Explication : Cette règle empêche une commande de nombreux tickets si les sièges ne sont pas VIP.

15. Règles de message personnalisé (message expression rules)

Ces règles permettent de modifier le contenu d’un message en direct, selon les choix de l’utilisateur, et avec différents niveaux d’importance.

But pour l’entreprise : offrir des messages plus précis et utiles.

Exemple : afficher un message d’information sur le Nombre de Places configuré pour un Voyage en Bus, et un avertissement si le nombre de places est de 50 (car le bus est complet).

type VoyageEnBus {

    int NombreDePlaces;

    string infoMessage = "Le nombre de places configuré est de " + NombreDePlaces + ".";

    string warningMessage = "Le nombre de places choisi (" + NombreDePlaces + ") correspond à un bus complet. Veuillez choisir un autre voyage.";

    boolean isBusComplet = NombreDePlaces == 50;




    message(!isBusComplet, "{}", infoMessage, "Info");

    message(isBusComplet, "{}", warningMessage, "Warning");

}

Explication : Le message s’adapte au choix de l’utilisateur, donnant des informations précises ou des avertissements basés sur la disponibilité.

16. Règles basées sur le contexte (context tag rules)

Ces règles permettent de créer des conditions basées sur des informations du devis ou de la ligne de devis. Ces informations sont liées aux champs standards et personnalisés.

But pour l’entreprise : appliquer des règles basées sur des données spécifiques de la commande.

Exemple sur une information de ligne de commande : empêcher l’utilisateur de donner plus de 20% de remise sur un Service de Nettoyage.

type ServiceDeNettoyage {

    @(tagName = "ItemDiscountPercentage")

    decimal discount;

    message(discount > 20, "Ne pas accorder plus de 20% de remise pour le Service de Nettoyage.", "Warning");

}

Explication : Si le vendeur entre une remise supérieure à 20% sur la ligne du service de nettoyage, un avertissement s’affiche.

Exemple sur une information de commande globale : offrir un Bon de Réduction supplémentaire aux clients dont la Ville de Livraison est Paris.

@(contextPath = "SalesTransaction.ShippingCity")

extern string ShippingCity;




type Devis {

    @(sourceContextNode = "SalesTransaction.SalesTransactionItem")

    relation bonReduction BonReduction[0..1];

    require(ShippingCity == "Paris", bonReduction[BonReduction]);

}

Explication : Si la ville de livraison est Paris, un bon de réduction est automatiquement ajouté au devis.

17. Règles entre ensembles (cross bundle rules)

Ces règles permettent d’appliquer des logiques et des actions entre différents ensembles de produits au sein d’une même commande.

But pour l’entreprise : gérer des dépendances complexes entre des ensembles distincts.

Exemple : si la quantité de Cartes de Vœux « Premium » sur un devis dépasse 10, identifier toute Enveloppe « Standard » qui contient une Couleur « Or » et ajouter un Timbre « Spécial » à cet ensemble d’enveloppes.

type Devis {

    // ...

    int cartesVoeuxPremiumCount = cartesVoeuxPremium [CartesVoeuxPremium];

    @(sourceContextNode = "SalesTransaction.SalesTransactionItem")

    relation enveloppeStandard: EnveloppeStandard[0..10];

}




type EnveloppeStandard {

    // ...

    int cartesVoeuxQty = parent(cartesVoeuxPremiumCount);

    require(cartesVoeuxQty > 10 && couleur[Couleur].NomCouleur == "Or", timbreSpecial[TimbreSpecial]);

}

Explication : Cette règle complexe permet de réagir à la quantité d’un type de carte de vœux pour influencer la composition d’un autre ensemble (les enveloppes), même si plusieurs instances de ce dernier existent.

18. Calculs et logique (arithmetic & logical operators)

Le CML permet d’utiliser des calculs et de la logique pour faire des opérations, des comparaisons et des changements de types de données sur les lignes de commande. Cela permet de créer des règles dynamiques basées sur la quantité, le prix et d’autres informations importantes.

But pour l’entreprise : mettre en place des logiques complexes et des calculs dans les règles de configuration.

Exemple de logique complexe : si une Voiture « Sport » a un Moteur « V8 », elle doit avoir des Jantes « Alliage » OU (des Jantes « Acier » ET (un Système de Freinage « Performance » OU un Système de Suspension « Sport »)).

type VoitureSport {

    string Moteur = ["V6", "V8"];

    string Jantes = ["Alliage", "Acier"];

    boolean SystèmeFreinagePerformance;

    boolean SystèmeSuspensionSport;

    constraint(Moteur == "V8" && (Jantes == "Alliage" || (Jantes == "Acier" && (SystèmeFreinagePerformance == true || SystèmeSuspensionSport == true))),

               "Configuration de voiture sport incorrecte.");

}

Explication : Cet exemple montre comment combiner des opérateurs && (ET), || (OU) et des parenthèses pour créer des conditions très précises.

Exemple d’opérateurs de date : en raison d’une promotion spéciale, toutes les Pizzas commandées entre le 1er et le 15 du mois reçoivent une Boisson gratuite.

type CommandePizza {

    relation Pizza Pizza;

    relation Boisson Boisson;

    date debutPromo = "2025-08-01"; // Exemple : 1er août 2025

    date finPromo = "2025-08-15"; // Exemple : 15 août 2025

    date dateCommande = today(); // 'today()' est une fonction CML pour la date actuelle




    require(Pizza[Pizza] > 0 && dateCommande >= debutPromo && dateCommande <= finPromo, Boisson[Boisson]);

}

Explication : Cette règle utilise des comparaisons de dates (>=, <=) pour ajouter une boisson si la commande est passée pendant la période de promotion.

Exemple de combinaison de textes (concaténation) : combiner des messages pour donner des informations détaillées.

type CommandeLivre {

    // ...

    int nombreLivres = livre.nombreTotal; // Supposons que nombreTotal est défini sur le livre

    string messageLimite = "Veuillez limiter le nombre à 5.";

    string messageInfoLivres = "Vous avez " + nombreLivres + " livres dans votre panier.";

    string messageComplet = strconcat(" ", messageInfoLivres, messageLimite);




    message(nombreLivres > 5, "{0", messageComplet, "Warning");

}

Explication : strconcat est utilisé pour assembler plusieurs morceaux de texte en un seul message dynamique.

4/ Bénéfices pour les entreprises

Utiliser le Configurateur Avancé de Salesforce Revenue Cloud apporte de nombreux bénéfices aux entreprises :

• Devis plus exacts : en appliquant des règles strictes, le système évite les erreurs de configuration faites à la main. Les devis sont toujours corrects et respectent les règles de l’entreprise.
• Ventes plus rapides : les vendeurs peuvent préparer des produits compliqués en quelques clics. Ils n’ont pas besoin de chercher dans des manuels ou de demander à des experts. Cela réduit beaucoup le temps pour faire un devis.
• Meilleure expérience client : les clients reçoivent des offres précises et personnalisées plus vite. Cela les rend plus contents et plus confiants.
• Respect des règles et cohérence : les règles de l’entreprise sont appliquées de la même manière pour toutes les commandes. Cela assure le respect des lois et des règles internes.
• Capacité à grandir : le système peut gérer de plus en plus de produits et de règles compliquées sans ralentir.
• Souplesse : le CML, avec sa capacité à gérer les hiérarchies et l’héritage, s’adapte facilement aux changements des offres de produits.

Conclusion

Le Configurateur Avancé de Salesforce Revenue Cloud, avec son puissant langage CML et ses nombreux types de règles, est un outil essentiel pour les entreprises modernes. Il transforme la complexité de la configuration des produits en un processus simple, précis et automatique. En réduisant les erreurs, en accélérant les ventes et en améliorant l’expérience client, il aide les entreprises à augmenter leurs revenus et à rester compétitives dans un marché qui change tout le temps.

FAQ – Configurateur Avancé Salesforce Revenue Cloud

Est-ce réservé aux grandes entreprises ?

Non, les PME peuvent aussi tirer parti du configurateur avancé, surtout si leurs offres sont complexes.

 

Faut-il déjà utiliser CPQ Salesforce ?

Oui, le configurateur avancé enrichit votre module CPQ existant ?

 

Quel ROI attendre avec le Configurateur Avancé Salesforce Revenue Cloud ?

Des cycles de vente raccourcis et une diminution des erreurs de devis, améliorant directement la marge.

 

Quelle est la différence entre le Configurateur Avancé Salesforce et Revenue Cloud Advanced (RCA) ?

Le Configurateur Avancé est un module qui s’appuie directement sur RCA. Revenue Cloud génère tout le cycle de revenus, tandis que le configurateur se concentre sur la création d’offres complexes et sur mesure. Ensemble, ils automatisent la tarification et réduisent les erreurs de configuration.

 

Comment le Configurateur Avancé améliore-t-il les performances de RCA ?

En ajoutant une interface visuelle et des règles métier dynamiques, le configurateur accélère la génération de devis dans Revenue Cloud Advanced, améliore la précision des prix et offre une expérience fluide du premier contact client jusqu’à la facturation.

Liens utiles

• Notre offre Revenue Cloud Advanced : découvrez en détail nos services d’accompagnement pour déployer et optimiser votre solution RCA ici.
• Formation RCA sur l’Academy : accédez à un programme complet pour maîtriser la mise en place et l’utilisation de RCA ici.
• Formation CPQ sur l’Academy : apprenez à configurer et gérer efficacement vos produits avec le CPQ Salesforce pour booster vos ventes ici.
• Article dédié à Revenue Cloud Advanced : explorez un focus approfondi sur les bénéfices de cette technologie ici.