Réponse rapide
Omni-Channel n'est pas un mécanisme de distribution, mais un modèle de capacité. Il pose une seule question à tout moment : quelle quantité de travail cet agent peut-il gérer maintenant ? Si la réponse à cette question est incorrecte – par exemple, si le chat et l'e-mail se voient attribuer le même poids – le routage fonctionnera exactement comme défini et nuira au service.
Par conséquent, l'ordre de travail est le suivant : d'abord le modèle de capacité et les poids, ensuite les compétences, puis les Entitlements et les Milestones, et seulement à la fin les automatisations d'escalade.
Le modèle de capacité : le point déterminant
Omni-Channel attribue une « quota de travail » (capacité) à chaque agent et un poids à chaque élément de travail. Un centre d'appels qui attribue un poids uniforme à tous les canaux obtient l'un des deux résultats suivants : soit les agents du chat sont débordés par la charge de travail, soit les agents qui traitent les e-mails apparaissent occupés alors qu'ils sont disponibles.
Point de départ raisonnable pour l'étalonnage :
| Type de tâche | Caractéristique | Poids relatif recommandé |
|---|---|---|
| Appel téléphonique | Entièrement synchrone | Occupe toute la capacité |
| Chat en direct | Synchrone avec de courtes pauses | Élevé, généralement 2-3 simultanés au maximum |
| E-mail / Formulaire | Asynchrone | Faible |
| Requête en attente du client | Inactif | Zéro - doit libérer de la capacité |
La dernière ligne représente la source d'erreurs la plus courante : une requête en attente du client qui continue d'occuper de la capacité fait apparaître les agents comme occupés alors qu'ils n'ont pas de travail actif.
Compétences : Moins est plus
Le routage basé sur les compétences semble être une amélioration évidente, mais en pratique, c'est la source la plus fréquente de requêtes bloquées. Plus on ajoute d'exigences en matière de compétences, plus la probabilité qu'aucun agent disponible ne réponde à toutes ces exigences augmente.
Trois règles pour éviter cela : ne définir les compétences que lorsque leur absence empêche réellement le traitement ; définir un niveau de Fallback pour chaque exigence, qui est activé après un temps d'attente défini ; et vérifier chaque mois le nombre de requêtes attribuées via Fallback – un pourcentage élevé indique que le modèle ne correspond pas à l'effectif du centre.
Entitlements et Milestones : de l'engagement au mécanisme
Un SLA qui n'apparaît que dans un rapport est une déclaration a posteriori. Les Entitlements et les Milestones en font un mécanisme actif :
- Entitlement définit le niveau de service auquel chaque client a droit – généralement une valeur par défaut et quelques exceptions contractuelles.
- Milestone définit les points de temps mesurés : première réponse, mise à jour périodique, résolution.
- Business Hours déterminent quand le compteur est actif, et doivent être définies séparément pour chaque fuseau horaire et chaque canal.
- Stopped Time gèle le compteur en attente du client – sans cela, les indicateurs pénalisent le centre pour le comportement du client.
- Les actions de Milestone génèrent des alertes et des escalades avant le dépassement, généralement autour de 75-80% du temps.
La règle d'or : si la première alerte arrive après le dépassement, le mécanisme mesure plutôt qu'il ne gère.
Les décisions fondamentales concernant la définition des Cas et l'horaire SLA sont détaillées dans Implémentation de Service Cloud.
Comment savoir si le modèle est défaillant
Cinq signes avant-coureurs, avant que les mesures mensuelles ne révèlent un problème :
- Pourcentage élevé d'attributions via Fallback – les compétences ne correspondent pas à l'effectif.
- Requêtes dans la file d'attente d'attribution dépassant quelques minutes – manque de capacité ou règle d'Overflow manquante.
- Agents signalant une surcharge de travail alors que le rapport de capacité indique une disponibilité – poids incorrects.
- Concentration anormale des dépassements de SLA à une heure fixe de la journée – problème d'effectif, pas de routage.
- Taux élevé de requêtes attribuées et immédiatement abandonnées – les agents refusent le travail qui ne leur convient pas.
Mesure continue
| Mesure | Ce qu'elle révèle |
|---|---|
| Temps dans la file d'attente d'attribution | Si le modèle trouve un agent à temps |
| Utilisation moyenne de la capacité | Si les poids sont réalistes |
| Dépassements par Milestone | Où exactement le SLA a été rompu |
| Taux d'escalades évitées | Si l'alerte précoce fonctionne |
| Écarts de dépassement entre les canaux | Si un canal spécifique est désavantagé dans le routage |
Ordre de mise en œuvre
Activez un seul canal avec un seul Entitlement et sans compétences, calibrez les poids sur des données réelles pendant deux semaines, et seulement ensuite ajoutez un deuxième canal et des compétences. Une activation complète en un jour empêche d'identifier quel composant a causé la surcharge, et se termine généralement par la désactivation du routage et le retour aux files d'attente manuelles.
Résumé
Omni-Channel est un modèle de capacité et non de distribution, et le SLA est un mécanisme d'alerte et non un rapport. Ces deux principes déterminent si le centre d'appels fonctionnera selon le système ou trouvera des moyens de le contourner – et la différence est déjà perceptible dès la première semaine d'opération.