Nous utilisons SAP Sales Cloud et Service Cloud chez Spadoom. Voici ce que nous avons construit.

Nous disons souvent aux clients de ne pas construire du théâtre CRM.

Pas de première phase énorme. Pas d’ateliers sans fin. Pas de champs custom parce qu’ils existaient dans un ancien système. Commencer par le travail. Construire le processus. Passer en production. Améliorer ensuite.

Quand nous avons décidé d’utiliser SAP Sales Cloud V2 et SAP Service Cloud V2 pour Spadoom, nous avons dû appliquer la même discipline à nous-mêmes.

Nous avons pris les licences du stack début 2026. Environ un mois plus tard, nous étions en production.

Le périmètre

Nous avons gardé le premier release volontairement léger.

Pour les ventes, le processus de base était clair :

• Capturer les leads venant de vraies conversations, d’événements et du site.
• Gérer proprement les comptes et contacts.
• Suivre les opportunités sans transformer chaque deal en projet administratif.
• Rendre les suivis visibles.
• Donner assez de contexte pipeline au management sans construire un monstre de reporting.

Pour le service, l’exigence était tout aussi pratique :

• Suivre les demandes de support comme des cases.
• Garder la responsabilité claire.
• Relier les demandes du site au processus de support.
• Rendre visibles le statut et la prochaine action.
• Ne pas perdre le contexte client dans les fils d’e-mails.

C’était suffisant pour le go-live. Tout le reste devait mériter sa place.

Pourquoi Sales Cloud V2

SAP positionne Sales Cloud comme un CRM pour l’exécution commerciale : gestion des leads et opportunités, travail sur les comptes, guided selling, forecast et analytics.

Notre question interne était plus simple : l’équipe voit-elle ce qui compte sans fouiller ?

Nous avons configuré Sales Cloud autour de la manière dont Spadoom vend. Notre vente est rarement transactionnelle. Une première conversation inclut souvent architecture, intégration, adéquation produit et questions inconfortables sur le scope. Le CRM doit soutenir cette réalité.

Nous nous sommes donc concentrés sur une structure de comptes propre, des étapes d’opportunité utiles, des prochaines actions claires et assez de qualification pour éviter de répéter deux fois la même conversation.

Pourquoi Service Cloud V2

SAP positionne Service Cloud autour des opérations de service : case management, knowledge, automatisation et processus de support client.

Pour nous, l’objet clé est le case. Une demande de support a besoin d’une maison. Elle a besoin d’un owner. Elle a besoin d’un statut. Elle a besoin de contexte.

Avant ce projet, trop de travail support pouvait encore se passer dans des endroits faciles à perdre : boîtes mail, chats, notes de côté. Cela fonctionne avec peu de volume. Cela fait mal avec plus de clients, plus de projets et plus de passages de relais.

Service Cloud nous donne un endroit unique pour gérer ce travail.

La connexion au site

Le site compte parce qu’il est souvent le premier endroit où apparaît une demande de support ou un signal commercial.

Nous avons connecté les soumissions du site au processus interne, afin que les demandes entrent dans SAP Service Cloud au lieu de rester dans une boîte mail. Le point n’est pas la démonstration technique. Le point est l’hygiène opérationnelle :

• La demande est capturée.
• La bonne équipe la voit.
• Le statut peut être suivi.
• L’historique reste avec le client.

C’est exactement le type d’intégration que nous recommandons aux clients. Nous l’avons donc construite pour nous-mêmes.

Ce que nous avons personnalisé

Nous n’avons pas implémenté un tenant SAP de démonstration générique.

Nous avons adapté le système à la façon dont Spadoom travaille :

• Des étapes d’opportunité pour des deals SAP CX consultatifs.
• Des catégories de case qui reflètent le vrai support.
• Des champs légers pour une saisie rapide, pas pour une complétude décorative.
• Des vues pour les personnes qui font le travail.
• Un intake du site connecté aux demandes de support.

C’est là que beaucoup de projets CRM se trompent. Ils restent trop génériques et personne n’utilise le système. Ou ils customisent tout et créent un problème de maintenance.

Le chemin utile se trouve au milieu : adapter là où cela améliore le travail quotidien, rester standard là où cela suffit.

Ce que nous avons réappris

Ce projet a confirmé ce que nous voyons dans les projets clients.

Premièrement : la vitesse vient des décisions. Le produit n’était pas le blocage. La discipline de scope l’était.

Deuxièmement : la configuration standard va plus loin que beaucoup ne l’imaginent. Vous n’avez pas besoin de customiser chaque irritation au premier release.

Troisièmement : Service Cloud devient utile quand les cases deviennent la maison par défaut du support. Si le support reste dans les boîtes mail, le système reste décoratif.

Quatrièmement : utiliser le système nous-mêmes change nos conseils. Nous ressentons les petits détails de workflow chaque jour. Cela rend nos recommandations plus nettes. Il en va de même pour nos propres outils : dans Engage Social, un agent surveille notre blog et rédige les brouillons des publications sur les réseaux sociaux, qu’une personne relit ensuite.

La forme technique

Le projet est resté propre :

• SAP Sales Cloud V2 pour les leads, comptes, contacts et opportunités.
• SAP Service Cloud V2 pour le support basé sur des cases.
• Intake du site connecté au processus de support.
• Configuration standard d’abord.
• Personnalisation là où elle améliore le travail quotidien.
• Extensions futures séparées du scope du premier go-live.

Pas de cérémonie. Pas de théâtre de transformation. Juste un système qui fonctionne.

Pourquoi c’est rare

Beaucoup de partenaires SAP vendent SAP CX. Moins nombreux sont ceux qui gèrent leurs ventes et leur service internes sur les mêmes produits.

Cela compte. Quand nous parlons d’adoption, de champs, de files de service, de qualité de lead, de handovers ou d’intake depuis le site, nous ne parlons pas seulement depuis des projets clients. Nous parlons aussi depuis notre propre système quotidien.

Il est plus difficile de faire semblant quand on utilise le produit soi-même.

Cela reflète aussi notre manière de travailler aujourd’hui : nous livrons le noyau ERP comme la pile CX. Pourquoi une seule équipe pour S/4HANA Public Cloud et pour Sales et Service Cloud compte, notre guide pour choisir un partenaire SAP pour le Cloud ERP et le CRM en Suisse l’explique. Deux leçons de notre travail avec SSCV2 ont leur propre article : SSCV2 en quatre langues et le screen pop natif dans l’Agent Desktop.

Sources

• Documentation SAP Sales Cloud Version 2
• Documentation SAP Service Cloud Version 2
• Documentation SAP Business Technology Platform

En bref

Nous sommes passés en production environ un mois après la prise des licences. Rapide, oui. Mais le plus important commence après le go-live.

Le système soutient désormais nos ventes et notre support chaque jour. Il donne une pipeline plus claire, une meilleure file de support et plus de contexte client.

Utiliser ce que l’on recommande.

Nous le faisons. Puis nous améliorons la recette.