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. C’était le standard du secteur, et pendant un temps cela suffisait. Mais prima vista, les limites étaient visibles depuis longtemps : routage restreint, catégorisation rigide et un modèle d’extension où chaque personnalisation relevait de l’équilibrisme.

V2 n’est pas une mise à jour. V2 est une reconstruction. Même nom, produit entièrement différent. Que vous l’évaluiez pour une nouvelle implémentation ou que vous planifiez une migration depuis V1, voici les différences concrètes.

Nouvelle gestion des cas

V2 redéfinit la gestion des cas en profondeur. 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.

La gestion du cycle de vie des cas fonctionne avec des états configurables et des transitions définies. Vous déterminez quels états autorisent quelles actions, qui peut déclencher les transitions et ce qui se passe automatiquement à chaque étape. Au lieu d’un simple champ de statut : un véritable moteur de workflow.

V2 supporte nativement les relations parent-enfant entre cas. Un problème client complexe génère des sous-cas pour la facturation, la technique, la logistique — le cas parent suit la résolution globale. Dans V1, il fallait des contournements pour cela.

Côté suivi des SLA : les accords de niveau de service sont directement 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é et du niveau du client. Les agents voient des compteurs à rebours, les managers voient des tableaux de bord de conformité SLA. V1 offrait un support SLA rudimentaire ; V2 le rend opérationnel.

Routage omnicanal

V1 routait les cas par attribution manuelle ou via des règles simples. V2 introduit un vrai routage.

Avec le routage basé sur les compétences, vous 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. Fini le « attribuer à l’équipe en espérant que la bonne personne s’en charge ».

Pour la gestion des files d’attente, les cas entrent dans des files avec un ordre de priorité. Les agents travaillent à partir des files ou reçoivent des attributions automatiques basées sur la capacité et la correspondance des compétences.

Côté agnosticisme de 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.

Et puis l’équilibrage de charge. V2 distribue les cas en fonction de la charge de travail des agents. Si un agent a 15 cas ouverts et un autre en a 5, les nouveaux cas vont là où il y a de la capacité. V1 ignorait tout simplement 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 demandes courantes — réinitialisations de mot de passe, questions de facturation, questions produits standards — l’IA est suffisamment fiable 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 même 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 tirées de cas passés similaires. Les agents ne partent pas de zéro — ils commencent 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 particulièrement important dans le contexte du service : les environnements de service ont de facto plus d’intégrations que les ventes. Systèmes de téléphonie, chatbots, bases de connaissances, outils de service terrain, ERP — tout doit 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.

Les extensions personnalisées tournent sur BTP. L’ancien modèle d’extension de V1 (PDI) a disparu. Les extensions fonctionnent sur SAP BTP — Node.js, Java, CAP, Cloud Foundry. Concrètement, pour les scénarios de service : vous pouvez construire une logique d’escalade personnalisée, des connecteurs vers des systèmes externes ou des outils agents spécialisés sans toucher au coeur de Service Cloud.

Et l’intégration événementielle : V2 publie des événements (cas créé, cas mis à jour, SLA violé) vers SAP Event Mesh. Vos extensions réagissent 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 utilisez 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 repensées pour le modèle basé sur les compétences de V2.

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

La formation des agents ne doit pas être sous-estimée. 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 ».

Chaque intégration V1 doit être revue. Les endpoints API et modèles de données ont changé. Prévoyez du temps adéquat pour les intégrations.

Pour une organisation de service de taille moyenne (20-50 agents), prévoyez 4 à 6 mois d’implémentation V2 ciblée. Les environnements complexes avec de lourdes personnalisations prennent plus longtemps. Ce n’est pas du pessimisme, c’est de l’expérience projet.

Ce que Spadoom a appris

Nous avons implémenté Service Cloud V2 aux côtés de Sales Cloud V2 pour plusieurs clients. Trois observations se distinguent.

Commencez par le routage. Le moteur de routage est la plus grande amélioration et le plus complexe à configurer. Faites-le bien dès le début — il influence tout ce qui suit.

L’IA a besoin de données. L’IA de classification a besoin de données de cas réelles pour s’entraîner. Importez les cas historiques si vous en disposez. Et fixez les attentes de manière réaliste : la précision de l’IA s’améliore sensiblement au cours des 2-3 premiers mois.

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

Nota bene : les extensions BTP s’amortissent rapidement. 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 ou un tableau de bord de reporting spécialisé.

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