SAP Service Cloud V2 : ce qui change et pourquoi c'est important

SAP Service Cloud V1 (le volet service de C4C) faisait le travail. Les tickets arrivaient, les agents les traitaient, les cas étaient clôturés. Mais le système montrait son âge : options de routage limitées, catégorisation basique et un modèle d’extension qui faisait de chaque personnalisation un risque.

Service Cloud V2 est une reconstruction intégrale. Même nom, nouveau produit. Si vous l’évaluez pour une nouvelle implémentation où planifiez une migration depuis V1, voici ce qui à réellement changé.

Nouvelle gestion des cas

La gestion des cas de V2 est fondamentalement différente. Dans V1, un ticket était un enregistrement plat avec des champs de statut. Dans V2, un cas est une entité structurée avec son propre moteur de cycle de vie.

Gestion du cycle de vie des cas. Les cas passent par des états configurables avec des transitions définies. Vous définissez quels états permettent quelles actions, qui peut déclencher les transitions et ce qui se passe automatiquement à chaque étape. Cela remplace le simple champ de statut par un moteur de workflow complet.

Hiérarchie des cas. V2 supporte nativement les relations parent-enfant entre cas. Un problème client complexe peut générer des sous-cas pour différentes équipes — facturation, technique, logistique — tandis que le cas parent suit la résolution globale. V1 nécessitait des contournements pour cela.

Suivi des SLA. Les accords de niveau de service sont intégrés dans l’entité cas. Les SLA de temps de réponse et de temps de résolution se déclenchent automatiquement en fonction de la priorité du cas et du niveau du client. Les agents voient des compteurs à rebours. Les managers voient des tableaux de bord de conformité SLA. V1 avait un support SLA basique ; V2 le rend opérationnel.

Routage omnicanal

V1 routait les cas par attribution manuelle où règles basiques. V2 introduit un vrai routage :

Routage basé sur les compétences. Définissez les compétences des agents (langue, expertise produit, niveau de certification) et routez les cas vers les agents qui peuvent réellement les traiter. Plus besoin d’« attribuer à l’équipe en espérant que la bonne personne s’en charge ».

Gestion des files d’attente. Les cas entrent dans des files d’attente avec un ordre de priorité. Les agents peuvent travailler à partir des files d’attente où recevoir des attributions automatiques basées sur la capacité et la correspondance des compétences.

Agnostique au canal. E-mail, téléphone, chat, réseaux sociaux, formulaires web — V2 les traite tous comme des sources de cas avec un routage unifié. Les agents voient une boîte de réception unique quel que soit le mode de contact du client.

Équilibrage de charge. V2 distribue les cas en fonction de la charge de travail des agents. Si un agent à 15 cas ouverts et un autre en à 5, les nouveaux cas vont à l’agent qui à de la capacité. V1 ne prenait pas du tout en compte la charge de travail.

Classification assistée par l’IA

C’est là que V2 fait le plus grand bond :

Catégorisation automatique. Lorsqu’un cas arrive, l’IA de V2 lit la description et suggère une catégorie, sous-catégorie et priorité. Pour les problèmes courants (réinitialisations de mot de passe, demandes de facturation, questions produits standards), l’IA est suffisamment précise pour classifier sans intervention de l’agent.

Analyse de sentiment. V2 analyse le langage du client et signale le sentiment négatif. Les clients frustrés sont automatiquement priorisés. Les agents voient un indicateur de sentiment avant d’ouvrir le cas.

Solutions suggérées. Basé sur le contenu du cas, V2 suggère des articles de la base de connaissances et des étapes de résolution issues de cas passés similaires. Les agents ne partent pas de zéro — ils partent avec un contexte pertinent.

Apprentissage continu. Le modèle IA s’améliore à mesure que les agents corrigent ses suggestions. Après quelques mois de données réelles, la précision de classification atteint typiquement 80-90 % pour les principales catégories de cas.

Architecture API-first

Comme Sales Cloud V2, Service Cloud V2 est construit API-first. Chaque opération disponible dans l’interface est disponible via des API REST.

Pourquoi c’est important pour le service : les environnements de service ont plus d’intégrations que les ventes. Systèmes de téléphonie, chatbots, bases de connaissances, outils de service terrain, ERP — ils doivent tous communiquer avec le système de gestion des cas. La couverture API complète de V2 rend ces intégrations plus propres et plus fiables.

Extensions personnalisées sur BTP. L’ancien modèle d’extension de V1 (PDI) à disparu. Les extensions fonctionnent sur SAP BTP — Node.js, Java, CAP, Cloud Foundry. Pour les scénarios de service, cela signifie que vous pouvez construire une logique d’escalade personnalisée, des connecteurs vers des systèmes externes où des outils agents spécialisés sans toucher au cœur de Service Cloud.

Intégration événementielle. V2 publie des événements (cas créé, cas mis à jour, SLA violé) vers SAP Event Mesh. Vos extensions réagissent aux événements en temps réel au lieu de scruter les changements. C’est la base d’une architecture propre et maintenable.

Ce que cela signifie pour la migration

Si vous êtes sur V1 et envisagez V2, voici le tableau honnête :

Ce n’est pas une mise à jour. Tout comme Sales Cloud, Service Cloud V2 est une réimplémentation. Votre configuration V1, vos objets personnalisés et vos intégrations ne se transfèrent pas directement.

Les règles de routage doivent être reconçues. Le moteur de routage de V2 est plus puissant mais complètement différent. Vos règles d’attribution V1 doivent être reconçues pour le modèle basé sur les compétences de V2.

Migration de la base de connaissances. Si vous avez une base de connaissances dans V1, elle nécessite une planification de migration. La gestion des connaissances de V2 est intégrée avec les fonctionnalités IA — un bon moment pour restructurer votre contenu.

Formation des agents. L’interface est différente. Les workflows sont différents. La visibilité SLA est différente. Les agents ont besoin d’une formation structurée, pas d’un simple e-mail « voici le nouveau système ».

Refonte des intégrations. Chaque intégration V1 nécessite une revue. Les endpoints API et modèles de données ont changé. Prévoyez du temps de développement d’intégration.

Prévoyez 4-6 mois. Pour une organisation de service de taille moyenne (20-50 agents), une implémentation V2 ciblée prend 4-6 mois. Les environnements complexes avec de lourdes personnalisations prennent plus longtemps.

Ce que Spadoom à appris

Nous avons implémenté Service Cloud V2 aux côtés de Sales Cloud V2 pour plusieurs clients. Observations clés :

Commencez par le routage. Le moteur de routage est la plus grande amélioration et le plus complexe à configurer. Faites-le bien tôt — il affecte tout ce qui suit.

L’IA à besoin de données. L’IA de classification à besoin de données de cas réelles pour s’entraîner. Importez les cas historiques si vous en avez. Fixez les attentes : la précision de l’IA s’améliore au cours des 2-3 premiers mois.

L’omnicanal est un changement de processus, pas seulement un changement technologique. Si vos agents travaillent actuellement dans des files e-mail et téléphone séparées, passer à une boîte de réception unifiée change leur workflow. Planifiez cela.

Les extensions BTP s’amortissent vite. Les projets V2 les plus impactants que nous avons livrés incluent au moins une extension BTP — un outil d’escalade personnalisé, un connecteur de connaissances externe où un tableau de bord de reporting spécialisé.

Vous évaluez SAP Service Cloud V2 pour votre organisation de service ? Nous vous accompagnerons pour déterminer ce qui est réaliste pour votre configuration. Contactez-nous.