Un accord sur les niveaux de service (SLA) est une politique que vous définissez et qui mesure les délais de réponse et de résolution que votre équipe d’assistance fournit à vos clients. Vous pouvez définir de nombreuses normes de service dans une politique SLA, notamment la qualité, la disponibilité ou le respect des délais. La mesure de délai avant première réponse est très importante pour l’expérience globale de vos clients et c’est la mesure qui peut être le plus influencée par le routage omnicanal.
Vous pouvez utiliser les rapports Explore pour comprendre vos mesures actuelles, identifier vos objectifs SLA de délai avant première réponse, puis utiliser diverses fonctionnalités du routage omnicanal pour atteindre ces objectifs.
- Recueil et suivi des données de délai avant première réponse
- Comprendre la mesure SLA de délai avant première réponse
- Création d’une politique SLA de délai avant première réponse
- Définition de files d’attente du routage omnicanal correspondant à vos politiques SLA
- Optimisation de la configuration de votre routage omnicanal pour vos politiques SLA
- Autres optimisations pour vos politiques SLA
Recueil et suivi des données de délai avant première réponse
Avant d’implémenter le routage omnicanal ou les délais de réponse, vous devez comprendre vos niveaux de service par canal. Ces données servent de référence et vous permettent de mesurer le succès de la configuration de votre routage omnicanal et de vos politiques SLA.
Dans Explore, vous pouvez générer des rapports sur vos données de délai de réponse pour les tickets par e-mail et messagerie. Quand vous définissez votre rapport, vous pouvez spécifier l’unité de temps (secondes, minutes ou heures) et choisir si le calcul de la mesure se limite aux heures ouvrées (si configurées pour Support ou la messagerie) ou s’il utilise les heures calendaires. En outre, vous pouvez décider si vos rapports porteront sur le délai moyen avant première réponse ou le temps de réponse moyen, et appliquer des filtres temporels pour inclure les données historiques. Pour en savoir plus, consultez les informations sur les rapports sur le délai avant première réponse pour les tickets Support et de messagerie.
Pour mesurer le temps de réponse pour les appels, utilisez la mesure de temps d’attente de l’appel. C’est la mesure la plus proche de la mesure de délai avant première réponse pour les tickets par e-mail et messagerie car elle mesure le temps écoulé entre l’arrivée de l’appel et son routage initial jusqu’à la première connexion du client à un agent. Pour en savoir plus, consultez Appels entrants par temps d’attente.
Comprendre la mesure SLA de délai avant première réponse
-
Temps en file d’attenteLe temps que les tickets passent en file d’attente avant d’être affectés ou proposés à un agent dépend directement de trois facteurs :
- Disponibilité des agents. Cela dépend du ou des groupes d’agents vers lesquels la file d’attente route les tickets, ainsi que du statut, de la capacité et des compétences des agents de ce ou ces groupes. Quand vous utilisez des files d’attente de routage omnicanal personnalisées, les groupes d’agents principaux sont considérés en premier, avant de passer aux groupes secondaires si nécessaire. Plus le nombre d’agents éligibles pour recevoir du travail d’une file d’attente est élevé, plus vite les tickets quittent la file d’attente et leur sont affectés ou proposés. Réfléchissez à l’allocation du personnel et la planification afin de vous assurer qu’il y a suffisamment d’agents dans les groupes d’une file d’attente pour gérer le volume de tickets attendu et, si ce n’est pas le cas, résolvez rapidement le problème pour maintenir les niveaux de service souhaités.
- Position des tickets dans une file d’attente. Les tickets au début de la file d’attente sont affectés en premier et l’ordre des tickets dans la file d’attente est déterminé en premier lieu par la priorité des tickets, puis par leur horodatage.
- Priorité de la file d’attente. Quand les agents reçoivent du travail provenant de plusieurs files d’attente, les tickets de la file d’attente avec la priorité la plus élevée sont affectés aux agents en premier. Pour minimiser les conflits, faites attention aux chevauchements des groupes principaux et secondaires que vous configurez pour chaque file d’attente.
-
Délai d’acceptation
Dans la configuration du routage omnicanal standard, les tickets par e-mail sont automatiquement affectés aux agents, donc le concept de délai d’acceptation ne s’applique pas. Cependant, les tickets par messagerie, eux, sont proposés aux agents au lieu de leur être affectés directement. Si le premier agent auquel le ticket est proposé ne l’accepte pas, le routage omnicanal continue de le proposer aux agents disponibles jusqu’à ce que l’un d’entre eux l’accepte.
Si vous avez peur que les conversations par messagerie ne soient pas acceptées assez vite, vous pouvez activer l’acceptation automatique pour la messagerie dans votre configuration du routage omnicanal. Ce comportement élimine le délai d’acceptation.
-
Temps de réponse
Une fois un ticket affecté ou accepté, l’agent doit le lire et comprendre ce dont l’utilisateur final a besoin. Puis, il doit rédiger une réponse pertinente. Vous pouvez minimiser le temps de réponse en utilisant le module supplémentaire IA avancée pour résumer la demande et même répondre au ticket.
Pour savoir comment votre configuration du routage omnicanal affecte les mesures de délai avant première réponse, consultez Optimisation de la configuration de votre routage omnicanal pour vos politiques SLA.
Création d’une politique SLA de délai avant première réponse
- Existants plus X % : avec ce modèle, vous décidez de quel pourcentage vous voulez améliorer vos niveaux de service existants. Même si vous et vos clients êtes satisfaits des niveaux de service existants, vous pouvez malgré tout utiliser cette méthode pour améliorer progressivement vos normes.
- Normes du secteur pour les niveaux de service : dans certains cas, il existe des normes de niveaux de service clairement définies que vous devez respecter. Un exemple courant est une norme de réponse à 80 % des messages dans un délai de 20 secondes.
- Niveaux de service différenciés : ce modèle est adapté si vos niveaux de service dépendent du type d’utilisateur final. Par exemple, si vos utilisateurs peuvent payer pour bénéficier d’un service premium ou si vous accordez une priorité et des niveaux de service plus élevés aux segments de clientèle importants.
Dans la plupart des cas, vous devrez définir des politiques de délai avant première réponse différentes pour chaque canal que vos clients utilisent pour vous contacter. Généralement, le délai avant première réponse pour les tickets par e-mail se compte en minutes ou en heures, alors que pour les canaux en direct, il se compte en secondes ou en minutes. En plus des niveaux de service en fonction du canal, vous pouvez aussi différencier les niveaux de service en fonction du sujet, des utilisateurs finaux ou des organisations, ou même du sentiment client (si vous utilisez le module supplémentaire IA avancée). Les sujets sensibles, les clients VIP, les clients que vous risquez de perdre ou les clients en colère peuvent tous bénéficier de niveaux de service plus élevés.
Par exemple, vous pouvez définir des politiques SLA en fonction de deux éléments : le canal via lequel vous recevez le ticket et s’il provient d’un client VIP ou non. Dans ce cas, votre liste de SLA, allant du délai de réponse le plus court au plus long, pourrait être : messages VIP, messages non-VIP, formulaire Web VIP, formulaire Web non-VIP.
Pour créer une politique SLA, consultez Définition des politiques SLA.
Définition de files d’attente du routage omnicanal correspondant à vos politiques SLA
Un moyen très efficace d’exploiter le routage omnicanal pour respecter vos SLA est de définir des files d’attente qui correspondent à vos politiques SLA. Le routage omnicanal agence les tickets dans les files d’attente par priorité et par horodatage de création. Cela signifie que les tickets les plus proches du dépassement de votre SLA de temps de réponse suivant sont généralement en haut des files d’attente et qu’ils seront donc affectés en premier. Si vous combinez le comportement d’ordre des files d’attente standard avec la priorité de la file d’attente et un agencement en fonction des politiques SLA, vous garantissez que les tickets les plus importants nécessitant le temps de réponse le plus court sont traités en priorité non seulement au niveau des files d’attente mais aussi au sein même des files d’attente.
- ont les mêmes conditions que vos politiques SLA ;
- sont dans le même ordre que vos politiques SLA ;
- ont les priorités adéquates, correspondant aux exigences de chaque politique SLA.
En continuant avec les exemples de SLA précédents, vous pourriez créer quatre files d’attente du routage omnicanal personnalisées avec les mêmes noms et conditions et les agencer dans le même ordre. Dans ce scénario, le SLA Messages VIP nécessiterait le temps de réponse le plus court et la file d’attente Messages VIP aurait donc la priorité la plus élevée et serait placée en haut de la liste.
Dans ces files d’attente, vous pouvez configurer les groupes auxquels sont affectés les tickets de plusieurs façons différentes. Cependant, pour notre exemple, disons que les quatre files d’attente routent les tickets à un groupe principal de niveau 1, puis si nécessaire, à un groupe secondaire de niveau 2. Une autre possibilité serait de spécifier des groupes secondaires uniquement pour les files d’attente Messages VIP et Formulaire Web VIP.
Optimisation de la configuration de votre routage omnicanal pour vos politiques SLA
Quand vous optimisez les paramètres du routage omnicanal pour vos politiques SLA, vous devez prendre deux aspects en compte (en plus des files d’attente) : la capacité des agents et les différents paramètres de configuration du routage que vous utilisez.
Alignement de la capacité des agents avec les SLA
Quand vous utilisez le routage omnicanal, les règles de capacité établies pour les agents affectent directement leur capacité à recevoir des tickets (leur disponibilité) et donc à y répondre. Les capacités maximales déterminent le nombre de tickets simultanés auxquels peut être affecté un agent par canal. Quand les agents ont des règles de capacité, le routage omnicanal suit chaque ticket actif ouvert affecté à chaque agent et n’envoie du travail aux agents que s’ils ont un statut éligible et ne sont pas à leur capacité maximale pour ce canal.
Les règles de capacité pour les appels sont simples car il n’y a que deux options : zéro (l’agent ne peut pas recevoir d’appels) ou un. Il peut être plus compliqué de définir les règles de capacité pour les canaux d’e-mail et de messagerie. Si vous définissez une capacité maximale trop basse, cela peut avoir un impact négatif sur les niveaux de service car les tickets attendent trop longtemps en file d’attente avant qu’un agent puisse y répondre. Et inversement, si vous définissez une capacité trop élevée, cela peut aussi avoir un impact négatif car les agents risquent d’être débordés par le travail qui leur est affecté et de ne pas réussir à gérer tous les tickets assez rapidement.
Au départ, fiez-vous à votre intuition pour définir les capacités maximales. Cependant, le meilleur moyen de définir les règles de capacité est d’utiliser les rapports Explore et de vous servir des données. Quand vous utilisez Explore pour définir vos règles de capacité, regardez le volume de tickets créés pendant un certain nombre de jours ou de semaines et le nombre de tickets résolus par un agent ou un groupe d’agents au cours de cette période. Si besoin est, vous pouvez adopter une approche plus granulaire et vous pencher sur les tickets créés et résolus par heure. N’oubliez pas que la capacité de messagerie que vous définissez s’applique aussi séparément aux chats en direct dans certaines circonstances.
Alignement des paramètres de configuration du routage omnicanal avec les SLA
Compétences
L’intégration des compétences à votre solution de routage peut être un excellent moyen de vous assurer que les tickets sont affectés aux bons agents. L’affectation d’un agent doté des compétences et des connaissances nécessaires pour résoudre un ticket contribue à l’amélioration de la qualité de service (mesurée par la satisfaction client et le temps de traitement moyen). Quand vous utilisez les compétences, il est important de bien réfléchir car si vous exigez trop de compétences pour un ticket, les agents capables de le gérer seront peu nombreux et il risque de se retrouver coincé longtemps en file d’attente en attendant que l’un d’entre eux soit disponible. Quand vous associez les compétences aux files d’attente du routage omnicanal personnalisées, il est important d’allouer un nombre suffisant d’agents avec les compétences requises par les tickets dans les files d’attente desquelles ils reçoivent du travail.
Pour trouver le bon équilibre entre la valeur qu’apporte l’utilisation des compétences et le risque que les tickets doivent attendre trop longtemps avant d’être affectés à un agent, nous vous conseillons d’utiliser le délai d’expiration et la priorité des compétences. Quand vous activez le paramètre de délai d’expiration des compétences, le routage omnicanal ne prend plus les compétences facultatives en compte après qu’un ticket a passé une durée spécifiée en haut de la file d’attente. Chaque compétence qui n’est plus prise en compte accroît le nombre d’agents éligibles pour recevoir le ticket, qui a donc plus de chances d’être affecté. Si vous décidez d’utiliser les compétences et ne configurez pas le délai d’expiration, les tickets resteront indéfiniment en haut de la file d’attente jusqu’à ce qu’un agent avec toutes les compétences (obligatoires et facultatives) correspondantes soit disponible pour recevoir le ticket.
Si vous ne savez pas combien de tickets sont affectés à un groupe avec ou sans compétences, vous pouvez utiliser le jeu de données Support dans Explore pour produire un rapport présentant ces informations pour une période donnée.
Pour en savoir plus, consultez À propos de l’utilisation des compétences pour router les tickets.
Acceptation automatique pour la messagerie
Le comportement de messagerie standard consistant à proposer les conversations aux agents au lieu de les affecter peut accroître le délai avant première réponse. Si cela vous pose un problème, le routage omnicanal vous permet d’affecter automatiquement les conversations par messagerie aux agents, de la même façon que les tickets par e-mail. Nous vous conseillons vivement d’utiliser cette fonctionnalité pour améliorer vos mesures de délai avant première réponse.
Notez que vous ne pouvez pas utiliser le paramètre d’acceptation automatique avec le délai de réaffectation de la messagerie. Vous devez choisir l’un ou l’autre.
Délai de réaffectation de la messagerie
Le délai de réaffectation de la messagerie est une autre option qui peut vous aider à améliorer le délai avant première réponse pour les conversations par messagerie. Quand le routage omnicanal est configuré pour proposer les tickets de messagerie aux agents au lieu de les leur affecter directement, ce paramètre garantit que le moteur de routage passe à l’agent disponible suivant si un agent prend trop de temps pour accepter le ticket. Le délai de réaffectation de la messagerie par défaut est de 30 secondes, mais avec les éditions Enterprise, vous pouvez le modifier. Si vous avez un SLA de délai de réponse particulièrement court pour les messages, vous devriez envisager de réduire le délai de réaffectation des messages.
La configuration du délai d’inactivité pour les statuts d’agent unifiés peut aussi vous aider à minimiser le temps pendant lequel les tickets sont proposés aux agents car les agents inactifs auront automatiquement un statut qui n’est pas éligible pour recevoir du travail des canaux en temps réel comme la messagerie.
Routage des activités de messagerie
Le paramètre de routage des activités de messagerie permet de libérer automatiquement de la capacité des agents pour les conversations par messagerie (et les chats en direct) en configurant automatiquement les conversations comme inactives après 10 minutes sans réponse de l’utilisateur final.
Les tickets qui deviennent inactifs alors qu’ils sont en file d’attente sont directement affectés aux agents, au lieu de leur être simplement proposés. Cela accroît la probabilité que les tickets avec des interactions actives des utilisateurs finaux arrivent en haut de la file d’attente quand l’utilisateur final est encore là et attend une réponse. De la même façon, si un utilisateur final arrête de répondre à une conversation par messagerie qui est déjà affectée à un agent, le routage omnicanal la marque automatiquement comme inactive et libère de la capacité pour cet agent pour qu’il soit possible de lui affecter plus de tickets de messagerie actifs.
Ce comportement de routage omnicanal standard peut vous aider à respecter vos SLA de délai avant première réponse pour les tickets les plus récents, mais peut aussi être problématique selon votre organisation et vos workflows. Par exemple, si beaucoup de messages arrivent hors des horaires d’ouverture alors qu’aucun de vos agents n’est disponible, les conversations par messagerie deviennent inactives et peuvent être affectées au premier agent à se connecter le matin suivant, qui se retrouve débordé même s’il semble avoir de la capacité.
Si vous activez le routage des activités de messagerie, le routage omnicanal traite tous les messages (actifs et inactifs) de la même façon, quel que soit leur âge. Cela garantit que les messages des clients sont traités dans l’ordre dans lequel ils sont reçus, quelles qu’aient été les activités récentes. Cela résout le problème des agents qui se retrouvent débordés de tickets inactifs et le problème des tickets inactifs, non résolus, qu’un agent ne traite pas parce qu’il se concentre sur les conversations actives, mais cela signifie aussi que les agents doivent gérer leur propre capacité de messagerie en modifiant manuellement le statut des tickets de messagerie auxquels les utilisateurs finaux ne répondent plus et en le définissant sur En attente ou Résolu.
Mode Focus
Si vous activez le mode Focus, le routage omnicanal n’affecte à un agent que du travail provenant d’un seul canal en temps réel (appels, messagerie ou chat en direct) à la fois. Dans certains cas, permettre à un agent de se consacrer entièrement à une seule interaction peut améliorer la qualité de cette interaction et accélérer la résolution. Cependant, cela risque d’allonger votre délai avant première réponse global car les appels et les conversations risquent de rester plus longtemps en file d’attente.
Autres optimisations pour vos politiques SLA
Le routage omnicanal est un outil puissant qui peut vous aider à atteindre les niveaux de service que vous recherchez. Cependant, il peut arriver que la différence entre vos niveaux de service réels et vos niveaux de service souhaités soit telle que vous avez quand même besoin d’agents supplémentaires. Si vous avez implémenté toutes ces meilleures pratiques et n’arrivez toujours pas à atteindre les niveaux de service souhaités, réévaluez votre allocation de personnel et votre planification.