Console de tickets · le poste de travail du service client

La Console de tickets est l'espace où votre équipe traite les demandes : la file d'attente avec ses vues enregistrées à gauche, la conversation avec le client au centre, et le contexte du ticket avec les compteurs de SLA et l'IA à droite. On y trouve aussi l'adresse e-mail entrante, les macros, le routage, les automatisations, les incidents, la base de connaissances et les indicateurs de l'équipe.

La Console de tickets est le poste de travail du service client de SellioCRM : un seul endroit pour traiter les demandes en file d'attente, du premier e-mail du client jusqu'à l'enquête de satisfaction. Elle s'appuie sur le même objet Ticket que le CRM, donc tout ce que vous saisissez déjà (objet, entreprise, contact, catégorie, canal) reste valable et apparaît dans la vue 360° du client.

Ouvrez-la depuis le menu latéral, dans le groupe Service, sur Console de tickets. L'objet Tickets reste dans le même groupe pour celles et ceux qui préfèrent la saisie en formulaire, le tableau par statut et les vues de liste.

Une mise en page en trois volets

La console s'ouvre en trois volets, pensés pour une personne qui traite des demandes toute la journée : à gauche les vues et les files avec leurs compteurs, au centre la conversation avec le client, à droite le contexte du ticket. Sur mobile, le volet des vues devient un sélecteur en haut de la liste, pour ne pas prendre de place.

La file d'attente et les vues enregistrées

• La colonne de gauche propose des vues prêtes à l'emploi avec le nombre de demandes dans chacune : Ouverts, Non attribués, Les miens, En attente (client ou tiers) et Résolus aujourd'hui.
• Vues enregistrées : créez un filtre nommé par statut, priorité, attribution et groupe, par exemple Urgents de l'équipe support. Il apparaît dans la liste avec son propre compteur.
• Au-dessus de la file se trouvent la recherche (par objet ou par demandeur), le filtre de priorité et le tri : plus récents, plus anciens, par priorité ou par échéance de SLA.
• Chaque ligne affiche l'objet, le demandeur, le statut, la priorité, le responsable et l'état du SLA, avec des pastilles de couleur pour une lecture rapide.
• Actions en masse : cochez la case en haut pour sélectionner plusieurs demandes et leur appliquer un statut ou un responsable en une fois.

La console de l'agent

À l'ouverture d'une demande, la conversation s'affiche au centre par ordre chronologique et les propriétés restent à droite : demandeur, canal d'entrée, étiquettes, statut, priorité, catégorie, responsable et groupe. Toute modification de propriété est enregistrée immédiatement.

1. Dans l'éditeur de message, choisissez Réponse au client pour écrire un texte que le client verra, ou Note interne pour consigner quelque chose de visible uniquement par l'équipe.
2. La note interne apparaît mise en évidence dans une autre couleur, pour ne pas la confondre avec ce qui a été dit au client.
3. Cliquez sur Joindre pour envoyer des fichiers avec le message (jusqu'à 25 Mo chacun). Dans une réponse publique, les liens des pièces jointes sont également repris dans le corps de l'e-mail envoyé au client.
4. Rédigez, puis cliquez sur Envoyer (ou Ajouter une note).

• Numéro de ticket : chaque demande reçoit un numéro séquentiel par organisation, au format #000123. Il est immuable, apparaît dans la file, en haut de la demande et dans l'e-mail de réponse.
• Chronologie : l'onglet Chronologie fusionne, dans l'ordre, les messages publics et internes ainsi que les événements de changement (création, statut, priorité, responsable et autres propriétés).
• Mentions et abonnés : dans une note interne, utilisez Mentionner pour interpeller un collègue. Il reçoit une notification et devient abonné à la demande. Chacun peut s'abonner ou se désabonner depuis le volet des propriétés et reçoit un avis à chaque mise à jour.

Macros et variables

1. Cliquez sur Gérer les macros pour créer des réponses types avec un titre et un corps.
2. La macro peut aussi définir le statut et la priorité à appliquer lors de son utilisation.
3. Dans l'éditeur de message, sélectionnez la macro dans Appliquer une macro : le corps se place dans le champ de réponse et, si cela a été configuré, le statut et la priorité sont appliqués.

Les macros et les réponses acceptent des variables entre doubles accolades, remplies au moment de l'envoi : {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} et {{org_name}}, entre autres. Dans Canaux et routage, vous définissez une Signature du service client, ajoutée aux réponses publiques ; la signature personnelle de l'agent, lorsqu'elle existe, est prioritaire.

SLA : délais, pause, horaires et jours fériés

L'état du SLA apparaît dans la file et dans la demande : Dans les délais ou SLA dépassé tant qu'elle est ouverte, puis Résolu dans les délais ou Résolu hors délais une fois traitée. À droite, les compteurs de première réponse, de prochaine réponse et de résolution font un compte à rebours et changent de couleur : vert, jaune à l'approche de l'échéance et rouge une fois dépassée. Quand le statut passe à Résolu ou Fermé, la date de résolution est horodatée automatiquement.

• Pause automatique : lorsque la demande passe à En attente du client ou En attente d'un tiers, le compteur de résolution se met en pause et une pastille SLA en pause apparaît. Au retour à un statut actif, le compteur repart. Le temps d'attente ne compte ni pour votre objectif ni dans les indicateurs.
• Prochaine réponse : chaque politique peut fixer un objectif de prochaine réponse. Le compteur démarre quand le client répond et redémarre à chaque nouvelle réponse publique de l'agent.
• Heures ouvrées : dans l'onglet SLA et horaires, vous définissez les jours, les heures et le fuseau (indiquez un fuseau tel que Europe/Paris pour respecter l'heure d'été). Désactivez la restriction pour compter en temps continu (service 24h/24 et 7j/7).
• Jours fériés : enregistrez les jours fériés par date. Ces jours-là, l'agence est considérée comme fermée et l'échéance est repoussée au jour ouvré suivant.
• Politiques : chaque politique s'applique selon la priorité, le groupe ou la catégorie (vide signifie n'importe lequel) et fixe des objectifs en minutes ouvrées. Elles sont évaluées dans l'ordre de la liste et la première politique active qui correspond l'emporte. Si aucune ne correspond, ce sont les heures par priorité définies dans Paramètres, Service qui s'appliquent.
• Risque de dépassement : une barre estimée indique si la demande présente un risque faible, moyen ou élevé de dépasser l'échéance, avec le motif.

