SLA ServiceNow : priorités, heures d'ouverture et escalade utile

Commencez par l’engagement plutôt que par la minuterie

Un engagement de service décrit ce à quoi les utilisateurs peuvent s'attendre et dans quelles conditions. Un minuteur dans ServiceNow implémente une partie de cet accord ; il ne définit pas l'accord en soi. Clarifiez le service, les demandes éligibles, l’objectif de réponse ou de résolution et la fenêtre de mesure. Distinguer l'accusé de réception d'une demande du rétablissement du service. Un objectif de réponse courte en dit long sur la résolution si l’affaire reste intacte par la suite. Rédigez l’engagement dans un langage que le personnel d’assistance et les propriétaires d’entreprise comprennent avant de configurer les conditions. Cela empêche un compteur techniquement précis de mesurer un mauvais résultat opérationnel.

Relier la priorité à l’impact et à l’urgence

L’impact concerne l’ampleur et les conséquences de l’interruption. L’urgence concerne la rapidité avec laquelle une action est nécessaire. Définissez comment ils se combinent en priorité à l’aide d’exemples de votre organisation. Un utilisateur incapable d'exécuter une fonction critique et urgente peut avoir besoin d'une décision différente de celle de nombreux utilisateurs confrontés à un inconvénient mineur. Évitez de donner à chaque demandeur un contrôle illimité sur la priorité la plus élevée. Conservez un processus d'examen documenté et conservez les raisons pour lesquelles une priorité a changé. Une classification cohérente rend les engagements plus utiles et empêche les statistiques de refléter uniquement quelle équipe applique l'étiquette la plus bruyante.

Définir quand le timing commence

Déterminez l'événement qui attache l'engagement applicable à une tâche. Cela peut dépendre du service, du type de tâche, de la priorité ou d'autres conditions convenues. Considérez ce qui se passe si les informations sont corrigées après la création. Un changement de priorité ultérieur ne doit pas créer un résultat de timing inexpliqué. ServiceNow propose des choix de configuration dont le comportement exact doit être vérifié dans votre version et testé avec des enregistrements représentatifs. Enregistrez d’abord l’interprétation commerciale prévue. Ne présumez pas que le temps de création, le temps d’affectation et le début du temps d’activité compté signifient toujours la même chose.

Utilisez délibérément les horaires et les fuseaux horaires

Un engagement pendant les heures ouvrables diffère d'un engagement sur le temps écoulé. Convenez du calendrier applicable, de la manière dont les jours fériés sont gérés et du fuseau horaire qui régit le calendrier. Les équipes d'assistance distribuées peuvent transférer le travail entre les sites, mais cela ne modifie pas automatiquement l'engagement du client. Les cas de test ont été ouverts vers l'heure de fermeture, pendant un week-end et autour d'une exception d'horaire. Passez en revue l’heure affichée avec les personnes qui utilisent les rapports. Un délai apparemment impossible peut résulter de la configuration du calendrier plutôt que d’un dysfonctionnement du minuteur, et un rapport favorable peut cacher l’erreur inverse.

Rendre les règles de pause et de reprise défendables

Certains engagements permettent de faire une pause en attendant une information ou un autre événement convenu. Définissez-le explicitement plutôt que de faire une pause chaque fois qu'une tâche ne vous convient pas. L'état et la raison enregistrés doivent refléter la réalité et permettre aux utilisateurs de comprendre ce qui manque. Vérifiez ce qui reprend le timing et ce qui se passe lorsqu'un demandeur répond. Les transitions temporelles de ServiceNow dépendent des conditions configurées. Testez donc leurs interactions plutôt que d’évaluer chaque règle isolément. Des pauses excessives ou incohérentes peuvent améliorer la conformité signalée sans améliorer le service offert aux utilisateurs.

Définir la clôture, l'annulation et la réouverture

Décidez de ce qui constitue le succès pour chaque cible. Un engagement de réponse peut être complété avant un engagement de résolution. L'annulation doit être distincte de l'exécution, et les cas en double doivent suivre la politique de traitement convenue. La réouverture d'une tâche peut affecter le calendrier et les rapports ; documentez le comportement prévu et validez-le dans le flux de travail configuré. Ne fermez pas les dossiers simplement pour arrêter un chronomètre. Préservez la relation entre l’état opérationnel et ce que les utilisateurs ont réellement vécu. Les rapports doivent expliquer quels engagements s'appliquent et pourquoi ils ont été complétés, annulés ou remplacés.

