Aller au contenu
Tramework

· Jean-Emmanuel N'Zi Yao · 4 min de lecture

Service desk télécom : tenir le volume sans perdre les SLA

  • telecom
  • itsm
  • sla

Chez un opérateur, le service desk interne reçoit en une journée ce qu'une PME reçoit en un mois : postes des centres d'appels, accès aux outils de facturation, équipements de terrain, applications de distribution, incidents de production qui touchent des milliers d'abonnés. À cette échelle, une étape manuelle par ticket n'est pas un défaut de process, c'est un poste à temps plein. Voici ce qui tient, d'après les projets télécom que j'ai menés.

Le problème n'est pas le volume, c'est la variance

Mille tickets par jour se traitent très bien si chacun arrive au bon endroit avec les bonnes informations. Ce qui casse un service desk télécom, c'est la variance : le même incident décrit de dix façons, catégorisé par dix analystes, priorisé selon l'humeur du demandeur, affecté à la mauvaise équipe deux fois sur cinq. Chaque variance se paie en réaffectations, en relances et en rapports faux.

L'objectif d'une plateforme à cette échelle est donc simple à énoncer : retirer la décision humaine partout où une règle la prend mieux, et garder l'analyste pour l'exception.

Catégoriser par règles, pas à la main

Un analyste qui catégorise mille tickets par jour se trompe, et le reporting devient une fiction. La catégorie doit venir de trois sources, dans cet ordre :

  1. L'article de catalogue choisi. Quand le demandeur passe par le portail, il a déjà tout dit : « accès à l'outil de facturation » est une catégorie, une équipe et un délai.
  2. Le demandeur. Son site, son service, son rôle sont dans l'annuaire ; ils déterminent l'équipe de première ligne.
  3. Le texte. Des règles sur les mots-clés attrapent le reste : « SIM », « portabilité », « antenne » ont chacun leur file.

Ce que l'analyste corrige ensuite est l'exception. Et chaque correction nourrit la prochaine règle.

La priorité se calcule, elle ne se choisit pas

Laisser le demandeur choisir la priorité produit une file où tout est urgent, donc rien. La priorité est une matrice impact × urgence, calculée à la création. L'impact vient de la CMDB : un incident sur le système de facturation touche tous les centres d'appels, un poste de travail touche une personne. L'urgence vient de l'échéance : une activation bloquée le jour d'une campagne commerciale n'est pas une activation bloquée un mardi calme.

Le résultat est une priorité prévisible et défendable, la même pour tous, et un comité de direction qui arrête de demander pourquoi tel ticket a été traité avant tel autre.

Le portail employés est le premier niveau, pas un canal de plus

Sur un opérateur, chaque demande résolue sans agent vaut un poste d'analyste. Le portail doit donc résoudre, pas seulement enregistrer : réinitialisation de mot de passe, demandes d'accès standard avec approbation automatique du responsable, questions fréquentes, état des incidents en cours pour éviter les doublons.

Ce qui fait la différence n'est pas le nombre d'articles, c'est leur qualité : des formulaires courts, des variables qui posent la bonne question, des réponses de la base de connaissances affichées avant même que le ticket existe. L'assistant IA du portail va plus loin dans cette direction, avec vos clés ; les règles et le catalogue font déjà l'essentiel.

Des SLA par service, avec des calendriers différents

Un engagement unique « résolution en huit heures » est faux pour tout le monde : trop court pour un poste de travail en province, trop long pour la facturation. Définissez les engagements par service métier (facturation, activation, centres d'appels, réseau de distribution) et par priorité, avec des calendriers de service distincts : les équipes 24/7 n'ont pas les mêmes heures que les fonctions support.

La plateforme attache la bonne définition selon le service touché, et les compteurs tournent sur le bon calendrier. Le rapport de respect des engagements devient enfin comparable d'un mois à l'autre.

Trois rapports pour décider, le reste en libre-service

Le comité de direction n'a besoin que de trois vues : le volume par service et par catégorie, le respect des engagements par équipe, l'arriéré par âge. Tout le reste est du détail pour les responsables d'équipe, qui composent leurs propres tableaux de bord depuis l'interface sans passer par l'informatique décisionnelle.

Pourquoi une plateforme plutôt qu'un outil de tickets

Parce que chaque point ci-dessus est une règle, un flux ou un modèle de données à adapter à votre organisation, pas une case à cocher dans un menu. Une plateforme dont les tables, les règles et les flux se configurent depuis l'interface absorbe ces ajustements chaque semaine ; un outil fermé finit contourné par des tableurs, et le tableur devient le vrai système.

Sur TRAMEWORK, tout cela est disponible dès l'ouverture d'une instance : règles métier, flux, matrice de priorité, catalogue avec approbations, SLA avec calendriers, CMDB alignée CSDM, portail composable, rapports et tableaux de bord. Et sans limite d'utilisateurs, ce qui compte quand on a mille agents et quinze mille demandeurs.

Par où commencer

Choisissez la file la plus bruyante (souvent les accès aux outils des centres d'appels). Mettez ses cinq demandes les plus fréquentes au catalogue, avec approbation automatique du responsable. Mesurez le volume résiduel après un mois. C'est en général là que le projet trouve son budget.

Ouvrez votre instance. Elle est à vous, sans limite de temps.

Instance prête en quelques secondes · Aucune carte bancaire · Aucune limite de temps