Gérer les SLA dans un contexte Omni-Channel

Omni-Channel ne gère pas les SLA nativement : il route le travail, mais ne connaît rien des engagements contractuels de délai. C'est la combinaison avec les Entitlements, les Milestones et une priorisation de routage bien pensée qui permet réellement de tenir vos SLA. Voici comment articuler ces briques.

Rappel : Entitlements et Milestones

Le module SLA natif de Salesforce repose sur :

• Entitlement : le contrat de service associé à un compte ou un contact, définissant les canaux couverts et les horaires de service (Business Hours).
• Milestone : une étape chronométrée à l'intérieur d'un Entitlement, par exemple « Premier temps de réponse » ou « Résolution », avec une échéance calculée à partir des heures d'ouverture.
• Entitlement Process : le moteur qui déclenche les Milestones à la création du Case et suit leur respect ou leur dépassement.

Ces objets calculent des échéances mais n'influencent pas, par eux-mêmes, l'ordre de routage dans Omni-Channel.

Relier l'échéance SLA à la priorité de routage

Le point clé : il faut traduire le temps restant avant échéance de Milestone en priorité de routage exploitable par la Routing Configuration. Approche recommandée :

1. Créez un champ formule ou un champ mis à jour par Flow, par exemple Minutes_Avant_Echeance__c, calculé à partir du champ TargetDate du Milestone actif.
2. Construisez un Flow planifié (Scheduled-Triggered Flow) exécuté toutes les 5 à 15 minutes, qui recalcule un champ Priorite_Routage__c sur les Cases encore en file d'attente : plus l'échéance approche, plus la priorité numérique diminue (donc devient prioritaire).
3. Mappez ce champ sur la Routing Configuration pour que le moteur Omni-Channel réordonne dynamiquement les éléments en attente selon l'urgence réelle du SLA, pas seulement selon la priorité initiale à la création.

Gérer le risque de dépassement en amont

Il est préférable d'anticiper plutôt que de réagir après coup. Deux mécanismes complémentaires :

• Warning Actions sur les Milestones : déclenchées à un pourcentage du délai consommé (souvent 75-80%), elles peuvent envoyer un e-mail, notifier un superviseur, ou — via un Flow associé — augmenter automatiquement la priorité de routage du Case concerné.
• Success/Violation Actions : à l'échéance dépassée, déclenchez une notification vers Omni Supervisor ou un canal Slack/Chatter pour intervention manuelle immédiate.

Cas des canaux asynchrones (email, WhatsApp)

Sur les canaux asynchrones, le risque est que le SLA coure pendant que l'élément de travail attend en file, sans qu'aucun agent ne le voie avant l'échéance. Pour limiter ce risque :

• Réduisez le Push Time-out sur les Routing Configurations couvrant des éléments à fort enjeu SLA, pour accélérer la réaffectation en cas de non-réponse d'un agent.
• Envisagez un modèle de capacité qui réserve une part de la capacité des agents seniors aux dossiers proches de l'échéance (voir l'article dédié aux Capacity Models).

Attention : augmenter artificiellement la priorité de tous les Cases proches de l'échéance peut créer un effet de bord où plus rien ne respecte l'ordre initial pensé pour les comptes VIP. Réservez le recalcul dynamique de priorité aux cas réellement à risque de violation, pas à l'ensemble du portefeuille.

Mesurer le respect des SLA côté routage

Pour évaluer si votre configuration Omni-Channel sert bien vos SLA, croisez dans un rapport :

• Le temps d'attente en file (avant première prise en charge par un agent) issu des logs Omni-Channel (objet AgentWork).
• Le statut du Milestone associé (respecté / en violation) au moment de la première réponse.
• La Routing Configuration et la file d'origine, pour identifier les segments où le SLA est structurellement à risque (sous-effectif, compétences rares, poids de capacité mal calibré).

Ce croisement révèle souvent que les violations de SLA ne viennent pas d'un manque global d'agents, mais d'un déséquilibre de configuration sur une file ou une compétence précise — un problème de paramétrage Omni-Channel, pas de capacité brute.