L’automatisation du support change la proposition de valeur des ESN Salesforce. Elle ne permet pas d’affirmer qu’un agent absorbera une part fixe des tickets, qu’un ROI arrivera en un nombre de jours donné ou qu’un centre de services humain disparaîtra.
Salesforce présente Agentforce Service comme une combinaison d’agents IA, d’expertise humaine et de données de confiance. Pour une ESN, la question commerciale est donc précise : quelle partie du service peut être automatisée avec des critères de qualité et d’escalade vérifiables ?
Partir du catalogue d’intents
Une offre sérieuse ne commence pas par « Agentforce pour le support ». Elle commence par une liste d’intents : demande d’information, guidage, mise à jour autorisée, diagnostic, création de ticket, routage ou escalade.
Pour chaque intent, documentez :
- données nécessaires et fraîcheur attendue ;
- actions autorisées et actions interdites ;
- règles de validation avant écriture ;
- conditions d’escalade vers un humain ;
- preuve de résolution ;
- propriétaire métier et technique.
Cette matrice empêche de confondre réponse plausible et résolution effective.
Data 360 n’est pas un prérequis universel
Un agent qui consulte une base de connaissances et crée un ticket n’a pas le même besoin de données qu’un agent qui doit rapprocher l’identité d’un utilisateur dans plusieurs systèmes.
Data 360 et Identity Resolution peuvent être utiles lorsque le cas d’usage exige un profil cross-système gouverné. D’autres agents peuvent fonctionner avec des objets Salesforce, des APIs ou une base de connaissances correctement contrôlée. La décision dépend du contexte nécessaire, des droits, de la latence et du coût contractuel.
L’ESN doit donc présenter une architecture par intent, pas ajouter Data 360 comme ligne obligatoire à toute proposition.
Mesurer contre le baseline du client
Un taux de déflexion publié sans définition ne vaut rien. Selon les équipes, « défléchi » peut signifier qu’aucun humain n’a ouvert le ticket, que le ticket a été fermé automatiquement ou que l’utilisateur n’est simplement pas revenu.
Définissez avant le pilote :
- le volume et la typologie des demandes sur une période de référence ;
- la définition d’une résolution correcte ;
- le taux d’escalade et ses causes ;
- les réouvertures et contacts répétés ;
- le temps de traitement humain résiduel ;
- la satisfaction et les incidents de conformité ;
- le coût total, licences et opérations comprises.
Le pilote produit ensuite une comparaison avec ce baseline. Il ne vise pas un benchmark universel.
Concevoir le handoff humain
L’escalade ne doit pas être un bouton de secours. Elle fait partie du parcours. L’agent transmet à l’humain l’intent détecté, les données consultées, les actions tentées, les contrôles passés et la raison de l’escalade.
Sans ce contexte, l’utilisateur recommence son explication et l’automatisation déplace le coût au lieu de le réduire.
Le contrat de support doit également préciser qui traite les erreurs silencieuses, les réponses non fondées, les actions refusées, les régressions après changement de modèle ou de configuration et les incidents nécessitant une suspension de l’agent.
Repositionner la valeur de l’ESN
La valeur ne se résume pas au volume de tickets humains. Elle peut se déplacer vers :
- cadrage et sélection des intents ;
- architecture des données et des droits ;
- tests et critères de mise en production ;
- observabilité et revue des conversations ;
- gestion des changements ;
- amélioration continue basée sur les échecs observés ;
- gouvernance fournisseurs et consommation.
Le modèle commercial doit suivre le travail réel. Une phase de cadrage peut être forfaitaire ; l’exploitation peut utiliser un retainer ou une capacité définie. Les durées et jours mensuels dépendent du périmètre et ne doivent pas être présentés comme une norme de marché sans source.
Souveraineté, conformité et contrat
Avant tout déploiement, l’ESN doit vérifier les flux de données, les sous-traitants, la résidence, la rétention, les droits d’accès, la journalisation et les modalités de facturation applicables au SKU du client.
Une promesse « RGPD-ready » ne suffit pas. Le DPO et le responsable sécurité doivent relier le cas d’usage aux obligations et contrôles réels. Cet article ne constitue pas un avis juridique.
Points clés
- Cadrer l’offre par intents, données, actions, exclusions et handoff humain.
- Utiliser Data 360 lorsque le cas d’usage justifie un contexte cross-système ; ne pas en faire une dépendance universelle.
- Mesurer le pilote contre le baseline du client avec des définitions stables.
- Inclure observabilité, suspension, régression et amélioration continue dans le modèle opérationnel.
- Vérifier licence, consommation, région, résidence et rétention sur le contrat réel avant de promettre coût ou délai.