Exemple : une demande ouverte avant un jour férié

Un employé signale un problème d'accès non critique peu avant la fermeture du centre de services. L'engagement suit les heures de bureau et un jour férié à venir. La tâche est assignée, puis attend l'approbation requise en vertu de la politique convenue. Le rapport doit indiquer quelles périodes ont été comptées et quelles conditions ont interrompu le chronométrage. Si le demandeur fournit des informations, le workflow reprend correctement. Parcourez la chronologie avec le propriétaire du service avant de publier la règle. Cet exemple expose des erreurs de calendrier et de transition qu'un simple test de jour ne révélerait jamais.

Escalader avec une action et un propriétaire

Une escalade doit indiquer à quelqu'un ce qui nécessite une attention particulière et quelle décision est attendue. L'envoi d'avertissements répétés à une grande liste de diffusion ne constitue pas un plan de réponse. Définissez le groupe responsable, le contact de secours et les informations incluses dans l'alerte. L'escalade peut concerner une propriété manquante, des délais imminents ou un impact durable sur les utilisateurs. Évitez de changer automatiquement de priorité uniquement en raison du temps passé, à moins que cela ne fasse partie d'une politique délibérée. Gardez les notifications proportionnées et assurez-vous qu’elles n’exposent pas le contenu restreint du ticket à des personnes qui n’ont pas accès au cas sous-jacent.

Lisez les rapports sans récompenser les mauvais comportements

Mesurez la conformité en fonction des réouvertures, des transferts, du vieillissement non résolu et des commentaires des utilisateurs. Ventilez les résultats par service et par priorité plutôt que de comparer des charges de travail non liées. Recherchez pourquoi les engagements n’ont pas été respectés et si les pauses ou les annulations faussent le tableau. Une équipe peut apparaître plus rapidement en clôturant les dossiers plus tôt ou en transférant le travail vers une autre file d'attente. Utilisez des examens de cas pour comprendre les chiffres et améliorer le processus. Le but du reporting est d’identifier les problèmes de service et de soutenir les décisions, et non de créer une compétition qui encourage le personnel à manipuler les États.

Testez les changements avant de les appliquer largement

Créez des scénarios de création, de correction de priorité, de réaffectation, d'attente, de réponse du demandeur, de résolution et de réouverture. Incluez les limites d’horaire et les conditions contradictoires. Vérifiez les enregistrements existants séparément de ceux nouvellement créés lors de la modification des définitions. Confirmez l'effet avec les administrateurs de la plateforme et le propriétaire du service. Conservez un enregistrement de la configuration et de la version testée. Un changement de calendrier peut affecter les décisions opérationnelles et l'interprétation historique, évitez donc les modifications silencieuses effectuées simplement pour réparer un rapport décevant. Un petit pilote contrôlé révèle les conséquences avant que la règle n'atteigne toutes les tâches de support.

Atelier : rédiger un tableau d'acceptation du timing

Pour un service, rédigez une chronologie avec l’heure d’ouverture, les changements d’état et le temps compté prévu. Ajoutez un week-end, des vacances et une pause approuvée. Demandez à un représentant du support technique et à un propriétaire d'entreprise d'examiner le résultat attendu avant la configuration. Reproduisez les cas dans un environnement de test et comparez les transitions réelles. Vérifiez les notifications et qui les reçoit. Documentez tout désaccord dans l’engagement plutôt que de le cacher dans des conditions techniques. Cet atelier produit un test d'acceptation reproductible et aide les équipes à distinguer les défauts de configuration des attentes floues.

Questions fréquemment posées

Un SLA manqué prouve-t-il que chaque partie du service a échoué ? Il identifie un engagement manqué dans son périmètre défini ; enquêter sur le cas sous-jacent et l’impact sur l’utilisateur.

L'attente doit-elle toujours mettre le temps en pause ? Seulement si la politique convenue le permet et que la raison enregistrée est authentique.

Une définition peut-elle servir à chaque service ? La simplicité est précieuse, mais des engagements sensiblement différents nécessitent un traitement explicite.

Comment Tuplify Studio peut-il vous aider ? Nous pouvons configurer des règles de timing, prendre en charge des flux de travail et des tableaux de bord compréhensibles. Le résultat utile est un engagement que le personnel peut expliquer et sur lequel agir, plutôt qu'un ensemble de compteurs auxquels personne ne fait confiance.