Le contrôle qualité sur Salesforce Service Cloud consiste à évaluer les réponses rédigées par un conseiller, le canal utilisé et l’état dans lequel la requête a été laissée. Décidez d’abord ce qui compte comme la conversation, car une requête regroupe de nombreux enregistrements liés.
En bref
- Le propriétaire de la requête n’a souvent pas écrit la réponse.
- Reliez chaque critère à un champ qui existe dans votre org.
- Définissez la population de l’échantillon avec un rapport.
- Décidez avant le déploiement comment évaluer les requêtes multicanales.
Ce que le contrôle qualité sur Salesforce Service Cloud veut vraiment dire
La plupart des conseils en QA partent d’un ticket : un client, un fil, un assigné, lu de haut en bas. Service Cloud ne fonctionne pas ainsi, et cette seule différence de structure explique pourquoi les conseils QA génériques s’effondrent souvent dès la première semaine.
Une requête (le « case » de Salesforce) est un enregistrement. Elle porte des champs comme le statut, l’origine, le motif, la priorité et le propriétaire, mais les valeurs de ces listes de sélection sont configurées par votre propre administrateur, pas fixées par la plateforme. Autour de cet enregistrement se trouve ce que le client et le conseiller ont réellement fait : e-mails, transcriptions de chat ou de messagerie, publications internes, tâches et, si l’org a activé la voix, enregistrements d’appels. Le fil de la requête affiche une chronologie de cette activité, mais une chronologie n’est pas une conversation. Elle mélange les réponses des conseillers avec des entrées système, des modifications de champs et des publications de personnes qui n’ont jamais parlé au client.
La première question du contrôle qualité dans Service Cloud n’est donc pas « que devons-nous évaluer ». C’est qu’appelons-nous la conversation. Il existe trois réponses défendables, et vous devez en choisir une délibérément :
- L’échange avec le client uniquement. Chaque message que le client pouvait voir, dans l’ordre, sans les publications internes ni l’historique des champs. C’est l’équivalent le plus proche d’un fil de ticket et le plus simple à expliquer à un conseiller.
- L’échange plus l’état de l’enregistrement. Les mêmes messages, jugés avec la façon dont la requête a été catégorisée et clôturée. Le bon choix pour les équipes dont la qualité des données alimente le reporting.
- Toute la requête, travail interne compris. Messages, notes internes, transferts et tâches. La vue la plus complète, et la plus difficile à évaluer de façon cohérente, car les évaluateurs ne s’accordent pas sur la quantité de travail interne suffisante.
Écrivez la réponse avant d’écrire les critères. Sinon, chaque évaluateur choisit discrètement la sienne, et vous obtenez le désaccord que tout responsable QA connaît : deux personnes notent la même requête 60 et 85, et aucune ne sait dire pourquoi. La mécanique de la grille d’évaluation qui s’appuie sur ce choix est la même que dans tout programme de QA du support. Si vous n’en avez pas encore construit, commencez par comment construire une grille d’évaluation QA et revenez ensuite.
Ce qu’il y a à évaluer sur une requête, et ce qu’il n’y a pas
Avant d’écrire des critères, prenez une requête récemment clôturée et inventoriez ce qui s’y trouve vraiment. Faites-le dans votre propre org plutôt qu’à partir d’un modèle, car ce qui est présent varie énormément selon la configuration de l’org.
Généralement disponible
- Les messages rédigés par les conseillers. Les réponses par e-mail, les échanges de chat ou de messagerie et les éventuelles publications publiques. C’est la preuve centrale pour tout ce qui touche à la communication.
- Les horodatages. Quand le client a écrit, quand le conseiller a répondu, quand le propriétaire a changé, quand la requête a été clôturée. Assez pour raisonner sur la réactivité, avec les réserves ci-dessous.
- Les valeurs des champs à la clôture. Statut, motif, champs produit ou catégorie, et tous les champs personnalisés que votre org exige. C’est ce qui rend une requête exploitable dans les rapports, et cela fait donc légitimement partie de la qualité.
- Les notes et publications internes. La qualité du transfert, l’investigation, le raisonnement derrière une escalade.
- L’historique des propriétaires. Qui a eu la requête, et quand elle a changé de main.
Souvent absent, à vérifier avant de promettre un critère
- La voix. La présence d’un appel joint, et l’existence d’une transcription plutôt que d’un simple enregistrement ou d’une note, dépendent de la manière dont la voix est activée dans votre org. Vérifiez-le avant d’écrire un critère qui dépend du contenu de l’appel.
- Ce que le conseiller pouvait voir. La sécurité au niveau des champs et les règles de partage font que la vue de l’évaluateur sur une requête n’est pas forcément celle du conseiller. Si un critère suppose que le conseiller disposait d’une information, vérifiez qu’il en disposait.
- L’état de la base de connaissances à ce moment-là. Si un article a changé après la clôture de la requête, le conseiller avait peut-être raison par rapport à la version qu’il avait.
- Tout ce qui s’est passé hors de l’enregistrement. Un rappel téléphonique consigné en une ligne, une conversation dans un outil de chat, un transfert de vive voix à une autre équipe. C’est du vrai travail, et il est invisible pour la QA.
La règle qui en découle est courte. Si un critère ne peut pas être prouvé par un élément de la requête, ce n’est pas un critère QA, c’est une opinion. Trouvez le champ ou le message qui le prouve, ou sortez-le de la grille pour le passer dans le coaching. Une checklist QA générique pour le service client est un bon inventaire de départ, mais chacune de ses lignes doit passer ce test face à la présentation de page de vos propres requêtes.
Comment relier les données d’une requête aux critères de la grille
C’est cet exercice de correspondance qui fait ou défait le programme. Pour chaque critère, nommez la preuve, nommez la vérification et nommez le mode d’échec attendu. Les équipes sautent souvent la dernière colonne, et c’est justement celle qui prédit chaque débat que vous allez avoir.
| Type de critère | Preuve sur la requête | Comment l’évaluateur le vérifie | Où ça se passe mal |
|---|---|---|---|
| Exactitude de la résolution | Le dernier message du conseiller, lu face aux champs avec lesquels la requête a été clôturée | La réponse donnée correspond-elle au résultat enregistré, et était-elle juste à ce moment-là | Le statut est défini par une automatisation ou une macro, si bien que l’enregistrement indique « résolu » sans aucune preuve que c’était le cas |
| Respect des processus | Champs obligatoires, notes internes et tous les enregistrements de droits ou de niveaux de service configurés par l’org | Comparer ce que la requête enregistre avec votre processus documenté pour ce type de requête | L’exigence vit dans un wiki plutôt que dans un champ, et deux évaluateurs en appliquent deux versions différentes |
| Qualité de la communication | Uniquement les messages rédigés par les conseillers, jamais tout le fil | Évaluer le texte que le client pouvait réellement lire | Les évaluateurs absorbent le ton des publications internes et des entrées système et l’attribuent au conseiller |
| Réactivité et effort | Horodatages des messages et des changements de propriétaire | Mesurer l’écart entre un message client et la réponse suivante du conseiller | Le temps en file d’attente, les heures ouvrées et l’attente d’une autre équipe sont imputés à celui qui se trouve détenir la requête |
| Catégorisation et qualité des données | Origine, motif, type d’enregistrement et vos propres champs de reporting | Les valeurs décrivent-elles ce qui s’est réellement passé dans la conversation | Les conseillers choisissent la valeur qui passe le plus vite la règle de validation, et personne ne l’évaluait jusqu’ici |
| Routage | Historique des propriétaires, appartenance aux files d’attente, type d’enregistrement | La requête a-t-elle atteint la bonne équipe du premier coup, et sinon, pourquoi | Une erreur d’aiguillage due à une règle de routage est notée comme une faute du conseiller |
En quoi l’évaluation d’une requête diffère de celle d’un ticket Zendesk
Beaucoup de responsables des opérations support ont fait du contrôle qualité sur Zendesk et doivent maintenant le faire sur Service Cloud, ou sur les deux à la fois. La philosophie de la grille se transpose. La mécanique, non, et voici les six différences qui coûtent le plus de temps. Si vous gérez aussi le côté Zendesk, la mécanique propre à cette plateforme est traitée à part dans le contrôle qualité pour Zendesk.
| Dimension | Ticket Zendesk | Requête Salesforce Service Cloud |
|---|---|---|
| L’unité d’évaluation | Un ticket est un fil. Demandeur, assigné et commentaires se lisent comme une seule conversation linéaire | Une requête est un enregistrement. La conversation est reconstituée à partir de messages, de transcriptions et d’éléments du fil liés |
| Qui a fait le travail | L’assigné plus les auteurs de commentaires visibles | Le champ propriétaire indique qui détient la requête maintenant. L’auteur doit être lu sur chaque message |
| Canal | En général une propriété du ticket lui-même | Les canaux arrivent sous forme d’enregistrements liés différents, et une requête peut en contenir plusieurs |
| Définir la population de l’échantillon | Vues et filtres de recherche | Un rapport ou une vue de liste construit sur les champs de requête propres à votre org |
| Part de standard | Les champs sont globalement les mêmes d’un compte à l’autre | Types d’enregistrement, champs personnalisés et valeurs de listes de sélection sont configurés par org, donc aucune grille ne se transpose sans modification |
| État de clôture | Un petit ensemble de statuts familiers | Les valeurs de statut, et ce que chacune signifie concrètement, sont définies par votre administrateur |
Comment tirer un échantillon défendable
Le reproche le plus fréquent fait à un programme QA est que l’évaluateur a choisi les pires requêtes. Sur Service Cloud, ce reproche est facile à formuler, car il n’existe pas de file d’évaluation naturelle et il est vraiment tentant de travailler à partir de la vue de liste déjà ouverte.
Définissez d’abord la population, dans un rapport, et enregistrez ce rapport. Un filtre efficace : date de clôture dans la période évaluée, type d’enregistrement ou file d’attente qui identifie le travail évalué, canal si vous évaluez les canaux séparément, et exclusion des requêtes sans aucun message rédigé par un conseiller. Les doublons, les requêtes clôturées automatiquement et celles qui n’ont jamais atteint un humain sont du bruit, et les laisser dans la population gonfle ou dégonfle discrètement chaque moyenne que vous publiez ensuite.
Échantillonnez ensuite à partir de cette population plutôt qu’à partir de la liste. Deux règles comptent plus que la taille de l’échantillon :
- Tirez au hasard à l’intérieur de strates, pas sur l’ensemble. Stratifiez par conseiller et par type de requête, puis tirez au hasard dans chaque strate. Un tirage purement aléatoire sur tout un mois donne vingt requêtes à vos conseillers les plus occupés et une seule à votre dernier arrivé, ce qui rend les notes individuelles incomparables.
- Figez l’échantillon avant que quiconque lise une requête. Tirez la liste, enregistrez-la et évaluez ce que vous avez tiré. Un échantillon choisi après que l’évaluateur a parcouru la population n’est pas un échantillon.
Soyez honnête sur ce qu’un échantillon manuel vous apporte. Évaluer trente requêtes par conseiller et par mois représente un travail considérable, et cela vous apprend pourtant très peu sur les types de requêtes rares qui font le plus de dégâts. Cette limite tient à l’arithmétique, pas à l’effort, et c’est la même contrainte que pose le manuel d’ingénierie du NIST lorsqu’il demande si une proportion de défauts mesurée sur un échantillon respecte une exigence : l’échantillon doit être assez grand pour que le test soit valide avant que la réponse veuille dire quelque chose. C’est pourquoi une note issue d’un échantillon et un score de qualité interne présenté à la direction doivent afficher leur intervalle de confiance à côté du chiffre, et pourquoi il vaut la peine de savoir à partir d’où l’échantillonnage QA ne peut plus répondre à la question.
Qui a écrit la réponse : l’attribution sur une requête qui a changé de main
Voici le problème auquel aucun modèle ne vous prépare, et celui qui abîme le plus la confiance des conseillers dans un programme QA sur Service Cloud.
Les requêtes bougent. Elles sont routées, escaladées, réattribuées, prises dans une file, confiées à une équipe spécialisée puis rendues. Le champ propriétaire indique qui détient la requête au moment où vous la regardez. Il n’indique pas qui a écrit la réponse qui a agacé le client, ni qui a mené l’investigation qui a résolu le problème. Si votre processus QA évalue une requête et impute le résultat au propriétaire, alors, sur chaque requête transférée, vous avez attribué le travail d’une personne à une autre.
La conséquence pratique est prévisible et précise. Les conseillers qui gèrent les escalades héritent de requêtes qui tournent déjà mal, et ce sont eux qui récoltent les notes qui en découlent. Ce sont en général vos meilleurs éléments. En un trimestre, ils apprennent que prendre une requête difficile leur coûte, et le comportement que vous vouliez le plus encourager devient celui que votre tableau de notes sanctionne.
Quatre règles pour corriger cela
- Évaluez le message, pas l’enregistrement. Chaque point retiré doit être rattaché à un message précis rédigé par un conseiller, avec un horodatage et un auteur, et non à la requête dans son ensemble.
- Attribuez par auteur. Lisez l’auteur sur chaque message plutôt que dans le champ propriétaire. Si votre reporting ne sait pas le faire, c’est la première chose à corriger, avant d’ajuster la moindre pondération.
- Traitez explicitement les requêtes à plusieurs conseillers. Évaluez séparément la contribution de chaque conseiller, ou sortez la requête de l’évaluation individuelle et utilisez-la pour la revue des processus. Les deux sont défendables. Noter en silence le dernier propriétaire ne l’est pas.
- Gardez l’historique des propriétaires à côté de la note. Quand une note est contestée, la première question est toujours qui a fait quoi. Si la réponse demande vingt minutes de reconstitution, le débat est déjà perdu.
Les requêtes transférées sont aussi votre meilleure source pour travailler sur les processus plutôt que sur le coaching individuel. Une requête qui a changé quatre fois de main avant d’être résolue vous dit quelque chose sur le routage, les droits ou les frontières entre équipes, et cela relève de l’analyse des causes racines plutôt que de la grille de quelqu’un.
Évaluer chaque requête plutôt qu’un échantillon
Une fois la méthode manuelle stabilisée, la question évidente est de savoir si vous pouvez arrêter d’échantillonner. C’est possible, et l’argument est plus fort sur Service Cloud que sur un modèle de ticket plus simple, car les types de requêtes qui comptent le plus sont souvent les plus rares, ceux qu’un échantillon n’atteint jamais. Il y a une vraie différence entre une couverture à 100 % qui révèle des tendances qu’un échantillon de 3 % ne pourrait jamais montrer, et une revue mensuelle de trente requêtes par conseiller.
La couverture en elle-même n’est pourtant pas le point intéressant, et ce n’est plus un élément différenciant. Tous les éditeurs de cette catégorie évaluent désormais tout. La question qui décide si une note automatisée survit au contact de votre équipe est de savoir si vous pouvez montrer que l’évaluation était juste. Sur Service Cloud, cela veut dire quatre choses :
- Une traçabilité jusque dans la requête. Un point retiré doit nommer le critère et pointer vers le message exact de la requête qui l’a déclenché. « Communication : moins dix » sur une requête de quarante éléments de fil est inexploitable.
- Les mêmes preuves que celles utilisées par l’évaluation. Un évaluateur qui vérifie une note doit voir l’ensemble des messages à partir duquel la note a été calculée, pas un résumé.
- Une voie de contestation. Un conseiller doit pouvoir contester une note et obtenir que quelqu’un examine le raisonnement. Sinon, la note est un verdict.
- Un accord mesuré avant qu’elle compte. Faites tourner la note automatisée en parallèle de vos propres évaluateurs sur les mêmes requêtes pendant quelques semaines et validez l’évaluation avant que le chiffre ne soit rattaché à quoi que ce soit qui a des conséquences.
L’Auto QA de Kaizo applique vos propres critères de grille aux requêtes et garde le raisonnement attaché à la conversation, si bien qu’un point retiré contesté peut être retracé jusqu’à l’échange qui l’a causé, au lieu d’être débattu de mémoire. Il fonctionne sur Service Cloud via l’intégration Salesforce, décrite plus en détail dans Kaizo sur Salesforce, à côté de la même intégration pour Zendesk, ce qui compte si vous menez le contrôle qualité sur les deux pendant une migration. Réserver une démo.
Un déploiement qui survit à la première contestation
Les programmes QA sur Service Cloud échouent au même moment : la première fois qu’un conseiller conteste sérieusement une note et que le programme ne sait pas répondre. Ordonnez le déploiement pour que la réponse existe avant la contestation.
| Étape | Ce que vous faites | Terminé quand |
|---|---|---|
| 1. Définir l’unité | Choisir l’une des trois définitions de la conversation et l’écrire. Inventorier ce qui est réellement présent sur une requête clôturée dans votre org | Un évaluateur peut dire, sans hésiter, quels enregistrements sont concernés |
| 2. Relier les critères aux champs | Pour chaque critère, nommer la preuve, la vérification et le mode d’échec attendu. Retirer tout ce qui ne peut pas être prouvé | Chaque critère pointe vers un champ ou un type de message qui existe |
| 3. Construire le rapport de population | Un rapport enregistré qui définit l’ensemble évaluable, avec exclusion des requêtes clôturées automatiquement et sans conseiller | Deux personnes qui lancent le rapport obtiennent le même nombre de requêtes |
| 4. Évaluer en parallèle et calibrer | Trois évaluateurs notent indépendamment les mêmes quinze requêtes, dont au moins trois qui ont changé de propriétaire. Comparer et débattre | Vous connaissez le taux de désaccord de vos évaluateurs, et il baisse |
| 5. Publier avec une voie de recours | Annoncer ensemble la grille, la méthode d’échantillonnage et le processus de recours. Un recours sans voie est un grief | Les conseillers peuvent nommer le processus sans le chercher |
| 6. Présenter les résultats, puis revoir la correspondance | Présenter les notes à côté des résultats opérationnels comme les réouvertures et les escalades. Revoir la correspondance chaque trimestre | L’évolution des notes explique quelque chose qu’un manager soupçonnait déjà |
Présenter la note d’une requête pour que quelqu’un agisse
Une note QA qui ne vit que dans un outil QA est lue par l’équipe QA. Pour valoir l’effort, la note doit figurer à côté des chiffres opérationnels que la direction du support regarde déjà, et être découpée d’une façon qui désigne une action.
Trois découpages font l’essentiel du travail sur les données de Service Cloud :
- Par type de requête ou type d’enregistrement, pas seulement par conseiller. La qualité varie bien plus selon la nature du travail que selon la personne qui le fait. Une moyenne basse sur un type d’enregistrement est un problème de processus, de connaissances ou de routage, et il se corrige de façon centralisée.
- Par critère, sur toute l’équipe. Un critère massivement non respecté n’est presque jamais un problème de coaching. C’est une règle peu claire, un article de connaissance manquant ou un critère mal rédigé.
- La note face au taux de réouverture et d’escalade. C’est le contrôle de la grille elle-même. Si les requêtes bien notées sont rouvertes au même rythme que les requêtes mal notées, la grille mesure autre chose que la qualité et doit être repondérée.
C’est ce troisième découpage qu’il faut protéger. C’est lui qui empêche un programme QA de dériver vers un rituel de conformité que tout le monde exécute et que personne n’utilise. Rapprocher les notes qualité de la vue opérationnelle est exactement le rôle d’une vue d’analyse du support, et c’est aussi le moyen le plus rapide de prouver à une direction sceptique que le programme QA mesure quelque chose de réel.
Questions fréquentes
Salesforce Service Cloud inclut-il une évaluation QA en standard ?
Service Cloud vous donne la matière première : l’enregistrement de la requête, les messages et transcriptions qui lui sont liés, l’historique des champs et une couche de reporting sur l’ensemble. Une grille pondérée, une file d’évaluation, le calibrage entre évaluateurs et une trace de recours auditable ne font pas partie de l’objet requête standard. Les équipes construisent soit une version légère avec des champs personnalisés et des rapports, qui fonctionne jusqu’à ce que le désaccord entre évaluateurs devienne le goulot d’étranglement, soit ajoutent un outil QA qui lit les requêtes. Vérifiez ce que votre propre org a déjà configuré avant de supposer quoi que ce soit, car la personnalisation varie énormément.
Que faut-il évaluer sur une requête Salesforce ?
Uniquement ce que la requête prouve. En pratique, ce sont les messages rédigés par les conseillers, les horodatages de ces messages et des changements de propriétaire, les valeurs des champs à la clôture, et les notes internes si votre définition de la conversation les inclut. Tout ce que vous ne pouvez pas montrer dans l’enregistrement, comme ce que le conseiller savait à ce moment-là ou un rappel consigné en une ligne, relève du coaching plutôt que d’une note.
En quoi le contrôle qualité sur Service Cloud diffère-t-il de celui sur Zendesk ?
La philosophie de la grille est la même, la mécanique non. Un ticket Zendesk est un fil linéaire avec un assigné clair, donc l’unité d’évaluation est évidente. Une requête Salesforce est un enregistrement avec des messages, des transcriptions et des éléments de fil liés, donc vous devez définir l’unité vous-même. L’auteur doit aussi être lu sur chaque message plutôt que dans le champ propriétaire, et comme les types d’enregistrement et les champs personnalisés sont configurés par org, aucune grille ne se transpose sans modification entre deux orgs Salesforce.
Comment échantillonner les requêtes Salesforce pour l’évaluation QA ?
Construisez un rapport enregistré qui définit la population, avec un filtre sur la date de clôture, le type d’enregistrement ou la file d’attente, le canal si c’est pertinent, et l’exclusion des requêtes sans message rédigé par un conseiller. Tirez ensuite au hasard à l’intérieur de strates, par conseiller et par type de requête, plutôt qu’au hasard sur tout le mois, afin que chaque conseiller fournisse un nombre comparable de requêtes. Figez l’échantillon avant que quiconque ouvre une requête. Évaluer une liste que vous avez déjà parcourue, ce n’est pas échantillonner.
Qui reçoit la note QA quand une requête change de propriétaire ?
Pas automatiquement le propriétaire actuel, qui est le réglage par défaut dans lequel tombent la plupart des programmes et celui qui fait le plus de dégâts. Attribuez chaque message évalué à la personne qui l’a écrit. Sur une requête traitée par plusieurs personnes, évaluez séparément la contribution de chaque conseiller, ou sortez la requête de l’évaluation individuelle et utilisez-la pour la revue des processus. Noter le dernier propriétaire pour un travail dont il a hérité apprend à vos meilleurs conseillers à éviter les escalades.
Peut-on évaluer e-mail, chat et voix sur la même requête ?
Oui, mais décidez de l’approche avant le déploiement plutôt que pendant la première contestation. Une note unique mélangée sur une requête qui contient un fil d’e-mails et une transcription de chat est difficile à exploiter en coaching, car les standards des deux canaux sont réellement différents. Évaluer chaque segment de canal séparément et les présenter séparément est généralement plus clair. Si la voix est concernée, vérifiez d’abord si votre org a réellement des transcriptions jointes plutôt que de simples enregistrements, car un critère qui dépend du contenu d’un appel est inapplicable sans elles.
