La réponse en bref
Service Cloud ne réduit pas les temps de réponse par lui-même. Il applique les configurations que vous lui avez définies. Si la définition d'un Case, son destinataire et le moment où le temps commence à être comptabilisé ne sont pas clairs, le système mesurera précisément un processus indéfini. Les indicateurs sembleront alors meilleurs ou pires que la réalité, sans aucun lien avec le service réellement fourni.
Quatre décisions clés déterminent le résultat : la définition du Case, le modèle d'affectation, les horaires SLA et l'emplacement des connaissances. Le reste de l'implémentation (écrans, canaux, automatisations) en découle.
Décision 1 : Qu'est-ce qu'un « Case » ?
De nombreux centres de contact ouvrent un Case pour chaque interaction sous prétexte d'obtenir des données. Le résultat est l'inverse : des milliers d'enregistrements clos en une minute gonflent les volumes, améliorent artificiellement le temps moyen de résolution et masquent les requêtes réellement bloquées.
Une définition fonctionnelle distingue trois types :
| Type d'interaction | Un Case est-il ouvert ? | Raison |
|---|---|---|
| Question répondue en conversation | Non, enregistré comme Interaction | Pas de suivi, pas d'engagement |
| Requête nécessitant une action ou une attente | Oui | Nécessite un suivi et un SLA |
| Incident susceptible de se reproduire | Oui, avec une catégorisation de la cause | Nécessite une analyse de tendance |
Décision 2 : Qui reçoit la requête ?
L'échec courant réside dans un routage basé uniquement sur le département, ce qui crée une seule grande file d'attente où les agents "piochent" les requêtes les plus simples. Les requêtes complexes vieillissent au fond de la file jusqu'à ce que quelqu'un les escalade par téléphone, transformant ainsi tout le mécanisme de SLA en un théâtre d'ombres.
Un modèle d'affectation approprié définit trois dimensions : la compétence requise, la capacité réelle de l'agent (pas le nombre de Cases mais leur "poids"), et les règles d'escalade basées sur le temps. Omni-Channel Routing prend en charge ces trois dimensions, mais uniquement si des compétences réelles ont été définies. Définir "Compétence : Support" pour tous les agents équivaut à ne rien définir.
Une description complète du routage omnicanal est disponible dans Omnichannel et SLA dans Service Cloud.
Décision 3 : Quand le décompte commence-t-il ?
C'est la décision que la plupart des organisations négligent, et c'est celle qui détermine la fiabilité des indicateurs. Des questions qui nécessitent une réponse écrite :
- Quand le décompte commence-t-il ? – Au moment de la réception de la requête, ou au début des prochaines heures ouvrables ? Les Business Hours doivent impérativement être définies pour chaque fuseau horaire pertinent.
- Quand est-il suspendu ? – Un Case en attente de réponse du client doit suspendre le compteur, sous peine de pénaliser le centre de contact pour la lenteur du client.
- Qu'est-ce qui est mesuré précisément ? – Le temps de première réponse, le temps de résolution, ou les deux avec des objectifs distincts pour chaque niveau de criticité.
- Que se passe-t-il avant un dépassement ? – Un Milestone générant une alerte à 80% du temps alloué est plus utile qu'un rapport mensuel de dépassements.
Les Entitlements et les Milestones sont les mécanismes qui implémentent ces quatre points. Leur activation sans une décision écrite préalable génère des alertes ignorées en moins de deux semaines.
Décision 4 : Où se trouve l'information ?
La Knowledge Base n'est pas un projet isolé, mais une condition essentielle pour réduire la charge de travail. L'échec habituel : les articles sont rédigés au lancement, personne ne les maintient, et six mois plus tard, les agents retournent poser des questions sur un chat interne.
Ce qui fonctionne : un cycle de vie défini pour chaque article — Owner, date de révision, et indicateur d'utilisation. Un Case clos sans article lié et apparaissant cinq fois au cours du même trimestre est un déclencheur automatique pour la création d'un article. Une analyse approfondie de ce sujet est disponible dans Gestion des connaissances dans Salesforce.
Indicateurs opérationnels
| Indicateur | Définition | Seuil d'examen |
|---|---|---|
| First response time | Jusqu'au premier contact humain | Dépassement pour plus de 10% des requêtes |
| First contact resolution | Fermé sans transfert | Inférieur à 60% |
| Reopen rate | Case rouvert dans les 7 jours | Supérieur à 8% |
| Backlog aging | Cases ouverts au-delà du SLA | Tendance à la hausse hebdomadaire |
| Knowledge attach rate | Cases avec un article lié | Inférieur à 30% |
Le Reopen rate est l'indicateur le plus important et généralement le plus négligé : il révèle les fermetures prématurées effectuées pour atteindre des objectifs de temps.
Ordre de travail recommandé
Première vague : Définition du Case, un ou deux canaux, routage de base, SLA pour un niveau de criticité, et dix articles Knowledge pour les requêtes fréquentes. Deuxième vague : canaux supplémentaires, compétences, Entitlements complets, Self-Service. Lancer tout en même temps conduit à un centre de contact devant gérer un changement de processus, un changement d'outil et un changement de mesure la même semaine – et généralement à revenir à des méthodes de contournement.
Conclusion
Une implémentation réussie de Service Cloud se mesure à une seule question : le responsable du centre de contact peut-il montrer, depuis le système et sans feuille de calcul auxiliaire, où se trouvent les requêtes qui dépassent les délais et pourquoi ? Si les quatre décisions sont claires, la réponse existe. Sinon, il y a un nouveau système, mais le même centre de contact.