E-mail entrant : l'e-mail devient une demande

1. Ouvrez la Console de tickets et allez dans l'onglet Canaux et routage.
2. Cliquez sur Générer une adresse de support. Le CRM affiche une adresse au format support+votre-code@domaine.
3. Chez votre fournisseur de messagerie, redirigez la boîte du support vers cette adresse.
4. C'est fait : les nouveaux e-mails ouvrent des demandes et les réponses du client rejoignent la même conversation.

L'expéditeur est rattaché à un Contact grâce à son e-mail ; la première fois, le Contact est créé, et le canal de la demande est fixé à E-mail. Chaque réponse envoyée au client porte le code de la demande dans l'objet, au format [#XXXXXXXX]. Quand le client répond en conservant ce code, le message rejoint la même conversation au lieu d'ouvrir une nouvelle demande ; si la demande était résolue ou fermée, elle est rouverte.

Accusé de réception automatique : dans Canaux et routage, activez l'Accusé de réception et rédigez le texte avec ses variables. Quand un e-mail ouvre une nouvelle demande, le demandeur reçoit immédiatement l'accusé avec le numéro de ticket. Cette option est désactivée au départ.

Fusionner des demandes et conversations parallèles

Quand un même sujet a donné lieu à deux demandes, ouvrez celle qui restera la principale et cliquez sur Fusionner. Les messages de l'autre passent dans la principale et celle-ci est clôturée avec un message indiquant où le contenu a été déplacé.

Vous devez échanger avec un fournisseur ou une autre équipe sans que le client le voie ? Utilisez les Conversations parallèles, juste sous la conversation principale : indiquez un objet et les participants par e-mail, rédigez le message et le CRM l'envoie. Tout reste consigné dans la demande, séparé de la conversation avec le client.

Attribution automatique et automatisations

Dans Canaux et routage, définissez pour chaque équipe la façon dont les demandes sont réparties à leur arrivée dans le groupe : Rotation (alternance entre les agents) ou Par charge (l'agent avec le moins de demandes ouvertes en premier). Laissez sur Désactivée pour attribuer toujours à la main.

Dans l'onglet Automatisations, vous créez des règles du type quand quelque chose change, alors agis. Chaque règle comporte un événement (la demande est créée, ou une propriété change), des conditions facultatives de statut, priorité, catégorie, groupe et responsable, et une ou plusieurs actions.

• Actions : définir le statut, la priorité ou la catégorie ; attribuer à un agent ou à un groupe ; appliquer une macro ; notifier le responsable ; notifier tout le groupe ; envoyer l'enquête de satisfaction.
• Les règles s'exécutent au moment exact de la création ou du changement, où qu'il se produise dans le CRM : console, modification de l'enregistrement ou intégration.
• Faites glisser la poignée à gauche du nom pour réordonner les règles ; elles sont évaluées de haut en bas.
• Automatisations temporelles : elles s'exécutent seules à intervalles réguliers et agissent selon l'échéance, par exemple escalader une demande sans première réponse depuis X heures ouvrées, alerter quand l'échéance approche ou fermer les demandes résolues depuis N jours. Chacune agit au maximum une fois par demande.
• Webhooks sortants : dans Canaux et routage, informez des systèmes externes à chaque événement de la demande (créée, mise à jour, résolue, nouveau message), vers une URL signée ou vers les canaux de messagerie déjà connectés dans le hub d'Intégrations.

L'intelligence artificielle appliquée à la demande

Avec l'IA activée, le volet de droite analyse la demande et propose : la catégorie et l'urgence, le sentiment du client avec une note de 0 à 100, un résumé de l'historique, des demandes similaires et des articles de la base de connaissances. Dans l'éditeur de message, le bouton Suggérer une réponse (IA) rédige un brouillon à partir de la conversation, dans la langue de votre interface. L'IA n'envoie jamais rien au client toute seule : vous relisez, vous modifiez et vous décidez.

Base de connaissances et centre d'aide

Votre base de connaissances alimente un portail public en libre-service avec une recherche par titre, contenu et étiquettes. En bas de page, le formulaire j'ai encore besoin d'aide propose des articles liés pendant que la personne saisit son texte (déflexion) et, si cela reste nécessaire, ouvre une demande directement dans votre CRM.

• Dans Marketing, Base de connaissances, l'onglet Articles permet d'écrire, de modifier et d'envoyer en relecture ; l'onglet Relecture est la file de validation (Approuver et publier ou Rejeter avec un motif) ; l'onglet Importer crée un brouillon à partir d'une URL ; l'onglet Retours montre les articles les plus utiles et ceux qui demandent de l'attention, selon les votes des lecteurs.
• Chaque enregistrement conserve un historique et vous pouvez restaurer une version antérieure.
• Chaque article a une langue, et la recherche publique peut filtrer selon la langue du lecteur.
• Dans l'onglet SLA et horaires, vous composez les formulaires d'ouverture du portail : en plus du nom, de l'e-mail, de l'objet et du message, ajoutez vos propres champs texte, liste ou e-mail, avec affichage conditionnel. Marquez-en un par défaut pour que le centre d'aide l'utilise.

Incidents et page de statut

1. Ouvrez l'onglet Incidents de la console et créez un incident avec un titre et une gravité.
2. Rattachez les demandes touchées par le même événement.
3. Publiez des mises à jour dans la chronologie de l'incident et informez tous les clients concernés en une fois, par e-mail aux demandeurs des demandes rattachées.
4. À la résolution, consignez la cause racine et le post-mortem.
5. Marquez l'incident comme public pour exposer une page de statut ouverte à vos clients.

Satisfaction et indicateurs

À la résolution ou à la fermeture d'une demande, le CRM envoie automatiquement une enquête de satisfaction par e-mail au demandeur, avec une note de 1 à 5 et un commentaire. Elle n'est envoyée qu'une seule fois par demande. Quand le client répond, la note apparaît dans le bloc Satisfaction de la console et est enregistrée dans les champs de la demande elle-même. Activez ou désactivez cette option dans Automatisations, Enquête de satisfaction, et utilisez Renvoyer l'enquête pour redemander un avis.

Dans l'onglet Indicateurs, vous suivez la période de 7, 30 ou 90 jours : demandes créées, résolues et ouvertes, délai moyen de première réponse, délai moyen de résolution, pourcentage dans les délais du SLA, satisfaction moyenne avec le taux de réponse, backlog, résolution au premier contact, taux de réouverture et charge par équipe, avec une segmentation par canal et par catégorie et un tableau par agent. Les indicateurs montrent la variation par rapport à la période précédente et un mini-graphique journalier, et les rapports peuvent être exportés en PDF ou en XLSX.

Questions fréquentes

• L'envoi de l'enquête dépend de l'e-mail du demandeur, du champ de la demande ou du Contact rattaché, et de la configuration de l'envoi d'e-mails.
• Lorsque vous exportez ou anonymisez les données d'une personne concernée dans Paramètres, Confidentialité, le contenu des messages et des évaluations de ce demandeur est également inclus ou anonymisé.
• Les intégrations avec des help desks externes créent automatiquement des demandes dans le CRM ; une fois créées, vous les traitez ici comme n'importe quelle autre.
• Dans l'application mobile, vous suivez aussi la file, ouvrez une demande, répondez et changez le statut.
• Pour que le client suive lui-même ses demandes, réponde et les rouvre, consultez l'article sur le portail client.

Cas parent et enfant, règles de réponse automatique et mappage de canal

Un cas peut désormais dépendre d'un autre. Vous définissez le parent sur le cas et les enfants s'affichent en liste, avec une garde qui refuse une boucle ou une chaîne trop profonde, et un avertissement quand vous tentez de fermer un parent qui a encore des enfants ouverts. La réponse automatique est devenue des **règles** au lieu d'un texte fixe : chaque règle a ses conditions (canal, catégorie, priorité, heures ouvrées, premier message seulement, mots-clés) et son message, et la première qui correspond l'emporte. La garde anti-boucle n'est pas désactivable, volontairement : répondre à une boîte automatique, c'est deux répondeurs qui se parlent sans fin. Et le canal du cas vient maintenant d'une **table de mappage** que vous contrôlez, donc le cas arrivé par téléphone dans votre help desk cesse d'être enregistré comme « portail » et vos rapports par canal cessent de mentir.

Où les trouver : le parent et les enfants apparaissent sur le ticket lui-même, dans le panneau **Cas liés**. Les règles sont dans **Paramètres → Réponses automatiques**, et la correspondance dans **Paramètres → Canaux de ticket** ; les deux sont réservés à l'administration du compte.

Le ticket a un troisième onglet, **Contexte**, et c'est là que la console cesse de vous envoyer sur un autre écran. Il regroupe les champs du ticket lui-même (y compris ceux que vous avez créés), les enregistrements liés, les activités et les tâches, les fichiers, les cas parent et enfants, et les autres tickets ouverts du même client. Si vous avez conçu un Canvas pour l'objet Ticket, cette mise en page vaut aussi ici : vous ne dessinez pas deux fois la même chose.

Clôturer un ticket avec un code de résultat

Résoudre un ticket consistait à saisir du texte libre dans le champ Résolution. Cela décrit ce qui s'est passé, mais ne le classe pas : deux agents écrivent le même résultat de dix façons, et personne ne peut dire combien de tickets du mois dernier venaient d'un défaut produit et combien d'une erreur de configuration. Le champ Catégorie n'aide pas davantage, car il classe le sujet à l'ouverture du ticket, pas le résultat à la clôture.

Le résultat est donc désormais une courte liste que vous maîtrisez, dans **Paramètres → Codes de résultat**. Chaque code a un libellé, une portée et une option qui définit si le choisir exige une explication (utilisez-la sur « Autre », qui sinon n'explique rien). La même liste sert aux tickets et aux appels téléphoniques, vous gardez ainsi un seul vocabulaire au lieu de deux qui disent la même chose.

1. Ouvrez Paramètres → Codes de résultat et cliquez sur Générer la liste par défaut, ou écrivez votre propre liste.
2. Activez « Exiger un résultat à la résolution » si vous voulez que la règle s'applique.
3. Dans la console, choisissez le résultat dans l'encadré Clôture, à droite, avant de résoudre le ticket.

Trois comportements à connaître, car ils sont voulus :

• **Activer l'exigence avant d'avoir le moindre code ne bloque rien.** Sinon elle figerait tous les tickets de l'entreprise le jour où quelqu'un coche la case, sans rien à choisir.
• **L'exigence est appliquée par le serveur, pas par l'écran.** Clôturer depuis la liste, depuis une macro, depuis l'API ou depuis le terminal passe par le même contrôle.
• **Un code déjà utilisé ne peut pas être supprimé, seulement désactivé.** Le supprimer retirerait son sens à chaque ticket clos avec lui, et vos anciens rapports se mettraient à mentir en silence.

Texte rapide : des phrases toutes prêtes derrière un raccourci que vous tapez

Jusqu'ici le seul texte tout prêt de la console était la macro, et une macro applique aussi un statut et une priorité : insérer une phrase modifiait le ticket sans que personne l'ait demandé. Le texte rapide n'écrit rien d'autre que le texte. C'est pour cela qu'il peut être léger, personnel et accessible par un raccourci que vous tapez.

1. Dans l'éditeur, tapez :: suivi du début d'un raccourci, par exemple ::hi.
2. Continuez à taper pour réduire la liste, ou tapez seulement :: pour voir toute la bibliothèque.
3. Choisissez une phrase dans la liste, ou terminez le raccourci et validez pour insérer celle qui correspond exactement.
4. Relisez le texte avant d’envoyer : les variables entre doubles accolades, comme {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} et {{org_name}}, sont remplies à l’envoi de la réponse, comme dans les macros.

Il y a trois bibliothèques : **personnelle** (vous seul la voyez), **d'équipe** (les membres de cette équipe) et **d'entreprise** (toutes les personnes qui répondent). Le même raccourci peut exister dans plusieurs, et la plus proche de vous l'emporte : votre phrase personnelle bat celle de l'équipe, et celle de l'équipe bat celle de l'entreprise. Vous gardez ainsi votre version de ::hi sans demander à personne de changer le standard de la maison.

• **Un raccourci n'a ni espace ni deux-points**, et fait au plus 40 caractères. Un raccourci avec un espace ne pourrait jamais être tapé après ::, il est donc refusé à l'enregistrement au lieu de devenir une phrase qui n'apparaît jamais.
• **Le raccourci est unique dans sa propre bibliothèque.** Le même ::hi peut exister comme phrase personnelle et comme phrase d'entreprise ; deux d'entreprise, non.
• **La recherche ignore la casse et les accents** et regarde le raccourci, puis le titre, puis le dossier. Le corps n'est jamais cherché : un mot courant correspondrait à la moitié de la bibliothèque et le raccourci perdrait son intérêt.
• **L'ordre est toujours le même** : raccourci qui commence par ce que vous avez tapé, puis raccourci qui le contient, puis titre, puis dossier. Une liste dont l'ordre change entre deux ouvertures vous ferait choisir la mauvaise phrase par mémoire du geste.
• **Le dossier est du texte libre** et ne sert qu'à regrouper la bibliothèque à l'écran. Il n'y a pas de catalogue de catégories séparé à entretenir.

Vos phrases personnelles sont à vous : vous les créez, les modifiez et les supprimez sans rien demander. Les phrases d'équipe et d'entreprise sont le standard de la maison, car elles changent ce que tout le monde enverra aux clients demain, elles appartiennent donc à qui administre les paramètres. Personne ne modifie la phrase personnelle d'une autre personne, pas même l'administration.

E-mails du ticket : votre propre texte par événement, langue, catégorie et file

Cinq moments du ticket peuvent porter un texte à vous : **ouvert**, **mis à jour**, **résolu**, **enquête** et **clôture**. Chaque modèle est écrit dans une langue et peut, si vous le souhaitez, être limité à une catégorie, à une file, ou aux deux.

Le choix suit un ordre déclaré, et il se lit mieux en deux moitiés : le système décide d'abord **quoi dire** et seulement ensuite **dans quelle langue le dire**. Les familles sont parcourues de la plus précise à la plus générique : file et catégorie, puis file, puis catégorie, puis la générique. La file pèse plus que la catégorie parce que la file est l'équipe qui répond et le texte est sa voix ; la catégorie n'est que le sujet.

• **Un filtre vide est un joker, un filtre rempli doit correspondre.** Un modèle sans catégorie sert à n'importe quelle catégorie. Un modèle avec catégorie ne sert qu'à celle-ci et ne tient jamais lieu de texte générique.
• **La langue, à l'intérieur de la famille retenue** : d'abord l'exacte (pt-BR), puis la même langue de base (pt-PT sert à pt-BR), puis la langue de secours, qui est l'anglais tant que vous n'en indiquez pas une autre.
• **Une famille qui n'a aucune de ces trois langues est ignorée**, et la suivante, moins précise, est tentée. Envoyer le texte générique dans la langue de la personne qui lit vaut mieux qu'envoyer le bon texte dans une langue qu'elle ne lit pas.
• **La précision passe avant la langue.** Si la famille Facturation n'existe qu'en anglais et la générique en portugais, une personne qui écrit en portugais reçoit le texte de Facturation en anglais. Le correctif est d'ajouter la ligne en portugais de la même famille, et c'est exactement ce que le tableau vous demande.

La langue prise en compte est celle de **la personne qui a ouvert le ticket**, celle qui lit l'e-mail, et non celle de l'agent. Objet et corps acceptent les mêmes variables que les macros et les textes rapides, et l'aperçu montre quel modèle l'a emporté et dans quelle langue avant que quoi que ce soit ne parte.

Swarm : appeler du monde sur un cas difficile et consigner ce qui en est sorti

Une session de swarm consigne le rituel qui vivait jusqu'ici éparpillé dans les notes internes : qui a été appelé, dans quel rôle, pour répondre à quelle question, jusqu'à quand, et ce qui a été conclu. **Elle consigne la session ; elle n'ouvre pas de canal Slack et ne lance pas de visioconférence.** La conversation continue là où elle a déjà lieu (note interne, mention, abonnés, chat interne) ; ce qui apparaît, c'est sa mémoire.

1. Sur le ticket, ouvrez un swarm et écrivez la raison. L'échéance est facultative et ne peut pas être dans le passé.
2. La personne qui ouvre la session en est le **rapporteur** et se met à suivre le ticket.
3. Appelez les personnes nécessaires comme **spécialiste** (sans limite) ou comme **scribe** (place unique). Qui est appelé reçoit un avis portant la raison et se met à suivre le ticket.
4. Clôturez la session avec le **résultat**. Il revient sur le ticket sous forme de note interne, pour que la personne suivante sur le cas le lise sans rien ouvrir d'autre.

• **Une seule session ouverte par ticket.** Deux couperaient l'attention en deux, et le résultat n'aurait plus d'endroit unique.
• **Rapporteur et scribe sont des places uniques tant qu'elles sont occupées** ; spécialiste n'a pas de plafond, car appeler du monde est précisément l'objet du swarm.
• **Le rapporteur ne quitte pas la session.** La sortie consiste à la clôturer en disant ce qui a été conclu, même si c'est « rien n'a été conclu ».
• **Clôturer exige le résultat**, et met fin à la participation de tous, pour que les minutes de personnes cessent de croître toutes seules.
• **Qui est parti reste visible dans le registre.** Qui a participé doit rester vrai demain.

Relance programmée et rappel personnel

Deux actions qui se ressemblent et ne sont pas la même chose. La **relance** est une tâche sur le ticket : elle peut revenir à quelqu'un d'autre et apparaît dans la liste du jour comme toute tâche. Le **rappel** est toujours le vôtre et sonne à l'heure demandée, pas dans le résumé de fin de journée.

1. Sur le ticket, choisissez Programmer une relance ou Me le rappeler.
2. Écrivez quand, avec vos mots : demain 9h, dans 2 heures, vendredi, la semaine prochaine, ou une date comme 2026-09-10 14:30. Les dix langues du produit sont comprises.
3. Pour une relance, choisissez le type (tâche, appel, e-mail ou réunion) et, si vous voulez, la personne qui la prend. Le rappel est toujours une tâche, et toujours le vôtre.

• **Un jour sans heure devient 09:00** dans le fuseau de l'organisation, la même valeur par défaut que dans le reste du produit.
• **Une durée conserve l'heure actuelle**, car une durée la porte déjà en elle. Minutes et heures comptent en temps réel ; jours et semaines marchent sur le calendrier, si bien que l'heure d'été ne les déplace pas.
• **Une heure déjà passée part au lendemain**, comme dans toute application de rappel. Un jour dans le passé, lui, est refusé au lieu d'être deviné : deviner quel jour vous vouliez dire, ce serait inventer.
• **Au-delà de 365 jours, c'est refusé.** C'est le filtre du doigt qui glisse, le 2027 tapé en 2026 que personne ne verrait jamais.

L'écran répète l'heure réellement **enregistrée**, et non les mots que vous avez tapés, chaque fois que 09:00 a été supposé pour vous ou que l'heure a été repoussée au lendemain. Deux réponses différentes à « pour quand est-ce dû » sont exactement la confusion que cet écho existe pour éviter.

Onglets de travail : plusieurs cas ouverts en même temps

La console ouvrait un cas à la fois, et en choisir un autre remplaçait le précédent. Qui traite du volume mène trois ou quatre cas de front (un qui attend le client, un qui attend l'ingénierie, un en cours d'écriture), et chaque bascule perdait le brouillon et la position dans le défilement. La barre d'onglets de travail se place au-dessus de la conversation et apparaît dès qu'une deuxième chose est ouverte.

• **Un simple clic ouvre un onglet d'aperçu**, affiché en italique, et l'aperçu suivant prend sa place. Y écrire, ou l'épingler, le rend définitif. Sans cela, parcourir une file de vingt cas ouvrirait vingt onglets.
• **Le même cas ne s'ouvre jamais deux fois.** Cliquer à nouveau ne fait qu'activer l'onglet, avec le brouillon et le sous-onglet que vous y aviez laissés.
• **Le point bleu signale une réponse écrite et non envoyée** dans cet onglet. C'est ce qu'il faut voir avant de le fermer, pas après.
• **Chaque onglet retient son sous-onglet** (Conversation, Chronologie ou Contexte), pour que vous repreniez où vous en étiez et non au début.
• **Jusqu'à huit onglets.** Au-delà, l'onglet le plus ancien sans brouillon disparaît ; si tous ont un brouillon, la limite cède, car perdre du travail écrit est pire qu'une barre longue.
• **Fermer l'onglet actif active le voisin de droite**, et celui de gauche s'il n'y a pas de droite, comme le fait un navigateur.

**Fermer les enregistrés** ferme tous les onglets sans brouillon et conserve ceux qui en ont : le ménage n'emporte jamais du travail écrit. Les onglets vivent dans votre propre navigateur, sur cet appareil : ils sont à vous et non à l'équipe.

Contexte client : santé, valeur, plan et historique d'assistance

L'onglet Contexte d'un cas s'ouvre sur un bloc qui répond, avant que vous n'écriviez la moindre ligne, si ce client va bien, combien il vaut, sur quel plan il se trouve et combien de fois il a déjà été mal servi. Rien de tout cela n'est saisi par quelqu'un : tout est composé à partir de ce que le produit garde déjà sur ce compte.

• **Santé** montre le score et, plus important encore, **les facteurs qui le composent**. Un nombre seul ne vous dit rien sur quoi agir ; les facteurs disent si le problème est l'usage, l'assistance, l'argent ou la relation.
• **Valeur** apporte le revenu gagné, le revenu récurrent et le dernier mouvement, pour qu'une expansion le mois dernier et une réduction le mois dernier ne se ressemblent pas.
• **Plan** dit quel plan, depuis quand et quand il se renouvelle, et signale un renouvellement déjà marqué à risque.
• **Historique d'assistance** compte les cas précédents, combien d'entre eux ont dépassé le SLA, la satisfaction propre à ce client et s'il y a un cas critique ouvert en ce moment.

Sous le bloc, toute la conversation avec ce contact apparaît sur une seule ligne, quel que soit le canal : chat, SMS, WhatsApp, e-mail et cas ensemble, dans l'ordre. C'est le même historique que montre la fiche du contact, ramené dans la console pour que personne ne change d'écran juste pour se rappeler ce qui a déjà été dit.

Supervision : la même opération, vue par ceux qui la coordonnent

La console répond à « qu'est-ce que je fais maintenant ? » pour la personne qui traite. La supervision répond à une autre question, pour une autre personne : est-ce que l'opération tient le coup en ce moment. C'est un écran à part, fait pour rester ouvert sur un téléviseur, et il se rafraîchit tout seul.

• **L'opération tient-elle le coup ?** Éléments ouverts par file, combien sont sans responsable, combien attendent après nous, et combien vont dépasser leur échéance dans l'heure qui vient. Savoir ce qui va dépasser n'est pas la même chose que savoir ce qui a déjà dépassé, et le panneau garde les deux séparés.
• **Qui est surchargé et qui est libre ?** Éléments ouverts par personne face au plafond de cette personne, qui est sorti de la rotation et qui dirige la file.
• **Où est le goulot d'étranglement ?** La file avec la plus longue attente, le canal qui apporte le plus d'entrées, et la file dans laquelle personne ne peut piocher, parce qu'elle exige une compétence que personne dans l'équipe ne possède.
• **Que s'est-il passé dans la dernière heure ?** Le registre d'attribution est déjà en ajout seul, alors le panneau se contente de le montrer.

La supervision est réservée à ceux qui administrent, et c'est délibéré : elle montre la charge de chaque personne et qui est hors rotation. Surveiller les gens est un acte de gestion assumé, pas un effet de bord de l'ouverture d'un écran. Le panneau est en lecture seule : rien n'y réattribue ni n'y repriorise. Il désigne, et le travail se fait là où il habite déjà.

Catalogue de services : une vitrine à la place du cas vide

Qui a besoin de quelque chose en interne ouvre aujourd'hui un cas vide et écrit ce dont il se souvient. Le catalogue remplace cela par une vitrine : une liste de ce qu'on peut demander, chaque élément portant son propre formulaire, sa file et sa priorité. La demande ouvre un vrai cas, déjà rempli.

1. Dans Paramètres → Catalogue de services, la personne qui administre monte le catalogue : catégories, éléments, et les questions que pose chaque élément.
2. N'importe qui ouvre le même écran, choisit un service et remplit son formulaire.
3. Le système ouvre un cas dans la file de l'élément, avec sa priorité et les réponses à l'intérieur, dans le même format que celui déjà utilisé par le portail.
4. Si l’élément exige une approbation, le ticket s’ouvre tout de suite et l’approbation en attente bloque sa résolution : personne ne le clôture avant qu’une décision soit prise.

• **Désactiver un élément n'annule pas ce qui a déjà été demandé.** Cela veut dire « ne demandez plus ceci », jamais « annulez ce qui est en cours » : les cas déjà ouverts restent ouverts, avec la même file et la même échéance.
• **Un élément déjà demandé ne peut pas être supprimé, seulement désactivé.** Le supprimer ferait mentir l'historique sur ce qui a été demandé.
• **La demande fige un instantané du formulaire.** Changez les questions plus tard et l'ancienne demande continue de montrer les questions auxquelles cette personne a réellement répondu.
• **L'état d'une demande n'est pas une copie.** Il est lu depuis l'approbation elle-même à chaque fois, il ne peut donc jamais s'écarter de ce que le moteur d'approbation a décidé ailleurs.

Catalogue de services : réaliser la demande

Un élément du catalogue peut porter un plan de réalisation : ce qui doit se passer une fois que quelqu'un a demandé le service, et dans quel ordre. Chaque étape devient une **vraie tâche**, avec un responsable, une échéance, un rappel et une place dans la liste de tâches que la personne chargée de la faire ouvre tous les jours, et la dépendance entre les étapes est celle que les tâches possèdent déjà. Le plan est figé dans la demande au **démarrage** de la réalisation, pas au moment où le service est demandé : modifier l'élément plus tard ne réécrit jamais une demande déjà en cours, et la nouvelle version s'applique à partir du démarrage suivant.

Qui coordonne le travail dispose de la file de réalisation : ce qui est en attente, chez qui et depuis combien de temps. Une demande approuvée que personne n'a encore démarrée apparaît **en haut**, avec son âge bien en vue, car approuver ne démarre rien : quelqu'un doit encore mettre le plan en marche. Un élément qui n'attend aucune approbation démarre dès qu'il est demandé.

1. Dessinez le plan sur l'élément du catalogue : objet, type de tâche, échéance en jours comptés depuis le démarrage, qui la reçoit et, quand cela compte, l'étape précédente dont elle dépend.
2. Quand quelqu'un demande le service, le ticket s'ouvre comme il s'est toujours ouvert. Si l'élément exige une approbation, la réalisation attend la décision ; s'il n'y a aucune approbation à attendre, elle démarre tout de suite.
3. Au démarrage de la réalisation, le plan est figé dans la demande et les tâches naissent dans l'ordre des dépendances, chacune avec un responsable et une échéance.
4. Le panneau de la demande, dans le ticket, montre chaque étape, chez qui elle se trouve, l'échéance et ce qui est déjà fait. Les étapes apparaissent aussi dans l'historique du ticket, parce que ce sont des tâches ordinaires attachées au cas.
5. Cliquez sur Livré quand le service est réellement arrivé à la personne. Une étape obligatoire encore ouverte bloque, avec le motif bien en vue ; une étape marquée comme non obligatoire ne bloque jamais.
6. Marqué par erreur ? Annulez la livraison avec une note. C'est une nouvelle écriture : la livraison précédente reste dans l'historique, rien n'est effacé.

Équipements du client : le cas porte sur cet équipement-là

Un ticket peut désormais pointer vers l'**équipement** du client, l'unité installée avec son numéro de série, et plus seulement vers le modèle de produit qui a été vendu. Dans le ticket, vous le choisissez dans le parc installé du client, en cherchant par numéro de série, car c'est ainsi que le client le désigne au téléphone. Seul un équipement appartenant au client de ce ticket peut être rattaché, et à partir de là c'est l'historique de l'équipement lui-même qui raconte le service : les cas rattachés, détachés et résolus se retrouvent sur la même chronologie que l'installation, les déplacements et les entretiens.

L'arrêt est enregistré par des **personnes**, ou depuis le ticket lui-même. Il n'y a ici ni télémétrie ni signal machine : la disponibilité, le MTTR et le MTBF valent donc exactement ce que vaut la discipline de ceux qui les saisissent. L'écran le dit à voix haute au lieu de maquiller le chiffre.

• Garantie et couverture : la pastille de garantie (sous garantie, bientôt expirée, expirée) et le contrat de service s'affichent avant que vous n'ouvriez la bouche devant le client.
• Emplacement : déplacer l'équipement enregistre où il est allé, si bien que l'historique des emplacements est la lecture de ces mouvements, et non un champ unique qui oublie le passé.
• Remplacement avec filiation : remplacer retire l'ancienne unité et crée la nouvelle, qui hérite du compte, du contrat et de l'emplacement, avec un événement de chaque côté pointant vers l'autre.
• Cycle de vie : actif, en maintenance, en RMA, retiré et sorti des actifs. Ce qui est sorti des actifs ne revient pas, car la sortie est un fait comptable ; le chemin du retour consiste à enregistrer un nouvel équipement avec la filiation de l'ancien.
• Arrêt : ouvrir et fermer un arrêt, planifié ou non. Le même équipement n'est jamais à l'arrêt deux fois en même temps, et les arrêts qui se chevauchent sont fusionnés avant d'être additionnés, de sorte que la disponibilité ne devient jamais négative.
• Disponibilité : le pourcentage sur la fenêtre, avec la part planifiée séparée de la part non planifiée, parce qu'une fenêtre de maintenance convenue avec le client n'est pas une promesse rompue. Le MTTR et le MTBF restent vides sans assez de mesures.
• Risque et prochaine action : criticité, âge, pannes répétées, couverture et disponibilité mesurée s'additionnent en un score explicable, et le moteur déclare ce qu'il a dû supposer faute de données.

Base de connaissances : responsabilité, révision et usage

La base de connaissances a gagné la couche qui répond à qui répond de chaque article et s'il mérite encore votre confiance : un responsable, un relecteur, un cycle de révision en jours et, à partir de là, l'article **en retard de révision**. Le tableau de gouvernance est en direct, calculé au moment où vous l'ouvrez : il ne dépend donc jamais du passage nocturne. Seul l'article publié y est tenu : un brouillon est encore en cours d'écriture, et un article archivé est hors circulation.

La visibilité n'est plus seulement publié ou non. Chaque article a désormais un public : **externe**, c'est ce que le centre d'aide et le portail montrent à quiconque a le lien, et **interne** ne sort jamais du CRM. Tout article naît externe, exactement comme il se comportait avant : rien ne change tant que vous n'en décidez pas autrement.

• Le responsable et le relecteur sont des personnes de votre équipe, définies article par article. Sans responsable, l'article est signalé dans le tableau, et c'est là que cette absence se règle.
• Cycle de révision en jours : la prochaine révision est la dernière révision plus le cycle. Un article sans cycle n'arrive jamais à échéance, et personne n'est relancé à son sujet.
• L'avis de révision en retard part vers le **responsable** de l'article, une fois par échéance. Un article sans responsable ne prévient personne, car déverser chaque jour la moitié orpheline de la base dans la cloche de l'administration apprend aux gens à ignorer la cloche.
• Archiver retire un article de la circulation avec un auteur, une date et une piste d'audit, au lieu que quelqu'un modifie discrètement un champ de statut. Le désarchivage le renvoie au brouillon, jamais directement en ligne.
• Brouillon écrit par l'IA à partir de tickets résolus : choisissez jusqu'à cinq cas clos, pointez une lacune si vous le souhaitez, et l'assistant écrit un article réutilisable. Il **naît toujours comme brouillon** et entre dans la même file de révision que n'importe quel article écrit à la main : l'IA propose, une personne approuve. Seuls les tickets résolus sont utilisés, car un cas ouvert n'a pas encore de réponse.
• Usage par article : combien de visites ont ouvert chaque article, par quelle porte, et quels articles publiés personne n'a lus sur la période, c'est-à-dire la part de la base qui ne travaille pas.

Libre-service : l'assistant et le taux de déflexion

La base de connaissances publique a désormais un assistant. Il répond en s'appuyant **uniquement** sur vos articles publiés et montre les sources qu'il a utilisées, pour que celui qui lit une réponse générée puisse vérifier d'où elle vient. Quand il ne trouve rien, il le dit et renvoie vers le formulaire d'ouverture, et la question restée sans réponse est enregistrée comme lacune de couverture. Il ne comble jamais le silence par une étape inventée, et lorsqu'aucune IA n'est configurée, il montre les articles trouvés au lieu de faire semblant d'être hors service.

C'est ce qui rend la déflexion mesurable, et la définition est stricte à dessein : un **ticket évité est une déclaration explicite** de quelqu'un qui était en route pour ouvrir un cas et qui a renoncé, après avoir reçu une réponse ou un article suggéré et cliqué pour dire que cela avait résolu son problème. Rien d'autre ne compte.

• Lire un article ne compte pas. Celui qui lit est peut-être en train de comparer, de se renseigner, ou de lire le mauvais article sur le chemin d'un ticket qu'il ouvrira de toute façon.
• Chercher sans issue ne compte pas. Fermer l'onglet n'est pas un succès.
• Le ticket l'emporte sur la déclaration : si la personne a dit que c'était résolu et a ouvert un cas dans la même visite, la visite compte comme un ticket. Nous préférons mesurer moins.
• Une visite qui n'a rien décidé reste entièrement hors du taux, ni au numérateur ni au dénominateur, et elle est rapportée à part comme indécise.
• Le taux est la part des visites qui **ont décidé quelque chose** et ont décidé de ne pas ouvrir de ticket. Sans aucune décision sur la période, le taux reste vide et jamais à 0 %, car ne pas savoir et zéro pour cent sont deux réponses différentes.
• L'entonnoir (recherches, questions, questions répondues) mesure la portée, pas le résultat, et rien de tout cela n'entre dans le taux.

Analyses du support : rapports tout prêts, constats et prévision

L'onglet Analyses de la console de tickets répond à ce qu'aucun écran ne répondait : depuis combien de temps la file attend, quelle part de chaque jalon promis a été tenue, combien de tickets ont été escaladés, ce que la voix, le bot et la messagerie ont fait, ce que les incidents ont coûté en tickets, où va le volume et, pour finir, quoi en faire. Chaque chiffre arrive déjà calculé par le serveur : deux écrans ne peuvent donc pas se contredire en silence sur la même valeur.

Deux lectures qui se ressemblent sans être la même : **l'âge court à l'horloge** (le temps de calendrier depuis la création du ticket) et **l'échéance court sur les heures ouvrées** (la promesse de SLA, pauses déduites). Elles portent des noms différents à dessein. Les mélanger donnerait deux chiffres sous la même étiquette et aucun moyen de savoir lequel a été rompu.

• Rapports tout prêts : un clic transforme un modèle en rapport à vous, nommé dans votre langue. À partir de là, c'est un rapport ordinaire, modifiable, partageable, exportable et programmable comme n'importe quel autre, sans aucun moteur séparé derrière.
• Constats : SLA en dessous de l'objectif, il entre plus qu'il ne sort, file qui vieillit, réouvertures, escalade, lacune de connaissances. Chacun arrive avec les chiffres qui le soutiennent, une cause probable et une action, classés par poids.
• Respect par jalon : première réponse, réponse suivante et résolution, et pas la résolution seule. La réponse suivante, c'est chaque fois que le client revient après avoir déjà reçu une réponse, et seuls les cas qui avaient réellement une échéance entrent dans le calcul.
• Vieillissement de la file par tranches (moins d'un jour, un à trois jours, trois à sept, plus d'une semaine), au global, par file et par agent, avec le cas le plus ancien bien en vue.
• Le bot a trois issues, pas deux : traité sans humain, transféré à un humain, et **a demandé un humain sans que personne ne vienne**, ce qui est une file abandonnée et se cachait auparavant dans le chiffre des traités.
• La voix, la messagerie et les incidents ont chacun leur lecture, parce qu'une conversation WhatsApp n'est pas un ticket et qu'un incident se mesure à ce qu'il a coûté en cas et à la cause racine qui revient sans cesse.
• Prévision du volume : la tendance plus un indice par jour de la semaine, pour que le samedi ne soit pas projeté comme s'il était un mardi.

Une IA qui agit sur le ticket, sous une politique

L'IA lisait déjà chaque ticket (catégorie, urgence, sentiment, résumé) et personne n'en faisait usage. Elle peut désormais **écrire** la catégorie et la priorité dans le ticket, mais seulement sous une politique que l'espace de travail définit, et elle est **désactivée par défaut** : rien ne change tant que la personne qui administre ne l'active pas dans **Paramètres → IA du service**. Champ par champ, vous choisissez entre **Ne rien faire**, **Suggérer (une personne confirme)** et **Écrire quand elle est sûre**. L'écriture n'a lieu qu'au-dessus d'un seuil de confiance que vous fixez (de 50 % à 100 %, 80 % par défaut) ; en dessous, la même proposition devient une suggestion qui s'applique d'un clic.

Dans la console, l'encadré **Suggestions de l'IA** liste ce qui attend : la valeur proposée avec sa confiance et la raison pour laquelle elle n'a pas été écrite (la politique dit de seulement suggérer, en dessous du seuil, une personne avait déjà choisi une valeur, limite quotidienne atteinte), avec **Appliquer** et **Ignorer**. Ce que la politique a écrit d'elle-même reste visible dans l'historique de l'encadré comme écrit par la politique, pour que l'agent sache que la catégorie n'est pas de son fait. **Classer avec l'IA maintenant** exécute la même politique à la main. L'encadré disparaît pour un espace de travail qui n'a pas activé la politique et n'a aucune suggestion.

• L'IA classe d'après **vos propres** listes de catégories et de priorités. Une valeur qui n'est pas l'une de vos options n'est jamais écrite, et sans option enregistrée pour un champ, elle se tait au lieu d'en inventer une.
• Une valeur choisie par une personne n'est pas écrasée. Par défaut, le mode automatique ne remplit que ce qui est vide ou encore à la valeur par défaut du formulaire ; remplacer un choix humain exige l'option explicite **Autoriser l'IA à remplacer une valeur choisie par une personne**.
• Un brouillon de réponse n'est **jamais envoyé**. L'accepter le place dans l'éditeur avec **Utiliser dans l'éditeur** ; relire, modifier et envoyer restent de votre ressort. Résoudre et clôturer un ticket ne sont jamais automatiques non plus : il n'existe aucun mode pour cela, nulle part.
• Chaque écriture automatique compte dans la limite quotidienne d'actions partagée avec l'agent (**Paramètres → IA**, autonomie de l'agent). À la limite, l'IA se remet à seulement suggérer et le dit dans l'encadré et sur la page de la politique, avec les chiffres du jour : écrites, suggérées, retenues par la limite, en attente d'une personne.
• Tout laisse une trace : chaque écriture automatique dans le registre des actions de l'agent, chaque appel à l'IA dans le journal d'audit de l'IA quand ce journal est activé, et le changement de politique lui-même dans la piste d'audit.
• **Exécuter à la création d'un ticket** applique la politique sans aucune automatisation configurée. Une fois activé, créer un ticket depuis l'écran attend l'IA quelques secondes avant que le ticket n'apparaisse ; si l'IA est indisponible (pas de clé, plafond de dépense, fournisseur en panne), le ticket est créé quand même, sans rien d'écrit.
• Les automatisations de ticket et les règles temporelles ont gagné deux actions : **Classer avec l'IA (selon la politique d'IA du service)** et **Rédiger une réponse avec l'IA (jamais envoyée)**. Une règle qui fixe d'abord la catégorie puis sollicite l'IA ne voit pas l'IA la défaire.
• La même analyse du même texte ne produit jamais deux suggestions et ne compte jamais deux fois dans la limite ; répéter une exécution ne coûte rien.

Le travail de terrain depuis le ticket

Un ticket qui nécessite une visite ne se ressaisit plus sur un autre écran. Avec la verticale Services sur le terrain activée, l'encadré **Travail de terrain** de la console ouvre l'intervention directement depuis le ticket, planifie la visite et montre à l'agent ce que le client demande au téléphone : prochaine visite, si elle est en retard, dernière visite, technicien, équipement. Tout est lu en direct depuis l'intervention, ses visites et son historique de statut, de sorte qu'une modification faite sur le tableau de dépêche est ce que le ticket affiche à la prochaine ouverture. L'intervention reprend le sujet et la description du ticket comme problème, et la priorité du ticket transposée dans la sienne (critique devient urgente, haute reste haute, moyenne normale, basse basse).

**Ouvrir une intervention** demande le **bien**, qui est obligatoire parce que le ticket ne connaît pas l'adresse de la visite : les biens du client viennent en premier et marqués, un client qui n'a qu'un seul bien le voit présélectionné, et un ticket sans contact ni entreprise cherche dans toute la base par nom, adresse ou code postal (les 50 premiers, avec un avis pour affiner). Quand le ticket pointe vers un actif dont le numéro de série correspond à exactement un équipement de ce bien, l'équipement est **suggéré** avec une case à cocher, jamais choisi à votre place. Le type d'intervention (réparation par défaut), le technicien et le créneau d'arrivée sont facultatifs ; avec un créneau, la première visite est planifiée aussitôt et apparaît sur le tableau de dépêche ; sans créneau, l'intervention reste à l'état de brouillon, encore sans visite.

• **Planifier une visite** ajoute une visite à la même intervention depuis la console : un retour est la visite 2, 3 et ainsi de suite, jamais une seconde intervention. Un ticket a au plus une intervention, et un second clic sur ouvrir répond qu'elle existe déjà.
• Le créneau d'arrivée et le technicien de l'intervention elle-même ne sont remplis que s'ils étaient vides : une seconde visite ne réécrit pas ce qui avait été convenu pour la première.
• **Visite en retard** apparaît quand le créneau a commencé et que la visite est encore seulement planifiée, c'est-à-dire que personne n'est parti. Le sélecteur de changement de statut ne propose que les transitions que la machine à états de la verticale accepte depuis le statut actuel.
• Quand le travail de terrain est **terminé**, **n'a pas pu être terminé** ou a été **annulé**, le responsable du ticket est prévenu dans sa langue avec un lien vers la console, que le changement vienne de la console, de l'écran de la verticale ou de l'application. Dépêché, en route et en attente d'une pièce restent visibles dans l'encadré sans faire sonner personne.
• **Le statut du ticket ne change jamais tout seul** quand le terrain a terminé. Confirmer avec le client et résoudre le ticket est une décision de la personne qui traite la demande.
• **Dissocier** retire le lien entre le ticket et l'intervention et rien d'autre : l'intervention continue de vivre dans la verticale, avec sa propre trace. L'annuler est une transition de la verticale, effectuée là-bas.
• Une tâche de rappel à la date de la visite est facultative et réutilise le module d'activités ; elle apparaît dans la chronologie du ticket et dans la liste de tâches du technicien, ou dans celle du responsable du ticket quand il n'y a pas de technicien.
• Quand la verticale est désactivée, l'encadré le dit et renvoie vers **Paramètres · Verticals**, au lieu d'afficher un bouton qui échouerait. Il propose le chemin léger dont dispose tout espace de travail, **Ouvrir plutôt un ordre de service**, et affiche cet ordre et ses rendez-vous quand il en existe un.

Où configurer : **Paramètres → Textes rapides** pour les phrases toutes prêtes, **Paramètres → Modèles d'e-mail du ticket** pour les textes transactionnels, et **Paramètres → Compétences** pour qui sait quoi et ce que chaque file exige. Le swarm, la relance et les onglets de travail ne demandent aucune configuration : ils sont déjà dans la console.

Ouvrir cet article dans le système →