Manuel

Chaque fonction pas à pas, avec des captures d'écran d'un système en fonctionnement. L'interface sur les images tourne en anglais, la langue de base du produit.

Les captures d'écran proviennent de la version 1.3.1. Rien n'a changé sur les écrans montrés jusqu'à la version 1.13.3. La seule chose qui a un autre aspect est le numéro de version en bas de la barre latérale.

Personnalisation et administration

C'est ici que tu gères les paramètres de langue du système et que tu appliques le logo et les couleurs de ton entreprise. Tu définis le format de date et d'heure, et tu informes tout le monde des maintenances prévues et des pannes. Ce bloc couvre aussi les tâches rares dont tu as ensuite vraiment besoin : une mise à jour, une archive, une alerte avant que le disque soit plein. Tout ici fait partie de Basic, sauf l'envoi de l'annonce par e-mail.

1

Activer des langues et les traduire toi-même

Sous « Settings → Language Settings », tu choisis les langues que ton entreprise propose. Il y en a 30 au choix.

L'anglais est toujours activé et ne peut pas être désactivé. C'est la langue vers laquelle le système se replie quand un texte n'a pas encore de traduction.

Ensuite, chaque utilisateur choisit dans son propre menu la langue dans laquelle il travaille, parmi celles que tu as activées.

Les traductions n'arrivent pas avec une mise à jour. Une mise à jour apporte de nouveaux textes anglais, et c'est toi qui en fournis la traduction.

Cela se fait en deux étapes. Avec « Export JSON », tu télécharges un fichier qui contient chaque texte anglais à côté de ta traduction existante.

Tu remplis ce fichier à ton rythme et tu le recharges avec « Import JSON ». Les champs vides sont ignorés, les traductions existantes sont remplacées.

Les variables comme {count} doivent survivre dans la traduction. Une entrée dont les variables diffèrent du texte anglais est refusée, et cela vaut aussi pour une variable en trop. La traduction précédente reste alors active. L'anglais n'apparaît que s'il n'y en avait aucune. Le système te dit de quelle entrée il s'agissait.

La carte « State of your language packs » te dit, pour chaque langue, où tu en es. Chaque langue que tu as activée y apparaît, même sans traduction. La carte montre combien de textes sont traduits et distingue quatre cas : obsolète, non traduit, inconnu et complet. « Unknown » signifie que les textes ont été importés avant que ce contrôle existe. La prochaine importation règle la question.

« Obsolète » est le cas qui compte. Le texte anglais a changé, ta traduction est toujours là et dit maintenant autre chose.

Des packs de langue prêts à l’emploi pour chaque langue sont disponibles gratuitement sur notre page « Téléchargements ». Tu les charges avec « Import JSON », comme ton propre fichier. Tu peux aussi modifier le fichier au préalable pour améliorer une traduction.

Dans l’application, le lien « Download language packs » de la carte « Import translations » t’amène directement sur cette page.

La carte « Languages » avec les langues sous forme de boutons, l'anglais activé de façon définitive.
Le cadre rouge entoure l'allemand et « Save languages ». L'anglais porte la mention « Always active ».Ouvrir l'image en taille réelle
La carte « Export translations » avec le sélecteur de langue cible.
Choisis d'abord la langue cible, puis télécharge. Le fichier contient le texte anglais et ta traduction existante.Ouvrir l'image en taille réelle
La carte « Import translations » avec le fichier choisi.
Après « Select file », le nom du fichier apparaît à côté. Seul « Import JSON » le charge.Ouvrir l'image en taille réelle
La carte « State of your language packs » avec l'état de l'allemand.
Dans cet exemple, le paquet allemand est complet. Le second nombre augmente à chaque mise à jour qui apporte de nouveaux textes.Ouvrir l'image en taille réelle
2

Logo, favicon et couleurs

Sous « Settings → CI Settings », tu définis ton logo, ton favicon et trois couleurs.

Le logo apparaît dans la barre latérale, sous le logo du système. La taille recommandée est de 400 sur 160 pixels, en PNG ou en SVG avec un fond transparent, 2 Mo au maximum. Un fichier SVG qui contient un script est refusé à l'envoi. Si un envoi échoue, le message en donne la raison.

Le favicon est la petite image dans l'onglet du navigateur. Le format recommandé est le SVG ou 64 sur 64 pixels.

Les trois couleurs sont « Primary color », « Accent color » et « Background color ». La première peint les boutons importants, la deuxième les icônes et les mises en avant, la troisième l'arrière-plan.

Le système calcule lui-même les couleurs du texte et du survol pour que le texte reste lisible. Tu ne fournis que les trois couleurs de base.

Un champ vide signifie que la couleur intégrée s'applique. Le carré à côté apparaît alors en noir, parce qu'il ne peut pas montrer « aucune couleur ». La remarque en dessous le précise.

L'aperçu sous les champs montre tes couleurs avant l'enregistrement. Seul « Save » les applique pour tout le monde.

« Restore defaults » remet tout en place. Cela supprime aussi le logo et le favicon envoyés.

La carte « Colors » avec deux couleurs définies et l'aperçu en dessous.
Le cadre rouge entoure les deux boutons d'aperçu. Ils montrent tout de suite les couleurs que tu as saisies.Ouvrir l'image en taille réelle
Le logo de l'entreprise dans la barre latérale, sous le logo du système.
Le cadre rouge entoure le logo envoyé. Il apparaît aussitôt et sur toutes les pages.Ouvrir l'image en taille réelle
3

Clair et sombre, et l'affichage sur un téléphone

Le système existe en version sombre et en version claire. Tu changes dans ton propre menu, en bas de la barre latérale.

Le choix appartient à chaque utilisateur et est mémorisé. Un agent peut travailler en clair pendant qu'un collègue travaille en sombre.

Le même menu contient ta disponibilité, ta photo de profil, ton mot de passe et ta langue.

Sur un écran étroit, l'interface se réorganise. Le tableau devient une pile de cartes, et la barre latérale se replie derrière l'icône en haut à gauche.

Il n'y a pas d'application séparée. L'adresse est la même que sur l'ordinateur, et tu te connectes de la même façon.

Le menu personnel avec les entrées « Light mode » et « Dark mode ».
Le cadre rouge entoure « Light mode ». La coche à côté montre quel aspect est actif.Ouvrir l'image en taille réelle
La liste des tickets dans l'aspect clair.
L'aspect clair est le réglage d'usine.Ouvrir l'image en taille réelle
La même liste des tickets dans l'aspect sombre.
La même page, les mêmes données. Seule l'apparence change.Ouvrir l'image en taille réelle
La même page dans une fenêtre étroite, comme sur un téléphone.
Sur un téléphone, la liste est empilée. Tu ouvres la barre latérale avec l'icône en haut à gauche.Ouvrir l'image en taille réelle
4

Les dates et les heures écrites comme chez toi

Avant de commencer : Les administrateurs et les agents peuvent modifier les paramètres généraux. Tous les autres lisent les dates telles qu'elles sont réglées là.

Sous « Settings → General Settings », tu trouves la carte « Date and time format ». Elle se situe juste après le fuseau horaire.

Quatre choix composent la façon d'écrire une date. « Date order » est l'ordre du jour, du mois et de l'année.

« Date separator » est le caractère entre les nombres. Tu peux choisir le point, la barre oblique ou le trait d'union.

« Clock » est l'affichage de l'heure : 24 heures, ou 12 heures avec AM et PM. « Time separator » est le caractère entre l'heure et les minutes.

Sous les quatre champs, tu vois « This is how it looks ». Cela montre le résultat avant que tu cliques sur « Save ».

Le réglage s'applique à toute l'installation. Il ne dépend ni de la langue ni de chaque utilisateur.

C'est voulu. Une entreprise écrit les dates d'une seule façon, et chaque collègue lit la même écriture.

Le réglage d'usine est jour, mois, année avec un point et l'affichage sur 24 heures. Si tu ne changes rien, rien ne change.

L'écriture choisie s'applique partout où le système montre une date. Cela vaut pour le ticket, les listes, le suivi et le temps saisi.

Les exports ne sont pas concernés. Ils écrivent une date sous la forme 2026-08-22, parce que les tableurs lisent cette forme de façon fiable.

Les champs dans lesquels tu saisis une date suivent eux aussi ce réglage. Un clic sur le champ ouvre un calendrier, et la date choisie apparaît ensuite dans ta forme d'écriture. Un champ vide affiche « Pick a date ».

Plus à ce sujet dans la carte : Activer des langues et les traduire toi-même

La carte « Date and time format » avec les quatre sélecteurs et l'aperçu.
Le cadre rouge entoure l'ordre et l'aperçu. Les exemples dans les sélecteurs suivent l'ordre choisi.Ouvrir l'image en taille réelle
Les détails du ticket dans le réglage d'usine : jour, mois, année et affichage sur 24 heures.
Voilà un ticket tant que rien n'est changé. En haut se trouvent des instants, en bas les jours du temps saisi.Ouvrir l'image en taille réelle
Les mêmes détails après le passage à mois, jour, année avec l'affichage sur 12 heures.
Le même ticket après le changement. Les jours saisis suivent le réglage tout comme les instants au-dessus.Ouvrir l'image en taille réelle
5

Annoncer une maintenance ou une panne

Avant de commencer : L'annonce sur la page de connexion fait partie de Basic. L'envoyer aussi par e-mail fait partie de Professional.

La page « Maintenance and incident notices » se trouve dans la barre latérale. Tu y écris une annonce que tout le monde voit.

L'annonce apparaît sur la page de connexion et dans tout le système. Les gens la lisent donc avant même de se connecter.

Le but est d'éviter des tickets inutiles. Celui qui lit que le réseau est en panne ne le signale pas une fois de plus.

Tu composes le texte en cliquant. Clique d'abord le champ que tu veux remplir. Il reçoit un cadre rouge, et tout ce que tu coches ensuite y est inséré. Décoche un bloc et il ressort du texte.

« Title / Subject » s'affiche en haut de l'annonce. « Body » s'affiche en dessous. Si tu envoies l'annonce par e-mail, l'un devient l'objet et l'autre le corps du message.

Des phrases toutes faites sont disponibles comme éléments de construction. Tu peux ajouter les tiennes sous « Text Modules » et tes systèmes et services sous « Systems / Services ».

Avec « Calendar (add date) » et « Time (add time) », tu insères une date et une heure. C'est ainsi qu'on annonce une maintenance planifiée.

L'interrupteur « Turn notification on/off » en haut active l'annonce et la désactive. L'activer enregistre en même temps le titre et le texte. L'annonce reste affichée jusqu'à ce que tu la désactives. Si l'annonce est déjà active, une modification du texte ne prend effet qu'avec « Save ».

Il existe un second type d'annonce à côté. Si tu transformes un ticket en incident collectif, elle apparaît aussi sur la page de connexion et disparaît d'elle-même dès que le ticket est résolu. Cet interrupteur ne s'y applique pas.

Avec « Send as E-Mail », tu envoies en plus le même texte à une liste d'adresses. C'est la partie qui appartient à Professional.

Tu écris l'annonce en anglais. Sa traduction arrive par la page des langues, comme tout autre texte. Si tu modifies ensuite le texte anglais, la traduction importée ne s'applique plus. Il faut la réimporter.

Plus à ce sujet dans la carte : L'incident collectif comme bannière et comme remarque dans la réponse automatique

La carte avec les éléments de texte et tes propres systèmes.
Les cadres rouges entourent les deux lignes de saisie : l'une pour les phrases, l'autre pour tes propres systèmes. Dans cet exemple, les systèmes sont l'e-mail, un serveur de fichiers et le VPN.Ouvrir l'image en taille réelle
Le titre et le corps avec des éléments cochés, le champ « Body » est actif.
Le cadre rouge entoure le champ actif et « Calendar (add date) ». Sous le champ, il est indiqué lequel est actif.Ouvrir l'image en taille réelle
La page de connexion avec l'annonce activée, sur toute la largeur.
Voilà comment un client la lit avant de se connecter. « Dismiss » masque les annonces affichées à ce moment jusqu'au rechargement de la page.Ouvrir l'image en taille réelle
Le même texte avec « Send as E-Mail » coché et la liste des destinataires.
Le cadre rouge entoure la liste des destinataires et « Send Mail ». Sépare plusieurs adresses par une virgule.Ouvrir l'image en taille réelle
6

Alerte précoce avant que le disque soit plein

Le système surveille l'espace disque du serveur et se manifeste avant qu'il ne manque.

Il y a deux niveaux. À partir de 90 pour cent utilisés, tu reçois une information ; à partir de 95 pour cent, un avertissement.

Celui qui gère les mises à jour voit les chiffres et ce qu'il faut faire. Le plus gros poste est en général constitué des anciennes images des mises à jour précédentes.

Tous les autres utilisateurs connectés reçoivent une phrase courte et un renvoi vers leur administrateur. Ils ne la voient qu'à partir du niveau d'avertissement.

Rien de tout cela n'apparaît sur la page de connexion. Le taux de remplissage d'un disque serveur ne regarde personne avant la connexion.

Un disque plein ne touche pas que la mise à jour. Les pièces jointes, le courrier entrant, la base de données et la sauvegarde se trouvent tous sur le même disque.

Tu reçois aussi une information dès qu'il reste moins de 10 Go de libre. Une mise à jour a besoin de cet espace et ne démarre pas avec moins.

Après chaque mise à jour réussie, le système supprime les images des versions plus anciennes. La version précédente est conservée pour un retour en arrière.

La bannière avec l'information que la place devient rare.
Le premier niveau. Dans cet exemple, 93 pour cent sont utilisés et 14 des 200 Go sont libres.Ouvrir l'image en taille réelle
La même bannière avec le texte du niveau d'avertissement.
Le deuxième niveau à 96 pour cent. Le texte nomme maintenant aussi ce qui peut commencer à échouer.Ouvrir l'image en taille réelle
Le même événement dans la fenêtre d'un agent : une phrase courte sans chiffres.
Les personnes qui ne peuvent pas libérer d'espace ne reçoivent aucun chiffre. La phrase nomme la conséquence et renvoie à l'administrateur.Ouvrir l'image en taille réelle
7

Mise à jour en appuyant sur un bouton

Sous « Settings → Updates », tu vois quelle version tourne et s'il en existe une plus récente.

S'il y a une nouvelle version, ce qu'elle apporte est listé en dessous. La liste montre chaque version que tu sautes.

Avant la mise à jour, le système vérifie qu'il y a assez d'espace libre. Une mise à jour a besoin de l'ancienne et de la nouvelle image en même temps, elle demande donc 10 Go. S'il n'y en a pas assez, le système refuse la mise à jour et dit pourquoi. C'est une meilleure nouvelle que d'abandonner à mi-chemin.

Ensuite, il fait une sauvegarde chiffrée tout seul. Elle couvre la base de données, les pièces jointes, les archives et les clés. Si la base de données tourne en dehors de SMITEY, elle ne fait pas partie de cette sauvegarde.

Si la sauvegarde échoue, la mise à jour s'arrête avant que quoi que ce soit ne change. Une base de données en dehors de SMITEY ne retarde pas la mise à jour. Sauvegarde-la avec tes propres outils.

Le système demande avant de commencer. Pendant la mise à jour, il est injoignable pendant quelques minutes, choisis donc un moment calme.

Si quelque chose se passe mal, le système revient à la version précédente et continue de tourner.

Si ton serveur ne peut pas joindre la source de mise à jour, le système le dit exactement. Il ne prétend pas alors que tu es à jour.

Une mise à jour qui fait passer la base de données à une nouvelle version ne s'applique pas en appuyant sur un bouton. Le système te le dit, et les notes de version indiquent quoi faire.

La carte « Version status » indiquant que le système est à jour.
Le cadre rouge entoure le message. « Check now » interroge tout de suite au lieu d'attendre la prochaine vérification.Ouvrir l'image en taille réelle
La même carte avec une version disponible et ses notes de version.
Le cadre rouge entoure « Install update ». Au-dessus figure ce qu'apporte la nouvelle version.Ouvrir l'image en taille réelle
La confirmation demandée avant le démarrage de la mise à jour.
La question nomme la version et précise qu'une sauvegarde est faite d'abord.Ouvrir l'image en taille réelle
La même carte quand la source de mise à jour ne peut pas être jointe.
Le cadre rouge entoure le message. Sans réponse, le système dit qu'il ne sait pas.Ouvrir l'image en taille réelle
8

Archiver les tickets fermés

Avant de commencer : « Delete from live DB » retire définitivement les tickets de la base de données en fonctionnement. Télécharge d'abord l'archive et regarde ce qu'elle contient.

Sous « Settings → Archive », tu empaquettes dans un fichier les tickets fermés d'une période. Cela garde l'ensemble de travail réduit.

Seuls les tickets fermés partent. Un ticket résolu n'en fait partie qu'une fois fermé. Cela se fait tout seul 24 heures après sa résolution. Un ticket ouvert dans la même période reste où il est.

« Preview » te dit à l'avance combien de tickets la période couvre. Cela n'écrit rien et ne change rien.

« Create archive » construit un fichier ZIP. Il contient les tickets avec leurs commentaires, leur historique, leurs champs personnalisés et leurs pièces jointes.

Le fichier figure ensuite dans la liste en dessous, avec la période, le nombre et la taille. Un sous-dossier est possible si tu veux classer par année.

C'est seulement alors que tu décides si les tickets quittent la base de données en fonctionnement. C'est une étape à part : « Delete from live DB » dans la liste « Existing archives ». Créer l'archive ne change rien en soi.

« Restore » ramène les tickets depuis le fichier. Les tickets dont le numéro existe déjà sont ignorés.

Une restauration a besoin des équipes et des workflows auxquels un ticket se rapporte. Ensuite, le système indique combien de tickets sont revenus et combien il en a ignoré parce qu'ils existaient déjà. Il nomme aussi les participations d'équipes ignorées et les tâches sans leur sous-ticket. Les autres manques ne sont pas signalés. Une équipe, une catégorie, un utilisateur ou un statut manquant reste vide sur le ticket. Les commentaires sans leur utilisateur et les valeurs de champs personnalisés supprimés sont laissés de côté.

« Delete archive file » ne supprime que le fichier. Les tickets de la base de données en fonctionnement ne sont pas touchés.

La carte « Create archive » avec les deux champs de date.
Le cadre rouge entoure la période. Le sous-dossier est facultatif.Ouvrir l'image en taille réelle
La même carte avec le résultat de l'aperçu.
Le cadre rouge entoure « Preview ». Le nombre à côté compte les tickets fermés de la période choisie. L'aperçu ne change rien.Ouvrir l'image en taille réelle
La liste des archives avec la période, le nombre, les pièces jointes et la taille.
Le cadre rouge entoure les deux actions qui touchent aux données en fonctionnement.Ouvrir l'image en taille réelle
La question posée avant que les tickets quittent la base de données en fonctionnement.
La question précise que cette étape ne peut pas être annulée.Ouvrir l'image en taille réelle
9

Remplir tes listes déroulantes à partir d'un fichier

Sous « Settings → General Settings », tu trouves les listes déroulantes du système. Chaque liste a son propre onglet.

Pour les départements, les postes et les sites, il y a aussi la voie du fichier. Elle est payante quand tu ajoutes beaucoup d'entrées d'un coup.

« Export JSON » télécharge la liste. Sur une installation neuve, cela te donne la structure vide dans laquelle écrire tes entrées.

Le fichier contient un exemple qui montre à quoi ressemble une entrée. Il est ignoré quand tu recharges le fichier.

« Import JSON » crée ce qui manque. Les entrées existantes ne sont pas touchées. Un nom qui apparaît deux fois dans le fichier n'est créé qu'une fois.

Renommer ne passe pas par le fichier. Les champs de cette page sont là pour cela, et la remarque en rouge le précise. L'emplacement de remplacement « None selected or available » ne peut pas être renommé. Tu le traduis seulement, sur la page des langues.

Tu traduis les entrées ensuite sur la page des langues. Le fichier contient le nom anglais.

Les catégories fonctionnent de la même façon. Elles appartiennent à une équipe, elles se trouvent donc sur la page des catégories de cette équipe.

Plus à ce sujet dans la carte : Les catégories principales et les sous-catégories sont librement configurables par équipe

L'onglet « Department » avec les boutons d'export et d'import.
Le cadre rouge entoure les deux boutons. La phrase en rouge au-dessus met en garde contre le fait de renommer par le fichier.Ouvrir l'image en taille réelle
Le fichier téléchargé dans le navigateur, avec l'exemple et les entrées.
À part un court en-tête et l'exemple, le fichier ne contient que des noms. C'est pourquoi n'importe quel éditeur de texte peut le modifier.Ouvrir l'image en taille réelle

Équipes et utilisateurs

Une équipe est une responsabilité, pas un dossier. Elle a ses propres catégories, ses propres délais et ses propres membres. Un client en voit exactement une. Tout le reste revient à savoir qui possède quel compte et ce que ce compte a le droit de faire.

1

Créer et configurer des équipes

Les équipes se trouvent sous « Settings → Teams ». La liste est à gauche, les réglages de l'équipe sur laquelle tu as cliqué sont à droite. Le nombre derrière le nom est le nombre de ses membres.

Une nouvelle équipe reçoit son nom dans le champ « Team name ». En dessous, « Copy categories from » permet de choisir une équipe existante, pour que la nouvelle équipe démarre avec les mêmes catégories principales et sous-catégories. « Create team » la crée.

La première équipe est celle que tes clients voient. Chaque équipe suivante est une équipe spécialisée derrière elle. Demander à une personne qui signale de choisir elle-même le bon département est trop lui demander : elle dépose auprès de la première équipe, et c'est transmis à partir de là.

Tu peux changer cela à tout moment. La carte « Customer permissions » décide, par équipe, ce que les clients peuvent y faire. Elle a deux interrupteurs : « Can create new tickets and see their own tickets » et « Can see their own tickets of this team in the dashboard and in reports ». Dès que l'un d'eux est activé, les clients voient l'équipe. Ce n'est qu'avec les deux désactivés que l'équipe n'apparaît pas du tout pour un client.

La carte « Agent Permissions » s'applique aux agents de cette équipe. Elle a trois interrupteurs : gérer les tickets, gérer les catégories et voir les rapports de cette équipe. Sans le premier, un agent ne peut ni créer, ni modifier, ni commenter des tickets dans cette équipe, ni envoyer de pièces jointes. Sans le deuxième, l'entrée des catégories de l'équipe disparaît de sa barre latérale. Sans le troisième, les rapports laissent cette équipe de côté. Chaque changement est consigné dans l'« Audit log » de l'équipe.

La carte « Agents » contient les membres. Malgré le titre, les clients de l'équipe s'y trouvent également. Le sélecteur au-dessus et « Add Agent » ajoutent quelqu'un, « Remove » le retire. Celui qui est ajouté ou retiré doit se déconnecter et se reconnecter une fois.

« Default e-mail language » est la langue dans laquelle cette équipe écrit. Elle s'applique quand une règle de messagerie choisit « Team default language ».

L'interrupteur « Active » met une équipe hors service. Elle disparaît de la barre latérale et de tous les sélecteurs. Elle n'est pas supprimée pour autant.

« Delete » ne supprime une équipe que si aucun ticket n'est encore ouvert. Sinon, le système nomme la raison et ne fait rien.

La carte « Audit log » consigne chaque changement de l'équipe, avec le nom et l'heure.

Basic fonctionne avec une seule équipe. Professional n'a pas de limite.

La page « Teams » avec la liste des deux équipes à gauche et les réglages du Helpdesk à droite.
Les cadres rouges entourent les deux équipes. Cliquer sur l'une change ce qui s'affiche à droite. Le nombre au bord est le nombre de membres.Ouvrir l'image en taille réelle
Le champ « Team name » avec un nom saisi, en dessous « Copy categories from » et le bouton « Create team ».
Saisis le nom, reprends éventuellement les catégories d'une équipe existante, puis « Create team ».Ouvrir l'image en taille réelle
Les cartes « Customer permissions » et « Agent Permissions » avec leurs interrupteurs.
Les cadres rouges entourent les deux titres. Ces interrupteurs ne s'appliquent qu'à cette seule équipe.Ouvrir l'image en taille réelle
La carte « Agents » avec le sélecteur, le bouton « Add Agent » et les membres en dessous.
Le cadre rouge entoure « Add Agent ». La pastille à côté de chaque nom est le rôle, et la carte contient aussi les clients de l'équipe.Ouvrir l'image en taille réelle
La carte « Audit log » avec ses entrées, chacune avec la modification, le nom et l'heure.
Le cadre rouge entoure le titre. Chaque ligne nomme le changement, qui l'a fait et quand.Ouvrir l'image en taille réelle
2

Créer des administrateurs et des agents

Les comptes se trouvent sous « User management ». La liste montre le nom et le nom de connexion, l'adresse e-mail, l'équipe avec le département en dessous, et le rôle.

« New user » ouvre le formulaire. Le prénom, le nom, le nom de connexion et l'adresse e-mail sont obligatoires. À cela s'ajoute un mot de passe. Avec Professional, tu peux cocher à la place la case « Send login details by e-mail ».

Avec cette case, tu ne définis aucun mot de passe. Le nouvel utilisateur reçoit un message avec son nom de connexion et un lien à durée limitée, et définit lui-même son mot de passe. Le système n'envoie jamais de mots de passe.

Le rôle décide de tout le reste. « Admin » et « Agent » sont tous deux du personnel et comptent dans le même quota. Un administrateur peut faire plus au départ. Presque chaque autorisation individuelle peut être modifiée ; les exceptions figurent sur la carte « Les rôles et le concept d'autorisations ». Seul un administrateur peut donner ou retirer le rôle « Admin ». Cela vaut aussi pour son propre compte. « Edit user » ne change que l'équipe affichée dans le formulaire. Les équipes auxquelles la personne a été ajoutée avec « Add Agent » restent telles quelles.

Basic est livré avec deux places de personnel. La répartition dépend de toi : un administrateur et un agent, ou deux administrateurs. Les clients ne comptent pas, ils sont illimités dans les deux éditions.

Quand quelqu'un part, clique sur le symbole d'archive dans sa ligne. Le compte est verrouillé, la personne ne peut donc plus se connecter.

Un compte verrouillé passe dans la vue « Archived » et y porte la pastille « locked ». Il n'est plus visible dans la vue « Active ».

Un compte verrouillé n'occupe plus de place de personnel et n'apparaît dans aucun sélecteur « Assign to ». Les tickets déjà attribués gardent leur agent et le nom de leur agent.

Dans la vue « Archived », le même bouton s'appelle « Restore » et libère de nouveau le compte. Dans Basic, cela demande encore une place libre.

Le symbole de la clé réinitialise un mot de passe. Le bouclier barré réinitialise la connexion à deux facteurs. Le nouveau mot de passe est alors affiché une seule fois à l'écran. Il n'est envoyé nulle part.

Réinitialiser le mot de passe ou la connexion à deux facteurs ne lève que le court verrouillage après des tentatives ratées. Un compte archivé reste verrouillé. Il ne reçoit ni invitation ni courrier de réinitialisation, et seul « Restore » le fait revenir.

L’archivage peut être annulé à tout moment. Si quelqu’un est parti pour de bon, supprime aussi le compte avec le symbole de corbeille « Delete account ». Le délai jusqu’à l’anonymisation automatique ne court qu’à partir de la suppression.

Plus à ce sujet dans la carte : Anonymiser des personnes

La page « User management » avec tous les comptes, leur rôle et les actions de chaque ligne.
Les cadres rouges entourent « New user » et le passage entre comptes ouverts et comptes verrouillés. Le bouton montre laquelle des deux vues est ouverte.Ouvrir l'image en taille réelle
La boîte de dialogue « Create new user » avec les noms, le nom d'utilisateur et l'e-mail remplis, et les sélecteurs d'équipe, de département, de poste, de site et de rôle.
Les cadres rouges entourent le rôle et l'invitation. Le rôle est le seul sélecteur qui doit être rempli.Ouvrir l'image en taille réelle
La même boîte de dialogue avec la case cochée : le champ du mot de passe est désactivé et indique que l'utilisateur le définit par le lien.
Avec la case cochée, l'astérisque du champ de mot de passe disparaît. Le champ lui-même indique qui définit le mot de passe.Ouvrir l'image en taille réelle
La vue « Archived » avec un compte verrouillé, la pastille « locked » et l'icône de restauration en fin de ligne.
Les cadres rouges entourent la pastille et le chemin du retour. Les deux n'existent que dans cette vue.Ouvrir l'image en taille réelle
3

Clients : les comptes des personnes qui signalent

Les clients sont illimités dans Basic comme dans Professional. Ils n'occupent aucune place de personnel.

Un compte client naît de trois façons. Tu le crées toi-même sous « User management » ; avec Professional, tu peux en même temps inviter la personne par courrier électronique. La deuxième voie est l'inscription libre. La troisième est la première connexion par SSO ou par un annuaire, qui crée le compte toute seule.

L'interrupteur correspondant se trouve sous « Settings → Security » dans la carte « Self-registration ». Il est désactivé au départ. Une fois activé, un lien « Register » apparaît sur la page de connexion.

Celui qui s'inscrit lui-même reçoit toujours le rôle « Customer ». Aucun autre rôle ne peut être attribué par cette voie.

Avec Professional, un client issu de l'inscription libre reçoit un deuxième e-mail après celui de bienvenue. Avec le lien qu'il contient, il confirme son adresse. Jusque-là, son compte porte la mention « not confirmed » dans la liste.

Tu peux aussi confirmer une adresse toi-même. Dans Basic, c'est la seule voie, car Basic n'envoie aucun courrier électronique. La ligne du compte affiche alors un bouton avec une icône d'enveloppe : « Mark email as confirmed ». Ne le fais que si tu sais que l'adresse appartient à la personne.

Pour un helpdesk interne, mieux vaut ne pas toucher à cet interrupteur. Sinon, quiconque connaît l'adresse crée un compte.

Un client ne voit que ses propres dossiers. Ce sont les tickets qu'il a créés lui-même. S'y ajoutent les tickets qu'un agent ou un e-mail a créés pour son adresse confirmée. Un ticket qu'un autre client crée avec son adresse lui reste caché. Si deux comptes ont la même adresse, les deux voient ces tickets.

Si son adresse n'est pas encore confirmée, un avis apparaît au-dessus de sa liste de tickets. Avec « Send confirmation email », il redemande le lien. L'avis n'apparaît que si le système peut envoyer du courrier électronique.

Sa barre latérale est courte : ses tickets, un nouveau ticket, la base de connaissances. Il ne voit jamais aucun paramètre. Si l'interrupteur de l'équipe « Can see their own tickets of this team in the dashboard and in reports » est activé, sa barre latérale contient aussi le tableau de bord et les rapports.

Ce qu'il a le droit de faire dans une équipe se règle sur l'équipe. Ce n'est qu'avec les deux interrupteurs clients désactivés que cette équipe n'existe pas pour lui.

La carte « Self-registration » avec l'interrupteur et la remarque en dessous.
Le cadre rouge entoure l'interrupteur. Le texte à côté dit ce qu'il fait et ce qui se passe sans envoi de courrier électronique.Ouvrir l'image en taille réelle
Le même système, connecté en tant que cliente : une barre latérale courte et une liste de tickets qui ne contient que ses propres dossiers.
La colonne « User » contient le même nom à chaque ligne. Une cliente ne voit rien qui ne soit à elle, et les paramètres manquent dans la barre latérale.Ouvrir l'image en taille réelle
4

Export des données d’une personne

Avant de commencer : Tu as besoin de l’autorisation « Data export (data subject request) ». Par défaut, seuls les administrateurs l’ont.

Une personne peut te demander quelles données tu conserves sur elle. L’export de données les rassemble toutes dans un fichier ZIP.

Tu le lances sous « User management ». Chaque ligne a un symbole de fichier avec une flèche et l’indication « Export personal data ». Il ouvre l’export de ce compte.

Certaines personnes n’ont pas de compte. Elles t’ont seulement écrit, ou un agent a créé un ticket avec leur adresse. Pour elles, il y a « Export by e-mail address » en haut de la page. Saisis-y l’adresse et clique sur « Search ». La recherche fonctionne avec un compte ou une adresse, jamais avec un nom.

Une recherche par adresse trouve moins qu’une recherche par le compte. Elle ne trouve que les endroits où l’adresse elle-même est enregistrée, par exemple comme demandeur d’un ticket ou comme expéditeur d’un e-mail. Une recherche par le compte trouve en plus tout ce qui est rattaché au compte. Si l’adresse appartient à un compte, la boîte de dialogue le dit et propose « Use this account ». Ensuite, elle affiche le nom de la personne et l’adresse e-mail du compte.

Avant que tu ne télécharges quoi que ce soit, la boîte de dialogue montre ce qu’elle a trouvé, compté par domaine. Les domaines sont par exemple les tickets, les entrées de temps, les enquêtes de satisfaction et le journal de sécurité. Si elle ne trouve rien, elle affiche « No data found for this person. » et ne propose aucun téléchargement. Si l’adresse appartient à un compte et n’a pas de résultats propres, la boîte de dialogue n’affiche aucun résultat et ne propose aucun téléchargement. Elle affiche l’encadré avec « Use this account ». Les administrateurs voient en plus la zone « Anonymize » en dessous. La carte « Anonymiser des personnes » l’explique.

« Download » crée le fichier ZIP. Il contient un fichier JSON par domaine, pour que les données soient lisibles par une machine. Les fichiers de toutes les pièces jointes trouvées l’accompagnent. « overview.html » présente le contenu principal sous une forme lisible. Chaque ticket y indique pourquoi il est inclus (« Why this ticket is included »). « README.txt » s’adresse à la personne et explique ce que contient le fichier.

Un ticket qui concerne la personne est repris en entier. Cela comprend les commentaires et les modifications d’autres personnes. Les notes internes sont également incluses et marquées comme internes. Si la personne a répondu par e-mail au ticket de quelqu’un d’autre, ce ticket porte la marque « Replied by e-mail to someone else’s ticket ». Un ticket sur lequel la personne a fait la dernière modification est également repris. Sa ligne « Why this ticket is included » indique alors « Last person to change the ticket ».

Vérifie donc l’export avant de le transmettre. Masque les données d’autres personnes là où c’est nécessaire. La boîte de dialogue te le rappelle. Le « README.txt » ne contient pas cette remarque, car il est destiné à la personne.

Les tickets déplacés dans une archive ne sont pas parcourus. Vérifie tes archives séparément. La boîte de dialogue te le rappelle aussi.

Les mots de passe et les clés de la connexion à deux facteurs ne font pas partie de l’export.

Chaque téléchargement est enregistré : qui l’a lancé, pour quelle personne et quand. L’enregistrement ne contient rien du contenu de l’export. La recherche qui précède n’est pas enregistrée.

Un agent qui reçoit l’autorisation a aussi besoin de « Users: manage accounts ». Sans elle, il n’atteint pas la page « User management ». L’autorisation ne peut jamais être donnée au rôle « Customer ».

La zone « Survey consents and unsubscribes » contient chaque consentement et chaque désabonnement pour l'enquête de satisfaction, avec la date, le canal et le ticket. « overview.html » montre l'historique complet dans une section à part. Si la personne a été anonymisée après un désabonnement, l'export par son adresse trouve le désabonnement restant. La colonne « E-mail address » indique alors « Anonymized (address removed) ».

Plus à ce sujet dans la carte : Anonymiser des personnes

La page « User management » avec le bouton « Export by e-mail address » en haut et le symbole de fichier avec une flèche dans chaque ligne.
Les cadres rouges entourent « Export by e-mail address » et le symbole dans la ligne de Julia Becker. Les deux ouvrent la même boîte de dialogue.Ouvrir l'image en taille réelle
La boîte de dialogue « Export personal data » pour Julia Becker avec son adresse e-mail sous le nom, la liste des résultats par domaine, les deux remarques sur la vérification et les archives, la zone « Anonymize » et le bouton « Download ».
Les cadres rouges entourent la liste des résultats et « Download ». La liste ne nomme que les domaines où quelque chose a été trouvé.Ouvrir l'image en taille réelle
La même boîte de dialogue après une recherche par adresse : elle nomme le compte auquel l’adresse appartient et propose « Use this account ».
Le cadre rouge entoure « Use this account ». Avec la seule adresse, la recherche ne trouve rien ici. C’est pourquoi la boîte de dialogue n’affiche aucun résultat ni « Download ». L’export du compte trouve les tickets de Julia Becker. Seuls les administrateurs voient la zone « Anonymize » en dessous.Ouvrir l'image en taille réelle
5

Anonymiser des personnes

Avant de commencer : Seul un administrateur peut anonymiser une personne. Une anonymisation ne peut pas être annulée.

Certaines données ne doivent pas rester pour toujours. Quand quelqu’un quitte ton entreprise ou qu’une personne demande l’effacement de ses données, tu l’anonymises. Le nom et l’adresse e-mail sont alors remplacés par une valeur de substitution comme « Anonymized user 3 ». Les tickets restent. Les rapports, les délais, les saisies de temps et les chiffres de satisfaction continuent de compter.

Chaque personne reçoit son propre numéro. Deux entrées avec le même numéro viennent de la même personne. L’adresse e-mail devient « anonymized-3@anonymized.invalid ». Aucun e-mail ne peut être remis à une telle adresse, c’est pourquoi le système l’ignore lors de l’envoi. La valeur de substitution est enregistrée en anglais et reste en anglais dans toutes les langues.

Il y a deux voies. La voie automatique anonymise les comptes supprimés après un nombre de mois défini. La voie immédiate anonymise une seule personne tout de suite, par exemple après une demande d’effacement.

La voie automatique se trouve sous « Settings → Security », dans la carte « Data protection ». L’interrupteur « Anonymize deleted users automatically » est désactivé par défaut. À côté de « after », tu saisis le nombre de mois. De 1 à 120 sont autorisés, la valeur par défaut est 36. « Save » enregistre un nombre modifié.

Le délai court à partir du jour où un compte a été supprimé. Le système vérifie toutes les dix minutes si une exécution est due. Elle a lieu une fois par jour, lors de la première vérification après 03:00 dans le fuseau horaire défini sous « Settings → General Settings ». Chaque compte supprimé dont le délai est écoulé est anonymisé lors de cette exécution.

Quand tu actives l’interrupteur, une fenêtre s’ouvre d’abord. Elle liste les utilisateurs supprimés que la prochaine exécution anonymisera, chacun avec le jour de sa suppression. Tape ANONYMIZE dans le champ et clique sur « Confirm ». C’est seulement alors que l’interrupteur est activé. S’il est déjà plus de 03:00 dans ce fuseau horaire, la première exécution suit dans une dizaine de minutes.

La même fenêtre apparaît quand tu raccourcis le nombre de mois alors que l’interrupteur est activé. La désactivation ne demande aucune confirmation.

Le délai ne commence que lorsqu’un compte est supprimé. L’archivage ne suffit pas. Un compte archivé est seulement verrouillé et peut revenir à tout moment, par exemple après un congé parental. Pour supprimer un compte, clique sur le symbole de corbeille « Delete account » dans sa ligne sous « User management ».

Avant que quoi que ce soit ne se passe, une fenêtre indique ce qui suit. Si l’anonymisation automatique est activée, elle indique le nombre de mois. Un compte supprimé apparaît dans la vue « Archived » avec le badge « Deleted ». Le symbole « Restore account » le fait revenir. Pour les administrateurs et les agents, Basic a besoin pour cela d’une place libre. Si le compte est à nouveau supprimé plus tard, le délai recommence.

Ton propre compte n’a pas de symbole de corbeille. Seul un administrateur peut supprimer ou archiver un compte administrateur. Le dernier administrateur actif ne peut être ni supprimé ni archivé.

Quand quelqu’un est parti pour de bon, supprime donc le compte au lieu de seulement l’archiver. Un compte archivé depuis plus d’un an affiche un symbole de calendrier dans sa ligne. Son info-bulle te rappelle de supprimer le compte.

La voie immédiate se trouve dans la boîte de dialogue de l’export de données, dans la zone « Anonymize » sous les résultats. Tu ouvres la boîte de dialogue depuis la ligne d’un compte, ou avec « Export by e-mail address » pour une personne sans compte.

Si l’adresse appartient à un compte, clique d’abord sur « Use this account ». C’est seulement ainsi que le compte lui-même est anonymisé. Une exécution par l’adresse seule remplace l’adresse là où elle est enregistrée et laisse le compte tel quel.

Tape ANONYMIZE dans le champ et clique sur « Anonymize ». Un compte actif est d’abord supprimé, puis anonymisé. Ton propre compte ne peut pas être anonymisé. Le dernier administrateur actif non plus.

Ensuite, la ligne porte le badge « Anonymized ». Un tel compte ne peut plus être modifié, restauré ni réactivé. Seul l’export de données reste. Tu peux relancer l’anonymisation. Le numéro reste le même, et les données restaurées depuis sont prises en compte aussi.

La case « Also clear the content of tickets this person requested » va plus loin. Le nombre entre parenthèses est le nombre de ces tickets. Leurs textes sont vidés et leurs pièces jointes supprimées. Les tickets d’autres personnes dans lesquels la personne a seulement répondu sont seulement anonymisés.

Vérifie d’abord tes obligations de conservation. En Allemagne, par exemple, les lettres commerciales doivent être conservées six ans. La boîte de dialogue te le rappelle. La voie automatique ne fait qu’anonymiser. Elle ne vide jamais de contenu.

Si un fichier n’a pas pu être supprimé du serveur, la boîte de dialogue indique combien. L’exécution compte quand même comme terminée. Le système ne réessaie pas de lui-même.

Chaque exécution est enregistrée avec son heure, le numéro de la valeur de substitution et ce qui a été modifié. Pour la voie immédiate, l’enregistrement indique aussi qui l’a lancée. Il ne contient ni le nom ni l’adresse e-mail de la personne.

Anonymiser nécessite l’autorisation « Anonymize people ». Par défaut, seuls les administrateurs l’ont. Seul un administrateur peut l’utiliser. Elle ne peut jamais être donnée au rôle « Customer ». La boîte de dialogue de l’export de données nécessite en plus « Data export (data subject request) ».

Plus à ce sujet dans la carte : Export des données d’une personne, Délais de conservation

La carte « Data protection » avec l’interrupteur désactivé, le champ des mois, « Save » et le lien « Download list of anonymizations ».
Les cadres rouges sont sur l’interrupteur et sur le nombre de mois. L’interrupteur est désactivé, comme après chaque mise à jour.Ouvrir l'image en taille réelle
La fenêtre « Who will be anonymized » avec un utilisateur supprimé et la date de suppression, en dessous le champ avec ANONYMIZE et le bouton « Confirm ».
Les cadres rouges sont sur la liste et sur « Confirm ». Oliver Grant a été supprimé il y a plus de 36 mois. La première exécution l’anonymiserait.Ouvrir l'image en taille réelle
La fenêtre « Delete account » pour Amir Khan. Le texte indique ce qui suit et les 36 mois jusqu’à l’anonymisation.
Le cadre rouge est sur « Delete account ». L’anonymisation automatique est activée ici. C’est pourquoi la fenêtre indique le nombre de mois.Ouvrir l'image en taille réelle
La vue « Archived » avec le compte supprimé d’Oliver Grant, le badge « Deleted » et le symbole pour le restaurer.
Les cadres rouges sont sur le badge « Deleted » et sur « Restore account ». Jusqu’à l’anonymisation, le compte peut être récupéré.Ouvrir l'image en taille réelle
La boîte de dialogue « Export personal data » pour Tomas Novak. Sous les résultats se trouve la zone « Anonymize » avec la case cochée, ANONYMIZE saisi et le bouton « Anonymize ».
Les cadres rouges sont sur la case et sur « Anonymize ». Tomas Novak a demandé quatre tickets. Leur contenu serait vidé aussi.Ouvrir l'image en taille réelle
La zone « Anonymize » après l’exécution : en haut « Already anonymized as Anonymized user 2 », en bas le message « Done ».
Le cadre rouge est sur le message avec le numéro de la valeur de substitution. La zone permet une nouvelle exécution.Ouvrir l'image en taille réelle
La vue « Archived » avec des comptes anonymisés. Chaque ligne porte un nom de substitution, l’adresse de substitution et le badge « Anonymized ».
Le cadre rouge est sur le badge « Anonymized ». Un compte anonymisé n’a plus aucune action, sauf l’export de données.Ouvrir l'image en taille réelle

Le compte

Les tableaux suivants nomment chaque endroit où le système enregistre une personne, et ce que l’anonymisation y fait. Tu peux t’en servir pour décrire comment ton entreprise efface les données personnelles.

DonnéesCe qui se passe
Prénom et nom« Anonymized user » et le numéro
Adresse e-mail et identifiant de connexionl’adresse de substitution
Numéro de téléphoneretiré
Service, poste et siteretiré
Langue, affichage clair ou sombre, disponibilitéremis à la valeur par défaut
Mot de passe et liste des mots de passe précédentssupprimé
Clés de la connexion à deux facteurs et le lien avec un compte chez un fournisseur de connexion (SSO)supprimé
Événements de connexion dans le journal de sécuritésupprimés. Les actions d’administration de la personne dans le journal de sécurité sont conservées. Son nom y est remplacé par l’espace réservé.
Photo de profilsupprimé
Rôle et appartenance aux équipesretirés. La liste des utilisateurs affiche ensuite le rôle « Customer ».
Choix personnel des colonnes de la liste des ticketsretiré
Un chronomètre de la saisie du temps en courssupprimé
Le compte lui-mêmereste, supprimé et verrouillé pour de bon. Les tickets, les commentaires et les saisies de temps continuent de pointer vers lui. C’est pourquoi les rapports continuent de compter.
Indicateurs oui/non pour l’adresse e-mail confirmée, le téléphone confirmé et la connexion à deux facteurs, le réglage oui/non de la liste des tickets, le compteur d’échecs de connexion, la date du dernier changement de mot de passe et celle de la désactivationrestent. Ils ne contiennent aucune valeur de la personne, seulement oui ou non, des nombres et des dates. L’adresse, le numéro, le mot de passe et les clés eux-mêmes sont remplacés ou supprimés.
La mention, sur un ticket, de qui l’a modifié en derniersupprimée. Le ticket ne nomme alors plus personne comme dernière personne à l’avoir modifié.

Copies du nom

À certains endroits, le système enregistre le nom une seconde fois. Ainsi, une entrée montre encore qui l’a faite après une modification. Ces copies sont remplacées aussi.

EndroitCe qui se passe
Qui a fait une modification dans l’historique du ticketnom de substitution
Nom sur les saisies de tempsnom de substitution
Qui a modifié un article de la base de connaissancesnom de substitution
Entrées dans le « Audit log » d’une équipe, y compris « Added user … » et « Removed user … »nom de substitution
Nom du demandeur sur les tickets que la personne a demandésnom de substitution. Le numéro de téléphone du demandeur est retiré.
Anciennes et nouvelles valeurs dans l’historique du ticket : nom, adresse et téléphone du demandeur, observateurs, attributionvaleur de substitution ou retiré. Cela vaut dans les tickets de la personne et dans les tickets dont elle était auparavant la demandeuse.

Adresses e-mail

Partout où une adresse de la personne est enregistrée comme champ à part entière, elle devient l’adresse de substitution. Les majuscules et minuscules n’ont pas d’importance.

EndroitCe qui se passe
Adresse du demandeur sur les ticketsadresse de substitution
Destinataire des enquêtes de satisfactionadresse de substitution
Adresse d’un approbateur, sur les approbations et dans les demandes avec tâchesadresse de substitution
Expéditeur des e-mails entrantsadresse de substitution
Adresse de destinataire fixe dans les modèles de réponseadresse de substitution
Note interne indiquant qu’une règle de messagerie a déjà traité un e-mailadresse de substitution
Adresse dans l’enregistrement des exports de données précédentsadresse de substitution. L’enregistrement lui-même reste comme preuve. Un export de données ultérieur pour cette adresse n’enregistre lui aussi que la valeur de substitution.
Suggestions pour les informations sur le demandeur lors de la création d’un ticketsupprimées si elles portent l’adresse
Entrée sur la liste de blocage des e-mailsreste. Sinon, le spam de cette adresse passerait de nouveau après la suppression.
Consentements et désabonnements pour l'enquête de satisfactionsupprimés. Si la dernière entrée était un désabonnement, elle reste sous la forme d'une entrée sans adresse. La liste « Survey consents and unsubscribes » l'affiche comme « anonymized ». Tant que la personne ne redonne pas son consentement ou ne se réabonne pas, aucune enquête n'est envoyée à l'adresse. Si la clé d'anonymisation n'est plus lisible ou a été écartée, cette entrée n'a plus d'effet.

Adresses dans le texte

Dans les textes, l’anonymisation ne remplace que les adresses e-mail de la personne. Cela se fait dans les tickets qui concernent la personne. Ce sont les mêmes tickets que ceux que trouve l’export de données.

TexteCe qui se passe
Description du ticketadresses remplacées
Commentaires, y compris le texte des e-mails entrantsadresses remplacées
Objet des e-mails entrantsadresses remplacées
Notes sur les saisies de tempsadresses remplacées
Commentaire dans une enquête de satisfactionadresses remplacées
Anciennes et nouvelles valeurs dans l’historique du ticketadresses remplacées
Titre et texte des articles de la base de connaissances, y compris dans leur historiqueadresses remplacées, dans tous les articles

Vider le contenu des tickets demandés

Avec la case « Also clear the content of tickets this person requested », ces tickets perdent leur contenu. Ce dont les rapports et les délais ont besoin reste.

Partie du ticketCe qui se passe
Numéro, dates, statut, équipe, catégorie, priorité, attribution et délaisrestent
Titredevient « Content removed »
Descriptionvidé
Tous les commentaires, y compris les réponses des agentstexte vidé. Le commentaire lui-même reste, pour que la première réponse et les délais restent justes.
Objet des e-mails entrantsvidé
Valeurs des champs personnaliséssupprimé
Note de relance et lieuvidé
Historique du ticketLe type de chaque modification reste. Les valeurs sont vidées, sauf pour le statut, la priorité, la catégorie, la sous-catégorie, le canal, l’équipe, l’escalade et l’attribution. Les rapports en ont besoin.
Enquête de satisfactionLa note reste, le commentaire est vidé.
Saisies de tempsLes minutes saisies restent, la note est vidée.
Pièces jointessupprimées, l’entrée et le fichier

Limites

Les noms dans le texte libre restent, par exemple « Cordialement, Max » à la fin d’un e-mail. Les numéros de téléphone dans le texte libre restent aussi. Aucun des deux ne peut être reconnu de façon fiable. Pour les tickets d’un client, il y a la case qui vide le contenu.

Si un autre compte porte le même prénom et le même nom, le nom de la personne n’est pas remplacé dans l’historique du ticket ni comme nom du demandeur. Sinon, les entrées de l’autre personne seraient touchées aussi. L’adresse et le téléphone sont quand même remplacés. La vérification compare le prénom et le nom. L’historique des attributions enregistre l’identifiant de connexion. Un homonyme qui n’y figure qu’avec son identifiant de connexion n’est donc pas détecté.

Les très anciennes entrées de l’historique du ticket qui ne pointent pas encore vers le compte ne portent que le nom. Elles ne sont pas reconnues.

Un ticket qu’un agent a saisi par téléphone sans l’adresse e-mail du demandeur n’est pas reconnu. Le nom et le numéro de téléphone du demandeur y restent.

Les adresses dans les réglages ne sont pas modifiées, par exemple dans les règles de messagerie et les règles d’automatisation. Si l’adresse de la personne y figure, modifie-la toi-même.

Si la personne écrit de nouveau après l’exécution, une nouvelle exécution par son adresse couvre aussi les nouveaux e-mails. Tu la lances avec « Export by e-mail address ». Le numéro reste le même. Une nouvelle exécution sur le compte anonymisé ne trouve pas les nouveaux e-mails. Le compte ne connaît plus l’ancienne adresse.

Le système s’occupe lui-même des archives. Quand tu restaures une archive, chaque personne anonymisée auparavant est de nouveau anonymisée dans les tickets restaurés. Le message après la restauration indique combien. Une adresse qui n’apparaît dans ces tickets que dans le texte libre n’y est pas reconnue. Les fichiers d’archive sont en outre mis à jour par l’exécution nocturne qui suit une anonymisation. La carte « Délais de conservation » l’explique.

Pour une sauvegarde, c’est différent. Une sauvegarde faite avant une exécution contient encore les anciennes données. Lors de la restauration, « Ticket System Backup & Restore » s’en charge. L’application demande si toutes les personnes anonymisées dans l’état du jour doivent l’être à nouveau. « Yes » est présélectionné. Le système de tickets le fait alors lors de l’exécution nocturne à 03:00, dans le fuseau horaire défini. Cela vaut aussi quand l’interrupteur est désactivé. Jusque-là, leurs noms sont de nouveau visibles. La carte « Data protection » affiche une remarque avec leur nombre. La sauvegarde ramène aussi l’état de l’interrupteur de l’époque. Vérifie donc l’interrupteur après la restauration.

Si tu restaures une sauvegarde d’une autre manière, si tu réponds « No » ou si tu utilises « --no-reapply » en ligne de commande, cela n’a pas lieu. La voie automatique retrouve alors les comptes supprimés, tant que l’interrupteur est activé. Les exécutions que tu as lancées à la main doivent être répétées. Le lien « Download list of anonymizations » dans la carte « Data protection » t’y aide. Télécharge la liste avant la restauration. Ensuite, elle ne contient plus les exécutions faites après la sauvegarde. La liste a une ligne par personne anonymisée, avec les colonnes « Date », « Number », « Account ID », « E-mail hash » et « Content cleared ». « Date » est le moment de la première exécution en UTC. « Account ID » n’est rempli que si un compte a été anonymisé. « E-mail hash » est une empreinte de l’adresse qui ne peut pas être inversée. « Content cleared » indique si le contenu des tickets demandés par la personne a été vidé. Après chaque exécution, télécharge toi-même la liste et conserve-la en dehors du système. Une sauvegarde faite avant une exécution ne contient pas cette exécution.

Texte pour ta politique de confidentialité

En tant qu’exploitant, tu dois dire aux personnes combien de temps tu conserves leurs données. Tu peux reprendre ce texte dans ta propre politique de confidentialité.

Texte type

Après votre départ, votre nom et votre adresse e-mail dans le système de tickets sont remplacés par une valeur de substitution au bout de [36] mois. Les tickets et les chiffres sont conservés sans aucun lien avec vous. À votre demande, nous pouvons aussi anonymiser vos données plus tôt, sauf si une obligation de conservation s’y oppose. Les données des contacts externes avec lesquels il n’y a plus eu de contact depuis [36] mois sont anonymisées de la même manière. Les événements de connexion du journal de sécurité sont supprimés au bout de [90] jours. Les entrées relatives aux actions d’administration sont supprimées au bout de [12] mois.

Adapte les nombres à tes propres réglages. Supprime chaque phrase dont l’interrupteur est désactivé. Fais vérifier le texte par ton propre conseiller en protection des données. Ce manuel n’est pas un conseil juridique.

Demandes d’effacement et personnes qui reviennent

Supprimer et anonymiser sont deux choses différentes. « Delete account » ne fait que masquer un compte. « Restore account » le ramène. Jusque-là, son adresse e-mail reste réservée à ce compte. Tu traites donc une demande d’effacement avec « Anonymize » dans la boîte de dialogue de l’export de données. Cela ne peut pas être annulé. Le nom et l’adresse sont remplacés par « Anonymized user » et le numéro. Le lien vers le compte chez un fournisseur d’authentification unique est supprimé.

Chaque adresse e-mail appartient à un seul compte. Si tu crées un compte avec une adresse qu’un autre compte possède déjà, le système refuse. Le message est « This e-mail address already belongs to another account. » Il en va de même quand tu modifies l’adresse d’un compte. Si l’adresse appartient à un compte supprimé, le message est « This e-mail address belongs to a deleted account. Restore that account instead. » Restaure alors l’ancien compte au lieu d’en créer un nouveau. Les comptes anonymisés ne comptent pas. Ils ne portent plus que l’adresse de substitution.

Un compte supprimé ne peut pas être restauré si un autre compte actif possède entre-temps la même adresse. Le message est alors « This e-mail address already belongs to another account. » Modifie d’abord l’adresse de l’autre compte.

Il peut exister, depuis l’époque d’avant cette règle, des comptes qui partagent une adresse. La gestion des utilisateurs les signale par la remarque « This e-mail address belongs to more than one account. Change it so that each account has its own address. » Donne à chacun de ces comptes sa propre adresse. Jusque-là, la connexion avec cette adresse à la place du nom d’utilisateur ne fonctionne pas. L’e-mail de réinitialisation du mot de passe n’est pas envoyé non plus.

Si une personne revient après une demande d’effacement, elle obtient un nouveau compte. C’est le cas par exemple quand elle se reconnecte via Google ou Microsoft avec la même adresse. Pour cela, « Automatically create accounts on first sign-in » doit être activé. Le compte anonymisé ne porte plus son adresse et ne gêne pas le nouveau compte.

Les anciennes anonymisations n’affectent jamais les nouveaux tickets de cette personne. Cela vaut aussi après la restauration d’une sauvegarde ou d’une archive. Quand une anonymisation est appliquée de nouveau, elle ne couvre que les données créées avant son moment.

Si l’ancien compte a seulement été supprimé et non anonymisé, le système refuse la première connexion par SSO avec cette adresse. Ce que voit la personne dépend du fournisseur. Si le fournisseur confirme l’adresse, le message est « An account with this e-mail address was deleted. Ask an administrator to restore it. » S’il ne la confirme pas, le message est « Your e-mail address is not verified with the provider. » Ainsi, le système ne révèle pas s’il existe un compte supprimé pour une adresse.

En tant qu’administrateur, tu as alors deux possibilités. Si tu restaures l’ancien compte avec « Restore account », la personne continue d’y travailler avec son historique. La connexion par SSO fonctionne si le compte était déjà lié à ce fournisseur ou si le fournisseur confirme l’adresse. Si la demande d’effacement reste valable, anonymise l’ancien compte. Ensuite l’adresse est libre, et la connexion crée un nouveau compte.

L’auto-inscription répond dans ce cas de façon neutre : « Registration could not be completed. If you already have an account, use the password reset on the sign-in page. » Elle ne révèle pas s’il existe un compte pour l’adresse.

6

Délais de conservation

Avant de commencer : Seul un administrateur peut modifier ces réglages. Une anonymisation ne peut pas être annulée.

Le système ne garde les données personnelles qu’aussi longtemps que nécessaire. Une personne est anonymisée quand elle part ou quand elle le demande. Partir signifie un compte supprimé, ou un contact externe qui n’a plus eu de contact depuis longtemps. Tu traites une demande dans la boîte de dialogue de l’export de données avec « Anonymize ».

Les tickets eux-mêmes n’ont pas de délai. Leur contenu garde son utilité, par exemple comme historique client. Les rapports et les saisies de temps continuent de compter.

Tous les délais se trouvent sous « Settings → Security », dans la carte « Data protection ». Elle a trois blocs : « Deleted accounts », « External contacts » et « Security log retention ». Chaque bloc a un interrupteur, un délai et « Save ». Le bloc « Security log retention » a deux interrupteurs et deux délais. En dessous se trouve « Archives ». Après une restauration, « Restore from a backup » s’ajoute dès que la prochaine exécution de 03:00 a eu lieu. D’ici là, la carte affiche la remarque « … will be applied again tonight at 03:00. » La carte « Anonymiser des personnes » explique le premier bloc. Elle contient aussi le texte type pour ta politique de confidentialité. Sous la description de la carte « Data protection » se trouve le lien « Data protection guide for operators ». Le guide contient des modèles pour le registre des activités de traitement, les mesures techniques et organisationnelles et une politique de conservation et de suppression.

Sous chaque bloc se trouve une ligne « Last run ». Elle indique la date et l’heure de la dernière exécution nocturne et combien de personnes ou d’entrées elle a traitées. « 0 done » signifie qu’il n’y avait rien à faire. « Not run yet » apparaît tant que la tâche n’a pas de résultat. Si un interrupteur est désactivé, sa tâche ne s’exécute pas.

Si la ligne est orange, la tâche n’a pas tout terminé. Avec « skipped », elle indique combien de personnes, d’entrées ou de fichiers ont été ignorés. Pour « Archives », ce sont des fichiers verrouillés ou endommagés. Avec « failed », toute la tâche a échoué. La phrase qui suit dit quoi faire. Si elle indique « Details are in the server log. », lis le journal du serveur. Sous Linux, la commande « sudo podman logs container-backend-1 » l’affiche. Si elle mentionne la clé d’anonymisation, suis la section « Quand la clé est illisible » plus bas. La prochaine exécution nocturne réessaie ce qui a été ignoré.

Plus à ce sujet dans la carte : Anonymiser des personnes, Tout récupérer

La carte « Data protection » avec les blocs « Deleted accounts », « External contacts » et « Security log retention », en dessous « Archives » et « Restore from a backup », chacun avec sa ligne « Last run ».
Les cadres rouges sont sur les lignes « Last run ». Ici, les quatre interrupteurs sont activés. Par défaut, seuls les deux interrupteurs du bloc « Security log retention » sont activés.Ouvrir l'image en taille réelle
Le bloc « External contacts » avec l’interrupteur « Anonymize external contacts automatically » et le champ « Months without contact ».
Les cadres rouges sont sur l’interrupteur et sur le nombre de mois. Le texte en dessous indique ce qui compte comme contact.Ouvrir l'image en taille réelle
La fenêtre « Who will be anonymized » avec la phrase « Nobody is due yet with this time limit. », ANONYMIZE saisi et « Confirm ».
Les cadres rouges sont sur le champ et sur « Confirm ». Ici, le délai a été raccourci à 24 mois, et personne ne serait concerné. Sinon, le nombre et les premières personnes avec leur dernier contact apparaissent ici.Ouvrir l'image en taille réelle
La carte « Recent sign-in attempts » avec la phrase « Entries are deleted after 90 days (Settings → Security). » et trois connexions.
Le cadre rouge est sur la phrase sur le délai. Si la suppression est désactivée, elle indique « Entries are kept until you delete them. »Ouvrir l'image en taille réelle
Deux remarques en haut de la carte : le nombre d’adresses qui ne sont plus reconnues, et des anonymisations qui n’ont pas pu être reprises.
Le cadre rouge est sur la remarque concernant la reprise. Ce qu’il faut faire figure dans la section « Restaurer une sauvegarde ».Ouvrir l'image en taille réelle
L’avertissement « The anonymization key cannot be read » avec le lien « How to restore the key » et le bouton « Discard old key ».
Les cadres rouges sont sur le lien vers ce manuel et sur « Discard old key ». Tant que l’avertissement est affiché, la carte n’affiche aucune remarque sur des anonymisations en attente.Ouvrir l'image en taille réelle
La fenêtre « Discard old key » avec DISCARD saisi dans le champ « Confirmation word ».
Les cadres rouges sont sur le champ et sur « Discard old key ». Le bouton ne peut être cliqué qu’avec le mot.Ouvrir l'image en taille réelle

Contacts externes

Les contacts externes sont des personnes sans compte de collaborateur. Ce sont les demandeurs sans compte et les comptes clients. Pour le système, ils ne partent jamais. C’est pourquoi ce bloc compte le temps écoulé depuis le dernier contact.

Le dernier contact est le plus récent de ces moments : la dernière modification d’un ticket demandé par la personne, un e-mail de sa part, son propre commentaire, une réponse à une enquête de satisfaction, une approbation qui lui a été envoyée et une suggestion pour les informations sur le demandeur. Pour un compte client, le jour de sa création compte aussi. Un nouveau compte jamais utilisé n’est donc pas concerné tout de suite. Les comptes qui existaient avant la mise à jour vers la version 1.7.0 comptent comme créés le jour de la mise à jour.

Les comptes de collaborateurs et leurs adresses ne sont jamais concernés. Cela vaut aussi pour une adresse partagée comme info@ si elle appartient à un compte de collaborateur. Quiconque a un ticket pas encore fermé est ignoré jusqu’à sa fermeture. Les comptes supprimés relèvent du bloc « Deleted accounts ».

L’interrupteur « Anonymize external contacts automatically » est désactivé par défaut. À côté de « Months without contact », tu saisis le nombre de mois. De 1 à 120 sont autorisés, la valeur par défaut est 36.

Quand tu actives l’interrupteur, la fenêtre « Who will be anonymized » s’ouvre d’abord. Elle indique combien de personnes sont concernées et montre les premières avec leur dernier contact. Tape ANONYMIZE dans le champ et clique sur « Confirm ». La même fenêtre apparaît quand tu raccourcis le nombre alors que l’interrupteur est activé et que tu cliques sur « Save ».

Cela s’applique lors de la prochaine exécution nocturne. Chaque personne concernée est anonymisée comme avec « Anonymize ». Son contenu n’est jamais vidé. Il reste la valeur de substitution, les tickets et les chiffres. Les noms et les numéros de téléphone dans le texte libre restent. La carte « Anonymiser des personnes » en indique les limites.

Journal de sécurité

Le journal de sécurité enregistre les événements de connexion et les actions d’administration. Les événements de connexion contiennent aussi l’adresse IP et l’identification du navigateur. Ce qui est enregistré exactement, la carte « Le journal de sécurité » l’explique.

La carte « Recent sign-in attempts » sous « Settings → SSO Settings » montre les 100 derniers événements de connexion via SSO et l’annuaire. Toute personne autorisée à ouvrir cette page peut la voir. Par défaut, ce sont uniquement les administrateurs. La phrase sous le titre de la carte indique le délai, par exemple « Entries are deleted after 90 days (Settings → Security). »

Par défaut, les événements de connexion sont supprimés au bout de 90 jours et les actions d’administration au bout de 12 mois. Dans le bloc « Security log retention », tu règles de 7 à 365 jours à côté de « Days » et de 1 à 120 mois à côté de « Months ». Les interrupteurs « Delete old sign-in events » et « Delete old administrator actions » désactivent la suppression. Les entrées restent alors. Aucun mot de confirmation n’est nécessaire, car seules des entrées sont supprimées, pas des personnes.

La connexion avec nom d’utilisateur et mot de passe figure elle aussi dans le journal de sécurité. Une tentative échouée est enregistrée avec son adresse IP et son navigateur. Une connexion réussie n’est enregistrée que pour les administrateurs et après des tentatives échouées.

Archives

Un fichier d’archive contient aussi des personnes anonymisées seulement plus tard. L’exécution nocturne qui suit une anonymisation met donc à jour chaque fichier d’archive dans lequel la personne apparaît. Les noms et adresses y sont remplacés par les mêmes valeurs de substitution que dans la base de données. Si le contenu a été vidé, les pièces jointes de ces tickets manquent aussi dans l’archive.

Jusqu’à la nuit suivante, la personne figure donc encore en clair dans les archives. Les archives n’ont pas d’interrupteur. Un fichier d’archive verrouillé à ce moment reste inchangé, par exemple parce qu’il est en cours de téléchargement ou de restauration. Il en va de même pour un fichier endommagé. La prochaine exécution nocturne réessaie.

Heure et fuseau horaire

Toutes ces tâches s’exécutent une fois par jour à 03:00. C’est le fuseau horaire sous « Settings → General Settings », dans la carte « Time Zone », qui s’applique. L’horloge du serveur ne joue aucun rôle. Beaucoup de serveurs tournent en UTC. Là, 03:00 serait une autre heure pour toi.

Le système vérifie toutes les dix minutes si l’exécution est due. La première vérification après 03:00 la lance. Si le serveur était éteint à 03:00, l’exécution suit à la première vérification après le démarrage.

Après la mise à jour vers la version 1.7.0, la première exécution a lieu peu après la mise à jour, au plus tard à 03:00 la nuit suivante. Cette exécution supprime les entrées du journal des connexions de plus de 90 jours.

Si tu changes le fuseau horaire, le nouveau s’applique dès la prochaine vérification. L’exécution a lieu au plus une fois par jour calendaire. Après un changement vers l’ouest, elle peut sauter ce jour-là. Elle suit alors le lendemain.

L’application « Ticket System Backup & Restore » planifie ses sauvegardes dans le même fuseau horaire. Elle lit le fuseau dans le système de tickets quand le planning est appliqué. L’onglet « Schedule » et « schedule --show » affichent l’heure avec le fuseau, par exemple « 02:00 (Europe/Berlin) ». Si la base de données n’est pas joignable à ce moment, le fuseau précédent reste. S’il n’y en a pas encore, l’horloge de l’ordinateur s’applique et l’affichage indique « (host clock) ».

Le système d’exploitation ne connaît que sa propre horloge. L’application convertit donc l’heure. Selon le fuseau horaire du serveur, elle inscrit une ou deux entrées par planning. Ainsi, la sauvegarde tourne à la bonne heure en été comme en hiver. Au démarrage, elle vérifie si une sauvegarde est vraiment due. Sinon, elle se termine sans sauvegarde, et le journal indique « No backup is due at this time in … ».

Si tu changes le fuseau horaire dans le système de tickets, la prochaine sauvegarde planifiée tourne quand même. Ensuite, l’application inscrit de nouveau le planning. Le journal affiche alors un avertissement qui commence par « The time zone in the ticket system changed ». Si le planning n’a pas pu être inscrit de nouveau, il indique « The schedule could not be updated. » Ouvre alors l’application et clique sur « Apply schedule ».

Quand la clé est illisible

Le système retient les adresses e-mail anonymisées sous forme d’empreinte. Il lui faut pour cela une clé. Le trousseau de clés du serveur protège cette clé. Le trousseau se compose des fichiers key-*.xml dans le dossier des clés. S’ils manquent ou ne correspondent pas, la carte affiche l’avertissement « The anonymization key cannot be read ».

Les mots de passe enregistrés pour la messagerie et le SSO ne fonctionnent alors plus non plus. Ils dépendent du même trousseau. Les exécutions nocturnes pour les comptes supprimés et le journal de sécurité continuent. Les personnes connues seulement par leur adresse sont ignorées. « Anonymize » refuse une exécution par la seule adresse.

Voici comment récupérer le trousseau. Prends une sauvegarde d’avant le problème. Elle contient le dossier des clés sous forme de fichier séparé. Sous Linux, les sauvegardes se trouvent dans « /opt/smitey/backups ». Copie-en une dans un dossier vide et place-toi dans ce dossier. Les commandes ci-dessous écrivent la sauvegarde sous forme de fichiers ordinaires et en extraient les fichiers key-*.xml. Ensuite, elles copient les fichiers dans le dossier des clés et redémarrent le serveur du système de tickets. Les autres fichiers du dossier des clés restent tels quels. Après le redémarrage, l’avertissement a disparu. Supprime ensuite le dossier « plain ». Il contient des mots de passe et des données personnelles. Une sauvegarde plus ancienne se terminant par « .zip » n’est pas chiffrée. Pour elle, la première commande est « sudo unzip -o <fichier> volumes/dataprotection_keys.tar && sudo tar -xf volumes/dataprotection_keys.tar ».

Sous Windows, les sauvegardes se trouvent dans « C:\Program Files\SMITEY\backups ». Copie-en une dans un dossier vide. Ouvre-y PowerShell en tant qu’administrateur. Saisis la commande de l’encadré « Windows : Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés ». Remplace-y <fichier>.smbk par le nom complet du fichier de la sauvegarde. Copie ensuite chaque fichier key-*.xml avec « podman cp <fichier> container-backend-1:/app/DataProtection-Keys/ ». Saisis les commandes pour le propriétaire et le redémarrage sans « sudo ». Supprime ensuite le dossier « plain ».

Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés

sudo /opt/smitey/Backup/TicketSystemBackup decrypt ticketsystem-backup-*.smbk --out plain && sudo tar -xf plain/volumes/dataprotection_keys.tar

Le dossier contient exactement une sauvegarde. Ensuite, les fichiers key-*.xml s’y trouvent. Le sous-dossier « plain » contient toute la sauvegarde non chiffrée.

Copier les fichiers dans le dossier des clés

for f in key-*.xml; do sudo podman cp "$f" container-backend-1:/app/DataProtection-Keys/; done

Les fichiers existants portant un autre nom restent dans le dossier des clés.

Donner aux fichiers le bon propriétaire

sudo podman exec -u root container-backend-1 chown -R 1654:1654 /app/DataProtection-Keys

Le système de tickets tourne dans le conteneur sous son propre utilisateur. Les fichiers doivent lui appartenir.

Redémarrer le serveur du système de tickets

sudo podman restart container-backend-1

Après le redémarrage, le système relit le trousseau de clés.

Windows : Écrire la sauvegarde sous forme de fichiers non chiffrés et en extraire les fichiers de clés

& "C:\Program Files\SMITEY\Backup\TicketSystemBackup.exe" decrypt <file>.smbk --out plain | Out-Host; tar -xf plain\volumes\dataprotection_keys.tar

Dans PowerShell en tant qu’administrateur, dans le dossier de la sauvegarde. Remplace <file>.smbk par le nom complet du fichier de la sauvegarde. Ensuite, les fichiers key-*.xml s’y trouvent.

Le dernier recours : « Discard old key »

Si tu n’as aucune sauvegarde avec les fichiers de clés, il reste « Discard old key ». Seul un administrateur voit le bouton. Tape DISCARD dans le champ « Confirmation word » et clique sur « Discard old key ». Le système crée alors une nouvelle clé.

Les anonymisations par compte continuent d’agir. Les personnes anonymisées uniquement par leur adresse ne sont ensuite plus reconnues dans les sauvegardes et les archives. La carte indique leur nombre. Une sauvegarde plus ancienne peut donc rendre ces personnes de nouveau visibles. Les mots de passe enregistrés pour la messagerie et le SSO restent illisibles. Saisis-les de nouveau.

Restaurer une sauvegarde

Lors de la restauration, « Ticket System Backup & Restore » demande si toutes les personnes anonymisées aujourd’hui doivent l’être à nouveau. « Yes » est présélectionné. Le système de tickets le fait lors de la prochaine exécution nocturne à 03:00 dans son fuseau horaire. D’ici là, la carte affiche « … will be applied again tonight at 03:00. »

La sauvegarde ramène aussi les interrupteurs et les délais de l’époque. Vérifie donc la carte « Data protection » après la restauration.

S’il y a eu des avertissements lors de la reprise, la ligne d’état de l’application indique leur nombre, par exemple « 2 warning(s) while carrying over anonymizations. See the Log tab. » En ligne de commande, la même chose figure dans la dernière ligne et renvoie à « backup.log ». C’est là qu’est indiqué ce qui n’a pas fonctionné. Si les anonymisations n’ont pas pu être reprises, refais à la main les exécutions faites après cette sauvegarde. La liste téléchargée avant la restauration t’y aide.

Le système de tickets lit le fichier de reprise de l’application à son prochain démarrage. S’il ne peut pas le lire, la carte affiche « A carry-over file from the backup app could not be read ». Le fichier reste sur le serveur et est relu au prochain démarrage. Restaure alors la sauvegarde encore une fois avec la version actuelle de l’application.

Si la clé de la sauvegarde ne correspond pas, les anonymisations par adresse ne peuvent pas être reprises. La carte affiche alors « … could not be carried over from before the restore ». Si tu connais ces personnes, anonymise-les de nouveau avec « Export by e-mail address ».

La ligne « Last run » sous « Restore from a backup » montre combien d’anonymisations l’exécution a de nouveau appliquées.

7

Les rôles et le concept d'autorisations

Il y a trois rôles : « Admin », « Agent » et « Customer ». Aucun autre ne peut être créé. Ce qui est libre en revanche, c'est presque chaque autorisation individuelle ; les exceptions sont listées plus bas.

Tu trouves ces trois rôles sous « Settings → General Settings » dans l'onglet « Role ». Ils ne peuvent pas être renommés.

Ce qu'un rôle a le droit de faire se trouve ailleurs : sous « Settings → Security » dans la carte « Permission concept ».

Chaque ligne est une fonction, chaque colonne un rôle. Une coche l'autorise. Sous le nom figure la clé interne ; tu n'en as pas besoin pour travailler avec la page.

La liste est longue. Elle va de la gestion des utilisateurs à l'accès aux différentes pages de paramètres, jusqu'au suivi du temps.

La colonne « Agent Team » est le cas particulier. Elle ne devient utilisable qu'une fois la coche « Agent » posée sur la même ligne. Choisis-y une équipe et l'autorisation ne vaut que pour les agents de cette équipe.

Aucune autorisation ne peut être retirée au rôle « Admin ». La coche est de retour après l'enregistrement. Ainsi, personne ne peut se fermer la porte de son propre système. Seul un administrateur peut modifier le tableau. Cela vaut pour chaque réglage de la page « Security ». Toute autre personne autorisée à ouvrir la page la voit en lecture seule. Six autorisations ne peuvent jamais être données au rôle « Customer » : « Users: manage accounts », « Data export (data subject request) », « Anonymize people », « Security log », « Settings: Security » et « Settings: Single sign-on ».

Avec « Save », le changement s'applique immédiatement. Les personnes concernées s'en aperçoivent au clic suivant.

La carte « Permission concept » avec le tableau : une ligne par fonction, des colonnes pour l'administrateur, l'agent, l'équipe d'agents et le client.
Le cadre rouge entoure la ligne d'en-tête. Le sélecteur de la colonne « Agent Team » n'est utilisable que là où la coche « Agent » est posée.Ouvrir l'image en taille réelle
L'onglet « Role » avec les trois rôles, chacun marqué « Mandatory ».
Le cadre rouge entoure la remarque. Les trois rôles sont marqués « Mandatory ». Aucun d'eux ne peut être supprimé.Ouvrir l'image en taille réelle
8

Département, poste et site

Trois listes décrivent la personne et non le ticket : le département, le poste et le site.

Elles se créent sous « Settings → General Settings » dans la carte « Drop-down lists ». La manipulation est la même pour les trois.

Elles s'attribuent sur le compte. Dans le formulaire sous « User management », les champs s'appellent « Department », « Position » et « Location ».

Dans la liste des utilisateurs, le département figure sous l'équipe. Le poste et le site sont visibles dans le formulaire du compte.

Le site a un second usage. Il y a un champ « Location » sur le ticket, et il puise dans la même liste.

Chacune des trois listes a une entrée que tu ne peux pas supprimer. Elle s'appelle « None selected or available » et porte la pastille « Mandatory ».

Si tu supprimes une autre entrée, toutes les personnes qui la portaient passent à cet emplacement de remplacement. Personne ne reste ainsi rattaché à quelque chose qui a disparu.

Tu ne traduis pas ici, mais en une seule fois sur la page de traduction. Le nom anglais est l'ancre à laquelle les traductions se rattachent.

La boîte de dialogue « Edit user » avec les champs de département, de poste et de site remplis.
Les cadres rouges entourent les trois champs. Ils sont à côté de l'équipe mais veulent dire autre chose : l'équipe dit qui traite les tickets, le département dit où la personne travaille.Ouvrir l'image en taille réelle
La liste des utilisateurs avec la colonne « Team » qui contient le département sous le nom de l'équipe.
Le cadre rouge entoure la colonne. L'équipe est en haut, le département en dessous. Celui qui n'est dans aucune équipe a un tiret à cet endroit.Ouvrir l'image en taille réelle

Intégration e-mail

Le système de tickets récupère le courrier d'une boîte aux lettres et envoie lui-même des messages. La mise en place est décrite sur la carte « Tickets à partir d'e-mails, réponses et relances » dans le bloc de gestion des tickets. Ce bloc montre ce que devient un message entrant, comment tu bloques des expéditeurs et quels messages le système envoie de lui-même. Tout le canal de messagerie fait partie de l'édition Professional.

1

Ce que devient un e-mail

Professional uniquement

Quand quelqu'un écrit à la boîte aux lettres d'une équipe, un ticket en est créé. L'objet devient le titre, le texte devient la description, et l'adresse de l'expéditeur est enregistrée comme demandeur. Le canal sur le ticket indique « E-mail ».

Si le message porte un nom d'expéditeur, ce nom va dans le champ à côté de l'adresse. Sinon, le champ indique « E-Mail ». Le canal dit déjà que l'affaire est arrivée par courrier électronique.

Les préfixes comme « Re: » ou « Fwd: » sont retirés du titre. Le ticket porte alors le nom de l'affaire et non celui d'une réponse à celle-ci.

La mise en forme du message est conservée. Le texte en gras, les listes et les tableaux apparaissent dans le ticket exactement comme dans le message.

Les liens sont conservés. Ton agent peut cliquer dessus dans le ticket au lieu de recopier l'adresse.

Une image intégrée au message reste là où elle était dans le texte. Elle est aussi enregistrée comme pièce jointe sur le ticket.

Une image que le message se contente de charger depuis le web est retirée. De telles images signalent souvent à l'expéditeur quand et où un message a été lu. Qui veut qu'une image arrive doit l'intégrer au message ou la joindre.

Les fichiers joints au message deviennent des pièces jointes sur le ticket. Seuls les types de fichiers pdf, doc, docx, xls, xlsx, txt, png, jpg, jpeg et gif sont repris. Les autres fichiers sont écartés. La même limite de taille s'applique que pour un fichier envoyé par un agent.

Si la réponse automatique est activée dans le workflow, l'expéditeur reçoit une confirmation tout de suite. Avec la référence dans l'objet, chaque réponse suivante retrouve le même dossier et en devient un commentaire.

Une image intégrée dans une telle réponse apparaît sur le commentaire auquel elle appartient.

Si le demandeur répond à un ticket résolu ou fermé, celui-ci repasse à « Reopened ». Il en va de même quand le demandeur commente dans le portail client. Les réponses des personnes en copie, des observateurs et des agents ne rouvrent rien.

Plus à ce sujet dans la carte : Tickets à partir d'e-mails, réponses et relances

Le message envoyé dans le logiciel de messagerie de l'expéditeur, avec une image intégrée et un lien.
Cette fenêtre n'est pas le système de tickets, c'est le logiciel de messagerie de l'expéditeur. Le message contient une image intégrée et un lien.Ouvrir l'image en taille réelle
La description du ticket créé, avec l'image à sa place et le lien.
Le même message sous forme de ticket. Les cadres rouges entourent l'image et le lien. Les deux sont au même endroit que dans le message, et le lien est cliquable.Ouvrir l'image en taille réelle
L'onglet « Attachments » du ticket avec le fichier inline_image_1.png.
L'image intégrée est aussi enregistrée comme pièce jointe. Elle peut ainsi être téléchargée sans être extraite du texte.Ouvrir l'image en taille réelle
La confirmation dans la boîte de réception de l'expéditeur, avec la référence dans l'objet.
La confirmation telle qu'elle arrive chez l'expéditeur. L'objet porte la référence du dossier. Si l'expéditeur y répond, la réponse arrive sur le même ticket.Ouvrir l'image en taille réelle
2

Bloquer des expéditeurs

Professional uniquement

Avant de commencer : La liste de blocage se trouve tout en bas de la page « E-Mail Settings ». Elle s'applique à toutes les équipes à la fois.

Certains expéditeurs ne doivent pas créer de ticket. Les lettres d'information en sont un exemple, et les boîtes aux lettres qui n'envoient que des rapports automatiques en sont un autre.

Saisis une adresse complète quand un seul expéditeur est visé. Sur l'image, c'est no-reply@example.com.

Saisis le domaine précédé d'un @ quand toutes les adresses d'un expéditeur sont visées. Sur l'image, c'est @newsletter.example.net. Les sous-domaines sont bloqués avec lui.

Un message d'un expéditeur bloqué ne crée aucun ticket. Il est marqué comme lu et déplacé dans le dossier des messages traités. Rien ne s'accumule dans la boîte de réception.

Le blocage fonctionne aussi dans l'autre sens. Le système n'envoie aucun message à une adresse bloquée.

C'est le véritable intérêt pour les adresses que personne ne lit. Sans le blocage, la confirmation partirait vers une boîte aux lettres qui ne répond jamais.

« Add » place une entrée sur la liste. L'icône de corbeille à côté la supprime de nouveau. Un changement prend effet immédiatement, il n'y a rien à enregistrer.

Les messages générés automatiquement n'ont pas besoin d'entrée sur la liste. Cela concerne les avis de non-remise, les réponses d'absence et les envois en masse. Ils ne créent pas non plus de ticket et ne reçoivent pas de réponse. Le système les marque comme lus et les déplace dans le dossier des messages traités.

Cela vaut aussi pour les alarmes d'un système de supervision si elles sont marquées comme courrier généré automatiquement. Une alarme sans ce marquage devient un ticket comme n'importe quel autre message.

La carte « E-Mail Blacklist » avec deux entrées : une adresse complète et un domaine.
Le cadre rouge entoure le champ de saisie. Son texte d'exemple nomme les deux formes autorisées. En dessous se trouvent les deux entrées de cette installation.Ouvrir l'image en taille réelle
3

Ce que le système envoie de lui-même

Professional uniquement

Avant de commencer : Les interrupteurs de cette carte se trouvent par équipe sous « Team mailboxes » sur la page « E-Mail Settings », juste sous l'adresse de la boîte aux lettres de cette équipe.

Outre les réponses à tes clients, le système envoie ses propres messages. Cela comprend l'attribution d'un ticket, un délai dépassé, une invitation, un nouveau mot de passe, l'enquête de satisfaction et l'approbation d'une demande.

Ces textes sont fournis tout faits et sont d'abord en anglais. Ils se trouvent dans le paquet de langue avec tous les autres textes de l'interface.

Une fois un paquet de langue importé, chacun de ces messages part dans la langue réglée sur le destinataire. Deux personnes sur la même affaire reçoivent donc le message en deux langues. Les destinataires sans compte n'ont pas de langue propre. Les messages qui leur sont destinés partent dans la langue réglée sur l'équipe sous « Default e-mail language ». Cela concerne par exemple l'enquête, la résolution d'un incident collectif, un refus et le message d'une règle.

Tu modifies la formulation sur la page des langues. Tu y télécharges les textes d'une langue sous forme de fichier, tu le modifies et tu le renvoies. L'anglais est la source et reste tel quel.

Le fait qu'une attribution soit annoncée ou non se décide par équipe. Trois interrupteurs se trouvent sous la boîte aux lettres pour cela.

« Send assignment e-mails » envoie un message à l'agent qui reçoit un ticket. Avec l'interrupteur désactivé, cette équipe n'annonce aucune attribution.

« Notify on self-assignment » décide si un message part aussi quand quelqu'un prend un ticket lui-même. Cet interrupteur est désactivé par défaut.

« Send mail on ticket actions » agit ailleurs. Une fois activé, les boîtes de dialogue de fermeture, de changement de statut et de transmission proposent d'envoyer aussi le commentaire par courrier électronique.

La confirmation destinée à tes clients n'a pas sa place ici. Tu en écris le texte toi-même, dans le workflow de la boîte aux lettres.

Plus à ce sujet dans la carte : Tickets à partir d'e-mails, réponses et relances

La section « Assignment notifications » avec trois interrupteurs.
Les cadres rouges entourent les trois interrupteurs. Ils appartiennent à la boîte aux lettres d'équipe au-dessus. Chaque autre équipe a les mêmes trois interrupteurs, pour elle.Ouvrir l'image en taille réelle

Authentification et sécurité, SSO compris

Qui entre et comment se décide à deux endroits. La page de sécurité règle la connexion avec un nom d'utilisateur et un mot de passe. La page SSO relie un annuaire ou un service de connexion externe. Tu peux faire fonctionner les deux en même temps.

1

Se connecter avec un nom d'utilisateur et un mot de passe

Avant de commencer : Les réglages de cette carte se trouvent sous « Settings → Security ». Seul un administrateur peut les modifier. Toute autre personne qui a reçu l'accès à la page la voit en lecture seule.

Au départ, tout le monde se connecte avec un nom d'utilisateur et un mot de passe. L'adresse e-mail fonctionne à la place du nom d'utilisateur. Si l'envoi de courrier électronique est configuré, le lien « Do you need a password reset? » apparaît sous le formulaire. L'envoi de courrier électronique fait partie de Professional.

Après la connexion, le navigateur reçoit un laissez-passer valable pour une durée définie. La carte « JWT token timer » décide de la durée. Les valeurs de 1 à 24 heures sont autorisées, 12 est la recommandation. Ensuite, la personne doit se reconnecter.

La carte « Password policy » s'applique à chaque mot de passe défini dans le système. Elle est appliquée à la création d'un compte, quand une personne change son propre mot de passe et quand un administrateur en réinitialise un.

Tu définis la longueur minimale, les types de caractères qui doivent apparaître, au bout de combien de jours un mot de passe expire et combien d'anciens mots de passe restent bloqués. Pour les jours et pour la liste de blocage, 0 signifie « désactivé ».

Les règles sur les majuscules et les minuscules n'excluent aucune langue. Beaucoup de systèmes d'écriture n'ont pas cette distinction, et un caractère de l'un d'eux satisfait les deux règles à lui seul.

Les comptes qui se connectent uniquement par SSO ou par un annuaire n'ont pas de mot de passe local, l'expiration ne les concerne donc pas. Leurs règles se trouvent chez le fournisseur. Si un compte existant a été lié au SSO et possède encore son propre mot de passe, l'expiration et la politique de mots de passe continuent de s'appliquer à ce mot de passe.

La carte « 2FA Settings » détermine qui doit utiliser la connexion à deux facteurs. Sous « Two-factor requirement », tu choisis l'un des quatre niveaux : « Off », « Administrators only », « Administrators and agents » ou « Everyone ». « Everyone » inclut les clients. Une nouvelle installation commence avec « Administrators only ». Une installation qui existait déjà garde son réglage précédent après une mise à jour.

La personne qui se connecte ensuite sans second facteur en met un en place. Le système affiche un code QR pour une application d'authentification et la même clé à saisir à la main. Après le premier code, le facteur est actif. Avec « Set up later », la mise en place peut être reportée, et la connexion continue sans elle. Cela fonctionne pendant 7 jours au plus, comptés à partir du premier report. La ligne sous le bouton indique les jours restants. Ensuite, la mise en place est obligatoire.

Juste après, dix codes de secours apparaissent. Chacun d'eux remplace une fois le code de l'application. Ils sont affichés exactement une fois. Tu les sauvegardes avec « Copy » ou « Download ». « Download » fonctionne toujours. « Copy » fonctionne aussi la plupart du temps.

Si quelqu'un perd son appareil et ses codes, l'administrateur aide. Dans la liste des utilisateurs, le bouton avec le bouclier barré réinitialise la connexion à deux facteurs de cette personne. Elle la remet en place à la prochaine connexion.

Les codes dépendent de l'horloge du serveur. Si elle est fausse, aucun code n'est accepté. Le bouton « Check now » sur la même carte compare l'heure du serveur à une source de temps publique.

Si quelqu'un se connecte par un service de connexion externe, le système ne demande pas de code. Le fournisseur a déjà vérifié le second facteur. La connexion par annuaire est différente : là, la règle ci-dessus s'applique toujours.

Plus à ce sujet dans la carte : La connexion à deux facteurs dans ton propre profil

La page de connexion avec les champs « Username » et « Password » et le bouton « Sign in ».
Les cadres rouges entourent les deux champs et le bouton. Le champ du haut accepte aussi l'adresse e-mail.Ouvrir l'image en taille réelle
La carte « JWT token timer » avec le champ du nombre d'heures.
Le cadre rouge entoure le champ. Il accepte des valeurs de 1 à 24.Ouvrir l'image en taille réelle
La carte « Password policy » avec la longueur minimale, les types de caractères, l'expiration et la liste de blocage.
Les cadres rouges entourent les trois champs numériques. Les cases situées entre eux décident des types de caractères qui doivent apparaître.Ouvrir l'image en taille réelle
La carte « 2FA Settings » avec les quatre niveaux sous « Two-factor requirement ».
Le cadre rouge entoure les quatre niveaux. « Administrators only » est sélectionné, comme dans une nouvelle installation.Ouvrir l'image en taille réelle
L'écran de mise en place avec un code QR, une clé à saisir et le champ du premier code.
Le cadre rouge du haut entoure la clé. C'est la même chose que le code QR au-dessus, et elle aide quand la caméra ne lit rien. Celui du bas entoure « Set up later » et les jours restants.Ouvrir l'image en taille réelle
Dix codes de secours sur deux colonnes, avec « Copy » et « Download » en dessous.
Les cadres rouges entourent les codes et les deux boutons. Les codes apparaissent exactement une fois. Les codes de l'image viennent d'un système de test et n'ont aucune valeur.Ouvrir l'image en taille réelle
La liste des utilisateurs avec le bouton qui réinitialise la connexion à deux facteurs.
Le cadre rouge entoure le bouclier barré dans la ligne de Marco Rossi. Un clic lui retire son application et ses codes de secours.Ouvrir l'image en taille réelle
2

La connexion à deux facteurs dans ton propre profil

Chaque utilisateur peut activer la connexion à deux facteurs pour son propre compte. Cela vaut pour chaque rôle, même quand la carte « 2FA Settings » ne l'exige pas. Ouvre le menu utilisateur en bas à gauche de la barre latérale et choisis « Profile picture ». La même page contient la zone « Two-factor authentication ».

La zone indique si la connexion à deux facteurs est active. Tant qu'elle est désactivée, le bouton « Turn on » s'y trouve. Il demande d'abord ton mot de passe. Ensuite apparaissent un code QR pour l'application d'authentification et la même clé à saisir à la main. Après le premier code de l'application, le facteur est actif.

Juste après, dix codes de secours apparaissent. Sauvegarde-les avec « Copy » ou « Download ». « I have saved my codes » ferme la liste. Elle n'est affichée que cette seule fois.

Tant que la connexion à deux facteurs est active, la zone indique combien de codes de secours il reste. « New recovery codes » en crée dix nouveaux. Les anciens codes cessent alors de fonctionner. « Turn off » désactive de nouveau la connexion à deux facteurs. Les deux boutons demandent le code actuel de l'application. Un code de secours n'y est pas accepté.

Si la carte « 2FA Settings » exige la connexion à deux facteurs pour ton rôle, « Turn off » est absent. Une ligne dans la zone l'indique.

Un mauvais mot de passe ou un mauvais code compte comme une connexion échouée. La protection contre les tentatives de deviner un mot de passe s'applique donc ici aussi. L'activation et la désactivation sont inscrites dans le journal de sécurité. Si un administrateur désactive sa propre connexion à deux facteurs, le journal déclenche une alerte.

Les comptes qui se connectent uniquement par un service de connexion externe voient une phrase à la place des boutons. Leur fournisseur gère le second facteur. Les comptes issus d'un annuaire saisissent à la première étape leur mot de passe de l'annuaire.

Plus à ce sujet dans la carte : Se connecter avec un nom d'utilisateur et un mot de passe, Le journal de sécurité

La zone « Two-factor authentication » du profil avec l'état et le bouton « Turn on ».
Les cadres rouges entourent l'état et « Turn on ». Ici, la connexion à deux facteurs est encore désactivée.Ouvrir l'image en taille réelle
La première étape après « Turn on » : le champ « Password » avec « Continue » et « Cancel ».
Les cadres rouges entourent le champ du mot de passe et « Continue ». Le code QR n'apparaît qu'après le bon mot de passe.Ouvrir l'image en taille réelle
3

Protection contre les tentatives de deviner un mot de passe

La protection fonctionne sans aucun réglage. Il n'y a rien à activer. La remarque à ce sujet figure dans la carte « 2FA Settings ».

Elle fonctionne en deux niveaux. Après cinq tentatives ratées sur le même compte, l'adresse d'où elles venaient est mise en pause. La pause prend fin au plus tard 15 minutes après la première de ces tentatives. Depuis toute autre adresse, le compte reste utilisable tout de suite.

C'est la partie importante. Sinon, quiconque connaît un nom de connexion pourrait bloquer un collègue avec cinq mauvais mots de passe. Il n'aurait jamais besoin d'un mot de passe pour cela.

Le deuxième niveau est le compte lui-même. Il est verrouillé pendant 15 minutes après 20 tentatives ratées. Comme une seule adresse peut en fournir cinq au maximum, cela demande plusieurs adresses.

Une connexion réussie remet les deux compteurs à zéro. Après un redémarrage du serveur, la pause de l'adresse disparaît, le verrouillage du compte demeure. Les mêmes compteurs s'appliquent à la connexion par un annuaire. Un annuaire injoignable ne compte pas comme une tentative ratée. S'il n'existe pas encore de compte pour ce nom dans le système de tickets, seule la pause de l'adresse s'applique.

Dans la liste des utilisateurs, un compte verrouillé de cette façon porte la pastille « temporarily locked ». Il reste dans la liste. Après 15 minutes, la pastille disparaît d'elle-même.

Tu n'es pas obligé d'attendre. Dans la même ligne, il y a un bouton avec un cadenas ouvert. Il lève le verrouillage immédiatement et remet les deux compteurs à zéro.

Ce n'est pas la même chose que « Archive ». Ce bouton-là ferme un compte définitivement, et lui seul prend ou libère une place de personnel.

La remarque sur la protection contre les tentatives de deviner un mot de passe, dans la carte « 2FA Settings ».
Le cadre rouge entoure la remarque. Elle nomme les deux niveaux : l'adresse d'abord, le compte en dernier.Ouvrir l'image en taille réelle
La liste des utilisateurs avec la pastille « temporarily locked » et le bouton de déverrouillage.
Les cadres rouges entourent la pastille et le cadenas ouvert. Le cadenas n'apparaît que dans la ligne où il y a quelque chose à lever.Ouvrir l'image en taille réelle
4

Le journal de sécurité

Avant de commencer : Le journal se trouve sous « Settings → Security log ». Par défaut, seuls les administrateurs le voient. Tu le donnes à d’autres rôles avec l’autorisation « Security log » dans la carte « Permission concept ». Elle ne peut pas être donnée aux clients.

Le journal de sécurité enregistre deux sortes d’événements. Le domaine « Sign-in » contient les connexions échouées, les comptes verrouillés, les tentatives de connexion pendant un verrouillage, les codes à deux facteurs refusés et les changements de mot de passe. Cela vaut pour la connexion par mot de passe, via un annuaire et via SSO.

Le domaine « Administration » montre qui a modifié quoi. Cela couvre les comptes, les rôles, les autorisations, les paramètres de sécurité et les archives. Chaque export du journal y est aussi enregistré.

Les connexions réussies ne sont enregistrées que dans deux cas. Le premier cas est un administrateur. Le second cas est une connexion après des tentatives échouées sur le même compte. La connexion ordinaire d’un agent ou d’un client ne figure pas dans le journal. Le journal n’est pas une liste de présence.

Si quelqu’un se connecte avec un nom qui n’existe pas, l’entrée indique « unknown account ». Le système n’enregistre pas le nom saisi. C’est parfois un mot de passe tapé dans le mauvais champ.

Les événements de connexion enregistrent l’adresse IP et le navigateur. Les actions d’administration enregistrent qui les a effectuées, mais aucune adresse IP. Les mots de passe, les codes et le contenu des tickets ou des e-mails ne figurent jamais dans le journal.

La page montre d’abord les entrées les plus récentes, 50 par page. La carte « Filters » restreint la liste. « Area » choisit les connexions ou l’administration, « Event » un seul type d’événement. « Person » cherche dans le nom de celui qui a agi et de celui qui est concerné. « From » et « To » limitent les jours. « Failures only » masque tout ce qui a réussi.

Les filtres ne s’appliquent qu’après un clic sur « Apply ». « Reset » les retire.

« Export CSV » et « Export PDF » téléchargent exactement ce que montrent les filtres. Chaque fichier contient au maximum 10 000 entrées. Si plus d’entrées correspondent aux filtres, une remarque près des boutons d’export l’indique. Le PDF est dans ta langue et indique en haut les filtres et la période. La date et l’heure suivent le format réglé sous « Settings → General Settings ».

Le fichier CSV reste toujours en anglais, et les heures sont en UTC. Ainsi, un programme peut le lire quelle que soit la langue. Chaque export figure lui-même dans le journal, sous « Security log exported ».

Six événements déclenchent une alerte. Ce sont un compte verrouillé après des tentatives échouées, un rôle passé à « Admin », un compte créé directement avec le rôle « Admin » et une connexion à deux facteurs réinitialisée d’un administrateur. S’y ajoutent les tickets archivés retirés des données courantes et la connexion d’un administrateur après des tentatives échouées.

Après une alerte, toute personne qui a l’autorisation voit une bannière jaune en haut de chaque page. Elle indique le nombre d’alertes depuis sa dernière visite du journal. Le lien « Open security log » y mène. À l’ouverture du journal, la bannière disparaît. Avant la première visite, elle compte les alertes des sept derniers jours.

En plus, chaque compte actif qui a l’autorisation et une adresse e-mail reçoit un e-mail d’alerte. Le système regroupe les alertes toutes les 15 minutes et envoie un e-mail par personne, pas un par événement. L’e-mail indique l’événement, la personne concernée et l’heure. Il ne contient aucune adresse IP. L’e-mail d’alerte fait partie de Professional.

L’exécution nocturne supprime les anciennes entrées. Les délais se trouvent sous « Settings → Security », dans la carte « Data protection », bloc « Security log retention ». Par défaut, les événements de connexion sont conservés 90 jours ; de 7 à 365 jours sont autorisés. Par défaut, les actions d’administration sont conservées 12 mois ; de 1 à 120 mois sont autorisés.

Chaque délai a son propre interrupteur : « Delete old sign-in events » et « Delete old administrator actions ». Si un interrupteur est désactivé, ces entrées restent. La carte « Délais de conservation » explique l’exécution nocturne.

Lors d’une demande d’accès, la personne reçoit chaque entrée dans laquelle elle a agi ou a été concernée. L’adresse IP et le navigateur ne sont joints que pour les entrées qu’elle a déclenchées elle-même, par exemple sa propre connexion. Si la personne est anonymisée, le système supprime ses événements de connexion. Ses actions d’administration restent. Son nom y est remplacé par l’espace réservé.

Une remarque pour toi en tant qu’exploitant : les connexions réussies ne figurent dans le journal que pour les administrateurs et après des tentatives échouées. Le journal montre malgré tout qui a fait quoi et quand. Dans une entreprise dotée d’un comité social et économique, c’est donc un sujet de codécision.

Plus à ce sujet dans la carte : Protection contre les tentatives de deviner un mot de passe, Délais de conservation

La page « Security log » avec la carte « Filters » et la liste des entrées.
Le cadre rouge se trouve sur le verrouillage du compte de Lena Chen. En dessous figurent les tentatives échouées qui y ont mené, chacune avec son adresse IP. Les entrées de l’image proviennent d’un système de test.Ouvrir l'image en taille réelle
La carte « Filters » avec « Failures only » activé, les deux boutons d’export et les premiers échecs.
Les cadres rouges se trouvent sur « Failures only » et sur les deux exports. Les exports reprennent les filtres réglés ici.Ouvrir l'image en taille réelle
La bannière jaune au-dessus du tableau de bord avec le nombre d’événements de sécurité et le lien « Open security log ».
Le cadre rouge se trouve sur le lien vers le journal. Ici, c’est le verrouillage du compte de Lena Chen qui a déclenché l’alerte.Ouvrir l'image en taille réelle
Le bloc « Security log retention » avec deux interrupteurs, les jours et les mois.
Les cadres rouges se trouvent sur les deux délais. L’image montre le réglage par défaut : 90 jours et 12 mois.Ouvrir l'image en taille réelle
5

Se connecter par un annuaire ou un service externe (SSO)

Professional uniquement

Avant de commencer : Les réglages se trouvent sous « Settings → SSO Settings ». Sans fournisseur configuré, rien ne change sur la page de connexion.

Tout en haut se trouve l'interrupteur principal « Enable single sign-on ». Tant qu'il est désactivé, on reste au nom d'utilisateur et au mot de passe. Tout ce que tu configures en dessous est enregistré et ne prend effet qu'une fois que tu l'actives.

La carte « Active Directory / LDAP » relie un annuaire sur site. Tu saisis le serveur, la base de recherche, le filtre qui trouve une personne, et les champs de l'adresse e-mail et des noms.

Le compte utilisé pour les recherches est facultatif. Sans lui, le système interroge de façon anonyme. Le mot de passe d'une personne ne sert qu'à se lier à l'annuaire et n'est jamais enregistré.

Un annuaire n'apporte pas de second facteur propre. Si la page de sécurité exige la connexion à deux facteurs, on la demande aussi à ces personnes.

La carte « Identity providers » contient les services de connexion externes. Chacun reçoit sa propre tuile et son propre bouton sur la page de connexion. « Add provider » en crée un nouveau.

Sous « Provider type », tu choisis le type. « Generic OIDC Provider » convient à des services comme Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 ou Ping Identity. « SAML 2.0 Provider » convient aux mêmes maisons quand elles doivent être reliées par SAML.

À côté se trouvent six services régionaux : LINE, Kakao, Naver, WeChat, WeCom et DingTalk. Leurs adresses sont préremplies et apparaissent en gris dans le champ.

Le nom sous « Display name » apparaît ensuite sur le bouton. L'interrupteur à côté ne s'applique qu'à ce fournisseur.

Pour l'adresse de retour, procède dans cet ordre. Saisis d'abord seulement un nom et clique sur « Save provider ». Ce n'est qu'alors que le système connaît le numéro du fournisseur et affiche l'adresse complète sous « Redirect URI ». Elle est construite à partir de l'adresse publique de cette installation, celle enregistrée sous « Settings → Security ». C'est exactement l'adresse que le système utilise quand quelqu'un se connecte.

Tu copies cette adresse et tu l'enregistres chez le fournisseur. Elle doit y correspondre caractère par caractère. En retour, le fournisseur te donne un identifiant et un secret, et tu les saisis ici par « Edit ».

Le champ « Allowed e-mail domains » limite qui peut entrer par ce fournisseur. Laissé vide, tous les domaines sont autorisés.

S'il manque encore quelque chose à un fournisseur, sa tuile porte la pastille rouge « Incomplete ». Il n'apparaît alors pas sur la page de connexion. Le texte à côté indique les champs dont son type a besoin.

Les fournisseurs entièrement configurés n'apparaissent toujours pas tant que l'interrupteur principal est désactivé. La tuile le dit dans une ligne jaune.

Si ta licence repasse en Basic, la connexion par SSO et par l'annuaire continue de fonctionner. Sur cette page, tu peux alors seulement désactiver les fournisseurs et l'annuaire. Le journal des tentatives de connexion reste lisible.

La carte « Single sign-on » avec l'interrupteur principal.
Le cadre rouge entoure l'interrupteur principal. Quand il est désactivé, il ne reste que la connexion par nom d'utilisateur et mot de passe.Ouvrir l'image en taille réelle
La carte « Active Directory / LDAP » avec les champs remplis.
Les cadres rouges entourent le serveur, la base de recherche et le filtre de recherche. Les valeurs de l'image viennent d'un système de test.Ouvrir l'image en taille réelle
Deux tuiles de fournisseur, l'une configurée et l'autre portant la pastille « Incomplete ».
Les cadres rouges entourent les deux tuiles. Celle du haut est complète et n'attend que l'interrupteur principal. Celle du bas n'a pas l'adresse de son fournisseur.Ouvrir l'image en taille réelle
La boîte de dialogue « Add provider » avec le type, le nom affiché, l'interrupteur et l'adresse du fournisseur.
Le cadre rouge entoure le champ d'adresse. En dessous, « Quick fill » préremplit les fournisseurs connus. Ce qui figure entre accolades, tu le remplaces d'abord.Ouvrir l'image en taille réelle
La boîte de dialogue d'un fournisseur enregistré, montrant l'adresse de retour complète.
Le cadre rouge entoure l'adresse de retour. Elle ne naît qu'à l'enregistrement et commence par l'adresse de ta propre installation.Ouvrir l'image en taille réelle
6

Le compte à la première connexion, et le journal

Professional uniquement

L'interrupteur « Automatically create accounts on first sign-in » se trouve dans la même carte que l'interrupteur principal. Il est activé par défaut.

Quand quelqu'un se connecte pour la première fois par un fournisseur, le système cherche d'abord un compte qui appartient déjà à ce fournisseur. S'il n'en trouve aucun, un nouveau est créé.

Le nouveau compte reçoit le rôle « Customer » et aucune équipe. Un client n'a pas besoin d'appartenir à une équipe pour créer un ticket, il peut donc travailler tout de suite.

Les clients sont illimités dans les deux éditions, un compte créé ainsi n'utilise donc aucune place de personnel. Celui qui doit devenir agent reçoit le rôle ensuite dans la gestion des utilisateurs.

S'il existe déjà un compte avec la même adresse e-mail, les deux sont reliés. Cela n'arrive que si le fournisseur signale l'adresse comme vérifiée. Sinon, la connexion est refusée.

Si tu le désactives, seules les personnes qui ont déjà un compte entrent. Toutes les autres sont refusées.

La carte « Recent sign-in attempts », tout en bas, montre les 100 derniers événements de connexion via SSO et l’annuaire. Ils proviennent du journal de sécurité. Les tentatives échouées y figurent toujours. Une connexion réussie n’y figure que pour les administrateurs et après des tentatives échouées sur le même compte. Toutes les connexions n’apparaissent donc pas dans la liste.

Chaque ligne nomme l'heure, le fournisseur, le résultat et l'adresse d'origine. En cas d'échec, le motif figure à côté. La colonne « User » montre le nom du compte. S’il n’y a pas de compte, elle montre l’adresse communiquée par le fournisseur, sinon « unknown account ». Le système n’enregistre pas le nom saisi.

La connexion avec un nom d'utilisateur et un mot de passe n'apparaît pas dans ce tableau. Ce n'est pas du SSO. Tu la trouves dans le journal de sécurité.

Par défaut, les entrées sont supprimées au bout de 90 jours. La phrase sous le titre de la carte indique le délai réglé. La carte « Délais de conservation » explique ce réglage.

Plus à ce sujet dans la carte : Le journal de sécurité

L'interrupteur « Automatically create accounts on first sign-in ».
Le cadre rouge entoure l'interrupteur. Le texte en dessous nomme le rôle attribué à un tel compte.Ouvrir l'image en taille réelle
Le tableau « Recent sign-in attempts » avec trois tentatives échouées par l'annuaire.
Le cadre rouge entoure la ligne du haut. Elle montre une tentative échouée avec son motif. Les entrées de l'image viennent d'un système de test dont l'annuaire n'existe pas.Ouvrir l'image en taille réelle
7

Les cinq façons d'accéder au système

Avant de commencer : Tu choisis comment on accède au système dans le programme d'installation de SMITEY sur le serveur. Tu peux le modifier plus tard à tout moment.

Après l'installation, ton équipe utilise le système dans n'importe quel navigateur web. Le programme d'installation demande comment le système doit être joignable. Dans le programme d'installation Windows, tu le choisis sur la page « Accessibilité ». Sous Linux, install.sh pose la même question et numérote les options de 1 à 5. Plus tard, tu le modifies avec « Modifier la manière dont SMITEY est joignable ». Tes données restent où elles sont.

L'option « Réseau local uniquement, via l'adresse IP (HTTP) - option la plus simple » est le réglage par défaut. Ton équipe ouvre le système à http:// suivi de l'adresse IP du serveur et du port, par exemple http://192.168.1.20:8088. Le port est 8088, sauf si tu en choisis un autre. Le port 80 fonctionne aussi. L'adresse n'a alors pas besoin de port. Cette option n'a besoin ni d'un nom ni d'un certificat.

L'option « Dans le réseau local sous un nom propre (HTTP, HTTPS possible plus tard) - vous disposez d'un DNS interne » fonctionne comme la première, mais sous un nom comme ticket.company.local. Tu crées le nom toi-même dans ton DNS interne. Il pointe vers l'adresse IP du serveur. Ton équipe joint alors le système par le nom et toujours aussi par l'adresse IP. Le programme d'installation affiche ensuite l'adresse avec ce nom.

Avec les deux options HTTP, les mots de passe et les tickets traversent ton réseau en clair. Les administrateurs voient alors un avertissement en haut de la page.

Les trois autres options utilisent HTTPS : « Via un domaine public avec HTTPS (automatique, avec Let's Encrypt) », « Dans le réseau local avec HTTPS et votre propre certificat » et « Dans le réseau local avec HTTPS, certificat créé par SMITEY ». Elles ont besoin des ports 80 et 443 sur le serveur. La carte suivante les décrit.

Pour un premier test, la première option suffit. Si ton réseau a un DNS interne, choisis la deuxième. Si le système doit être joignable depuis Internet, choisis le domaine public. Si ton entreprise a sa propre autorité de certification, choisis ton propre certificat dans le réseau local. Sinon, laisse SMITEY créer le certificat.

Changer l'accès à SMITEY sous Linux

sudo bash /opt/smitey/install.sh --change-access

Affiche les variantes 1 à 5. Entrée seule garde la variante actuelle et ne change rien.

Plus à ce sujet dans la carte : Accéder au système en HTTPS

La page « Accessibilité » du programme d'installation Windows avec les cinq options.
Le texte au-dessus de la liste numérote les options de 1 à 5. Sous Linux, les mêmes textes apparaissent avec ces numéros.Ouvrir l'image en taille réelle
8

Accéder au système en HTTPS

Avant de commencer : Tu choisis le chemin vers HTTPS dans le programme d'installation de SMITEY sur le serveur, pas dans le navigateur.

Sans HTTPS, les mots de passe et les tickets traversent ton réseau en clair. Une nouvelle installation commence en simple HTTP, pour fonctionner tout de suite dans n'importe quel navigateur web. Tant qu'un administrateur ouvre le système en simple HTTP, un avertissement apparaît en haut de la page : « This connection is not encrypted. » Si le système est ouvert sur le serveur lui-même sous « localhost », l'avertissement n'apparaît pas. Les agents et les clients ne le voient jamais.

« How to switch on HTTPS » mène à cette carte. « Hide for 30 days » masque l'avertissement pour toi. Le réglage appartient à ton compte et vaut donc aussi dans un autre navigateur. Après 30 jours, l'avertissement revient tant que la connexion n'est toujours pas chiffrée.

Le programme d'installation de SMITEY met en place HTTPS de trois façons. Dans le programme d'installation Windows, tu choisis sur la page « Accessibilité », et sous Linux, install.sh pose la même question. Sur un système qui tourne déjà, ouvre « Modifier la manière dont SMITEY est joignable » sur le bureau Windows ou dans le menu Démarrer. Sous Linux, la commande ci-dessous fait la même chose. Tes données restent où elles sont.

L'option « Dans le réseau local avec HTTPS et votre propre certificat » utilise ton propre certificat, par exemple celui de l'autorité de certification de ton entreprise. Le programme d'installation demande le nom du système et le fichier du certificat avec sa clé. Un fichier PFX avec son mot de passe fonctionne aussi. Avant de modifier quoi que ce soit, il vérifie le certificat. La clé doit correspondre, le certificat doit être valide, et le nom doit figurer dans le certificat.

L'option « Dans le réseau local avec HTTPS, certificat créé par SMITEY » n'a pas besoin de ton propre certificat. SMITEY en crée un lui-même et le renouvelle aussi lui-même. Le programme d'installation enregistre le certificat racine sous le nom SMITEY-root-ca.crt dans le dossier d'installation. Installe ce fichier sur chaque ordinateur comme certificat racine de confiance, par exemple par une stratégie de groupe. Jusque-là, les navigateurs affichent un avertissement.

L'option « Via un domaine public avec HTTPS (automatique, avec Let's Encrypt) » obtient son certificat de Let’s Encrypt. Elle a besoin d'un domaine public qui pointe vers le serveur. Pour cela, le serveur doit être joignable depuis Internet.

Pour les deux options sur le réseau local, le nom peut être un nom comme ticket.company.local, un seul mot comme helpdesk ou une adresse IPv4. Les trois chemins ont besoin des ports 80 et 443 sur le serveur. Si un autre programme les utilise, le programme d'installation s'arrête et ne modifie rien. Le système est ensuite joignable à https:// suivi du nom, sans port.

Ton propre certificat expire un jour. À partir de 30 jours avant, les administrateurs voient en haut de la page un avertissement avec la date. À partir de 7 jours avant, il est rouge. En Professional, tous les administrateurs qui ont une adresse e-mail reçoivent en plus un e-mail 30 et 7 jours avant. Pour le renouveler, ouvre de nouveau « Modifier la manière dont SMITEY est joignable », choisis l'option avec ton propre certificat et indique les nouveaux fichiers.

Le fichier HTTPS-GUIDE.txt fourni avec l'installation décrit chaque étape. Cela comprend la diffusion du certificat racine et les étapes à la main.

Changer l'accès à SMITEY sous Linux

sudo bash /opt/smitey/install.sh --change-access

Affiche les variantes 1 à 5. Entrée seule garde la variante actuelle et ne change rien.

L'avertissement « This connection is not encrypted. » au-dessus de la liste des tickets, avec le lien et « Hide for 30 days ».
Les cadres rouges entourent le lien vers cette carte et « Hide for 30 days ». Seuls les administrateurs voient l'avertissement.Ouvrir l'image en taille réelle

Gestion des tickets

Le métier au quotidien : créer des tickets, les trier, les retrouver. Tout ce qui est dans ce bloc fait partie de Basic, sauf mention contraire sur une carte.

1

Créer et modifier des tickets

Avant de commencer : Un ticket ne peut pas être supprimé individuellement, pas même par un administrateur. Les tickets ne quittent la base de données que par l'archive, et seulement une fois fermés. C'est voulu : un dossier que quelqu'un peut faire disparaître sans laisser de trace n'a aucune valeur comme preuve.

Tu crées un nouveau ticket avec « New Ticket » dans la barre de gauche. Le formulaire s'appelle « Create new ticket ». En tant qu'agent, tu enregistres aussi les demandes des autres avec lui. C'est à cela que sert le champ « User » : il dit pour qui est le dossier, pas qui le saisit.

Tout ce qui porte une étoile est obligatoire : « Title », « User », « Main category » et « Description ». Il y en a un de plus, facile à manquer : le formulaire ne s'enregistre pas sans sous-catégorie, même si « Subcategory » ne porte pas d'étoile. Une catégorie principale et une sous-catégorie vont ensemble et se règlent toujours par paire.

Les champs obligatoires se règlent sous « Settings → Ticket Settings ». La carte « Admin / Agent Field Settings » n'a pour cela que l'interrupteur « Field is mandatory ». La carte « Customer Field Settings » a en plus « Is hidden for Customer » et « Is not editable ». C'est pourquoi un client peut voir un formulaire plus court que le tien, sans que personne ait à entretenir deux formulaires. « Title » et « Description » sont toujours obligatoires. Cela ne peut pas être désactivé.

Ensuite, tu peux presque tout changer : à droite du ticket se trouve la carte « Details » avec le demandeur, le téléphone, l'adresse e-mail, le site, la catégorie et le numéro de référence. Tu modifies le champ lui-même et tu confirmes avec le « Save » en dessous. Le statut, l'attribution, la priorité, le canal et les observateurs se trouvent une carte plus haut sous « Actions ». Le statut et l'attribution prennent effet immédiatement. La priorité, le canal et les observateurs ne sont enregistrés qu'avec le « Save » de la carte « Details ».

Seuls les agents et les administrateurs peuvent changer cela. Le demandeur peut lire le dossier, le commenter et y joindre des fichiers, mais pas modifier la classification sur laquelle tes rapports sont construits.

Un effet à connaître une fois pour toutes : si tu modifies un ticket qui n'appartient encore à personne, il est ensuite à toi. Le système t'inscrit comme agent et fait passer le statut de « Open » à « Assigned », les deux se retrouvent dans l'historique. Si tu ne voulais pas cela, attribue-le ensuite à quelqu'un d'autre.

Chacun de ces changements arrive dans l'historique du ticket, avec le nom, l'heure, l'ancienne valeur et la nouvelle. Tu n'as rien à activer pour cela.

Reste la question de savoir comment se débarrasser des tickets. Sous « Settings → Archive », tu choisis une période, tu vois avec « Preview » combien de tickets fermés elle contient, et tu crées un fichier ZIP avec « Create archive » : tickets, commentaires, historique, champs personnalisés et pièces jointes, le tout dans un seul fichier. Le créer ne supprime rien. Les tickets ne quittent la base de données en fonctionnement qu'avec l'étape à part « Delete from live DB » dans la liste « Existing archives », et ils peuvent être restaurés depuis ce même fichier.

Le formulaire « Create new ticket » avec les champs Title, Owning team, User, statut, priorité, canal et observateurs.
Le formulaire derrière « New Ticket ». Les champs marqués d'une étoile sont obligatoires ; les catégories, la description et les pièces jointes suivent plus bas.Ouvrir l'image en taille réelle
La carte « Details » d'un ticket avec les champs du demandeur et le bouton « Save » encadré en rouge.
Changer après coup : modifie le champ, appuie sur « Save ». En dessous figure, sans possibilité de modification, qui a créé le ticket et quand.Ouvrir l'image en taille réelle
2

Éditeur de texte enrichi pour la description et les commentaires

La description et les commentaires ne sont pas de simples zones de texte. Chacune a une barre d'outils au-dessus, et les boutons disent ce qu'ils font quand tu les survoles : « Bold », « Italic », « Underline », « Strikethrough », « Text color », « Highlight color », « Bullet list », « Numbered list », « Quote », « Link » et « Clear formatting ».

Voici comment on fait un lien : sélectionne le texte, clique sur « Link », saisis l'adresse dans la petite invite. Une saisie vide retire le lien. Les adresses web et de messagerie sont autorisées (http, https, mailto). Tout le reste est écarté à l'enregistrement, pour qu'un commentaire ne puisse rien faire passer à personne.

Les images passent par le presse-papiers : fais une capture d'écran et colle-la directement dans l'éditeur avec Ctrl+V. Au début, le texte n'affiche qu'un marqueur comme « [inline-image:1] ». À l'enregistrement, le système envoie l'image et l'affiche exactement là. Elle arrive aussi dans l'onglet « Attachments », où se trouvent tous les fichiers du dossier. Coller des images fonctionne dans la description d'un ticket existant et dans un nouveau commentaire. Cela ne fonctionne pas dans le formulaire « Create new ticket » ni pendant que tu modifies un commentaire.

Ce que tu vois est ce que les autres voient : la mise en forme, les listes et les liens sont conservés dans le ticket, et dans le message au demandeur également. Le balisage étranger, venu par exemple d'une page web copiée ou d'un e-mail entrant, est ramené à cet ensemble autorisé. Rien de ton texte n'est perdu au passage, seulement l'emballage.

Un commentaire peut être marqué comme interne avec « Internal note (not visible to the customer) ». Il porte alors la pastille « Internal » et est invisible pour le demandeur. Même la recherche ne le fait pas apparaître.

Chacun peut modifier et supprimer ses propres commentaires. Ce qu'un client a écrit ne peut être modifié ou supprimé que par ce client ou par un administrateur. Cela inclut ses e-mails. Les commentaires des collègues peuvent être modifiés et supprimés par tout agent qui peut travailler sur le ticket. Cela inclut une équipe qui avait le ticket auparavant.

La barre d'outils de l'éditeur, en dessous la phrase « The display shows ERROR 13.20 and then the paper jams. » avec le code d'erreur en gras.
Encadrés en rouge : « Bold », « Bullet list » et « Link ». La barre se trouve aussi bien au-dessus de la description qu'au-dessus de la zone de commentaire.Ouvrir l'image en taille réelle
Trois commentaires d'un ticket, celui du bas avec un terme en gras et une liste à puces, celui du milieu portant la pastille « Internal ».
Voilà le résultat : le texte en gras et la liste sont conservés. Le commentaire du milieu est marqué « Internal » et invisible pour le demandeur.Ouvrir l'image en taille réelle
3

Pièces jointes avec aperçu

Avant de commencer : Sont autorisés les fichiers PDF, DOC, DOCX, XLS, XLSX, TXT, PNG, JPG, JPEG et GIF, jusqu'à 50 Mo par fichier. La limite est indiquée dans le formulaire (« Max. 50 MB per file »), et les fichiers plus gros sont refusés avant le début de l'envoi.

Les fichiers appartiennent au dossier, pas à un commentaire isolé. Sur le ticket, l'onglet « Attachments » mène à la liste : « Upload file » en ajoute un, chaque ligne nomme le fichier, sa taille et sa date. Toute personne impliquée dans le ticket peut joindre quelque chose, le demandeur compris. Personne n'a donc besoin de t'envoyer sa capture d'écran par courrier électronique. Un client ne peut supprimer que les pièces jointes qu'il a envoyées lui-même. Quand un sous-ticket est fermé, ses pièces jointes sont copiées dans le ticket principal, où elles portent la pastille « Internal ». Les agents les voient ; les clients ne les voient pas et ne les téléchargent pas.

Un clic sur le nom ouvre l'aperçu, sans que tu doives télécharger le fichier. Pour les images, tu peux y agrandir, réduire et pivoter, ce qui est utile pour un écran photographié de biais. Un PDF s'affiche dans la même fenêtre, avec l'aperçu des pages, le zoom et l'impression. Les fichiers texte sont affichés comme du texte. Avec « Open in new tab », tu ouvres le fichier dans une fenêtre à part.

Une pièce jointe appartient au dossier et le suit : elle apparaît dans l'historique (« File uploaded: … »), survit à une transmission vers une autre équipe, et se retrouve dans le fichier d'archive quand le ticket est archivé.

L'onglet « Attachments » avec deux fichiers, au-dessus le bouton « Upload file » encadré en rouge.
Tous les fichiers d'un dossier au même endroit. La ligne en dessous nomme les types de fichiers autorisés et la limite de taille.Ouvrir l'image en taille réelle
L'aperçu d'une image jointe avec les boutons d'agrandissement, de réduction et de rotation en haut à droite.
L'aperçu d'une image : agrandir, réduire, pivoter, en haut à droite. Rien n'est téléchargé au passage.Ouvrir l'image en taille réelle
L'aperçu d'un PDF dans la même fenêtre, avec l'aperçu des pages à gauche et la barre d'outils du lecteur PDF en haut.
Un PDF s'ouvre de la même façon, sans téléchargement, avec l'aperçu des pages, le zoom et l'impression.Ouvrir l'image en taille réelle
4

Historique du ticket

L'onglet « History » du ticket répond à la question qui se pose à chaque reprise : qui a changé quoi, et quand ? Chaque ligne nomme la personne, le champ, l'ancienne valeur barrée, la nouvelle derrière et l'heure à la seconde près. L'entrée la plus récente est en haut.

Les entrées s'écrivent sans que tu fasses rien : lors des changements de statut, de priorité, d'attribution, de catégorie, de site, d'observateurs, de titre et de description, ainsi qu'à la création (« Ticket opened »), à chaque commentaire et à chaque fichier envoyé. Le nombre sur l'onglet te dit à l'avance combien de mouvement il y a eu dans le dossier.

L'historique ne peut pas être modifié ni désactivé. C'est exactement ce qui le rend utile : c'est la raison pour laquelle un ticket ne peut pas être supprimé un par un, et il part dans le fichier d'archive quand le ticket est archivé.

Pour un commentaire, l’historique enregistre seulement qu’il a été ajouté, modifié ou supprimé. Le texte se trouve dans l’onglet « Comments ». Un commentaire interne apparaît lui aussi dans l’historique, mais seulement pour les agents et les administrateurs.

L'onglet « History » avec les entrées de ce ticket : fichiers, commentaires, changements de statut, priorité, attribution et, tout en bas, l'ouverture, avec deux lignes en haut écrites par une règle.
Encadré en rouge, l'onglet avec le compteur. Sur « Status » et « Priority », tu vois l'ancienne valeur barrée à côté de la nouvelle.Ouvrir l'image en taille réelle
5

Workflow de statuts avec statuts et transitions configurables

Le statut dit où en est un ticket. Douze statuts sont livrés avec le système : Open, Assigned, In Progress, Waiting for User Response, Resolved, Closed et d'autres. Tu les trouves sous « Settings → General Settings » dans la section « Drop-down lists », derrière l'onglet « Status ». « + Add status » en crée un à toi, « Edit status » en ouvre un existant.

Le point important est la différence entre le nom et la signification. Dans l'éditeur d'un statut, sous « Meaning of this status », il y a trois interrupteurs : « Counts as resolved », « Counts as closed » et « Waiting for the requester ». Seuls ces interrupteurs disent au système comment traiter un statut.

Tu peux renommer chaque statut, y compris ceux livrés avec le système : en bas de l'éditeur, sous « Translations », il y a un champ « Name » par langue. Mets-y ce que tes collègues doivent lire. Le nom technique derrière reste intact, et c'est justement pour cela que rien ne casse : l'automatisation, les rapports et les interrupteurs au-dessus se rattachent à ce nom, pas à ton étiquette. « Resolved » peut donc devenir « Terminé ».

La suppression, en revanche, ne fonctionne pas pour tous. Huit statuts portent la pastille « Mandatory » dans la liste : Open, Assigned, In Progress, Resolved, Closed, Reopened, Waiting for approval et Rejected. Ils peuvent être renommés et réordonnés, mais pas supprimés ; un essai se termine par un message clair. Ce n'est pas là pour t'embêter : des processus s'y rattachent qui s'arrêteraient sinon sans un mot, par exemple la fermeture automatique, qui a besoin d'un statut « résolu » comme point de départ.

Deux statuts appartiennent au système lui-même : « Waiting for approval » et « Rejected » portent la pastille « System only ». Ils viennent d'un processus d'approbation, et personne ne doit pouvoir affirmer à la main que quelque chose a été refusé alors que rien n'a jamais été soumis à décision.

Ce que font les trois : un statut qui compte comme résolu ferme le ticket de lui-même au bout de 24 heures. Un statut qui compte comme fermé est l'état final dans lequel le ticket est placé. Et « Waiting for the requester » veut dire exactement cela : nous attendons le demandeur, pas une autre équipe et pas un prestataire. C'est le drapeau sur lequel l'horloge du SLA s'arrête, si tu l'as réglé ainsi.

En dessous se trouve « Allowed transitions to new status ». Tu y coches les statuts qui peuvent être atteints depuis celui-ci. Laisse tout vide et rien n'est limité ; coche quelque chose et tous les autres chemins sont fermés. C'est ainsi qu'on construit un déroulé qu'on ne peut pas sauter, par exemple : depuis « Open », on ne peut aller que vers « In Progress » ou « Assigned », mais pas directement vers « Closed ».

Les autres interrupteurs de l'éditeur sont de petites choses au grand effet : la couleur pour la liste, « Sort order » pour l'ordre, « Show status in new ticket form » (ce statut doit-il pouvoir être choisi à la création d'un ticket ?), « Requires comment in dialog » (imposer un motif) et « System only » pour les statuts que seul le système peut poser.

Jusqu'à quatre statuts apparaissent sur le ticket sous forme de boutons sous « Change Status to: ». Tu les choisis dans l'éditeur avec l'interrupteur « Set as primary status (max. 4) ». Dans le réglage d'usine, ce sont In Progress, Waiting for User Response, Waiting for Service Provider Response et Resolved. Tous les autres statuts se trouvent sous « More statuses ».

Les paramètres généraux avec l'onglet « Status » encadré en rouge et la liste de tous les statuts.
« Settings → General Settings », onglet « Status » : chaque statut avec son nom technique et ses marques.Ouvrir l'image en taille réelle
La boîte de dialogue « Edit status » avec les interrupteurs sous « Meaning of this status » et la liste « Allowed transitions to new status ».
Dans l'éditeur : l'apparence et le comportement en haut, la signification au milieu, les transitions autorisées en bas.Ouvrir l'image en taille réelle
7

Les catégories principales et les sous-catégories sont librement configurables par équipe

Avant de commencer : Il te faut au moins une équipe. La page des catégories porte le nom de son équipe, elle n'existe donc qu'une fois que tu en as créé une.

Les catégories sont ce que le demandeur ou l'agent choisit à la création d'un ticket, et ce selon quoi tu regroupes ensuite tes rapports. Chaque équipe a les siennes : un helpdesk trie selon d'autres critères qu'un service réseau, et aucun des deux ne voit les listes de l'autre.

Tu les trouves sous « Settings » à l'entrée « <nom de l'équipe> Categories ». Dans l'exemple, l'équipe s'appelle « Helpdesk », l'entrée se lit donc « Helpdesk Categories ».

La page a trois cartes : « Main categories », « Subcategories » et « Links ». Le démarrage le plus rapide : saisis le nom anglais dans le champ « EN (required) » et clique sur « + New main category » ou « + New subcategory ». Tu traduis tout plus tard en une seule fois sur la page de traduction, il n'y a rien à préparer ici pour cela.

Si beaucoup de catégories t'attendent, prends la voie du fichier : « Export JSON » télécharge la structure. Sur un système fraîchement installé, le fichier est vide et ne fait que te montrer la disposition. Tu le remplis, à la main ou avec l'aide d'une intelligence artificielle, tu l'enregistres et tu le renvoies par « Import JSON ». Ce n'est pas un moyen de renommer : tu changes un nom dans le champ de la catégorie concernée et tu confirmes avec le « Save » à côté, la page le dit également.

La troisième carte, « Links », est là où se fait le vrai travail. Choisis une catégorie principale en haut, coche en dessous les sous-catégories qui lui appartiennent, et enregistre avec « Save links ». L'astuce : une sous-catégorie peut se rattacher à plusieurs catégories principales. Tu n'as donc besoin de « Malfunction » qu'une fois et tu la réutilises pour Printer, Network, Meeting-Room et Notebook.

À partir de là, les catégories sont disponibles dans le ticket. La suppression peut échouer tant que des tickets utilisent encore une catégorie. C'est voulu, sinon d'anciens tickets perdraient leur classification. Si tu retires une liaison, les tickets qui utilisent ce couple peuvent toujours être enregistrés. Seule une catégorie nouvellement choisie est vérifiée par rapport aux liaisons.

Si tu transmets un ticket à une autre équipe, sa classification reste, même quand la nouvelle équipe n'a pas du tout ces catégories. Elle figure alors dans le champ avec son origine, par exemple « Meeting-Room · from Helpdesk », et elle est grisée : la nouvelle équipe voit sous quoi le dossier a couru jusque-là, mais ne peut pas attribuer cette entrée elle-même. Pour le reclasser, tu choisis dans ta propre liste, et le système veut alors une catégorie principale et une sous-catégorie ensemble.

Le menu des paramètres ouvert avec l'entrée « Helpdesk Categories » encadrée en rouge.
Sous « Settings », l'entrée porte le nom de l'équipe, ici « Helpdesk Categories ».Ouvrir l'image en taille réelle
La page « Settings · Manage categories » avec les cartes « Main categories » et « Subcategories ».
Voilà la page : les catégories principales à gauche, les sous-catégories à droite. La carte « Links » se trouve plus bas sur la même page, elle vient dans un instant.Ouvrir l'image en taille réelle
Le champ « EN (required) » contenant le mot « Beamer » et le bouton « New main category », tous deux encadrés en rouge.
Une par une : le nom anglais dans le champ « EN (required) », puis un clic sur « + New main category » en dessous. Dans la carte « Subcategories », le bouton s'appelle « + New subcategory ».Ouvrir l'image en taille réelle
La carte « Main categories » avec les boutons « Export JSON » et « Import JSON » encadrés en rouge.
Pour en faire beaucoup à la fois : télécharger la structure, la remplir, la renvoyer. La carte « Subcategories » à côté a les deux mêmes boutons.Ouvrir l'image en taille réelle
La carte « Links » : « Printer » est sélectionné, les sous-catégories Consumables, Malfunction et New request sont cochées.
« Printer » sélectionné, les sous-catégories correspondantes cochées, « Save links ». « Malfunction » se rattache en même temps à trois autres catégories principales.Ouvrir l'image en taille réelle
8

Comment le ticket est arrivé

Chaque ticket porte un canal. Il se trouve dans le formulaire, puis sur la carte « Actions » sous « How the request came in », et il répond à une question qui devient vite importante dans les rapports : le travail arrive-t-il par le portail ou par téléphone ?

Tu ne peux choisir que ce qu'une personne sait et que le système ignore : « Phone » et « Entered by an agent ». Les deux autres valeurs sont posées par le système lui-même : « Self-service » quand le demandeur a créé le ticket dans le portail, et « E-mail » quand il est né d'un message entrant. Quand un agent crée un ticket, le formulaire commence avec « Entered by an agent ».

Un canal posé par le système ne peut plus être modifié par personne après coup. Le champ indique alors « Recorded by the system. It cannot be changed. » Sinon, le champ perdrait justement l'information pour laquelle il existe. Dans l'autre sens, sur un ticket enregistré par téléphone, tu peux encore tout changer.

Seuls un agent ou un administrateur peuvent poser le canal. Pour le demandeur, ce serait une affirmation sur son propre dossier, et les rapports dépendraient de l'honnêteté de chacun.

« E-mail » exige une boîte aux lettres connectée, qui fait partie de l'édition Professional. Les trois autres canaux existent dans les deux éditions.

La partie du formulaire avec le statut, la priorité et la liste ouverte du champ « How the request came in », encadrée en rouge.
À la création d'un ticket, le canal se trouve entre la priorité et les observateurs. Seuls « Phone » et « Entered by an agent » sont proposés.Ouvrir l'image en taille réelle
La carte « Actions » d'un ticket, le champ « How the request came in » indique « Phone » et est encadré en rouge.
Sur le ticket, le canal se trouve sur la carte « Actions ». Ici, un dossier qu'un agent a enregistré après un appel téléphonique.Ouvrir l'image en taille réelle
10

Choisir les colonnes de la liste des tickets

Chacun compose sa propre liste de tickets. Pour cela, le bouton « Columns » se trouve à côté de « Filter ». Il ouvre la boîte de dialogue « Choose columns ».

Dans la boîte de dialogue, tu coches chaque colonne que tu veux voir. Les flèches à côté fixent l'ordre. « # » et « Title » sont toujours inclus. Tu changes la largeur d'une colonne dans la liste elle-même, en faisant glisser le bord de son en-tête.

« Save » enregistre ton choix avec ton compte utilisateur. Il s'applique donc sur chaque ordinateur et reste après ta déconnexion. « Default columns » remet la liste dans son réglage d'usine.

Quand la place manque pour toutes les colonnes, celles tout à droite disparaissent en premier. « # », « Title » et « Status » restent toujours. Tu places donc devant ce qui compte le plus pour toi.

Avec Professional, tes champs personnalisés sont aussi proposés. Ils apparaissent dans la boîte de dialogue sous leur propre nom, ici par exemple « Asset tag ».

Les clients peuvent organiser leur liste de la même façon, mais on leur propose moins de colonnes. « Team », « Created by », « Last activity », « Status changed at », « Deadline », « Follow-up » et « Time » ne sont pas disponibles pour eux. Les champs que tu as cachés aux clients n'apparaissent pas non plus comme colonne.

Sur un téléphone, le bouton n'est pas affiché. La liste y montre les colonnes qui tiennent.

La liste des tickets avec les colonnes #, Title, Status, Assigned, Priority, Category et Asset tag. Le bouton « Columns » est encadré en rouge.
Ici, « Assigned » vient juste après le statut, « Follow-up » est désactivée. « Created » est aussi choisie, mais ne tient plus dans la largeur.Ouvrir l'image en taille réelle
La boîte de dialogue « Choose columns » avec une case à cocher et des flèches pour chaque colonne, et les boutons « Default columns », « Cancel » et « Save ».
Les colonnes choisies sont en haut dans leur ordre, toutes les autres en dessous.Ouvrir l'image en taille réelle
11

Transmettre un ticket à une autre équipe

Professional uniquement

Avant de commencer : Les deux voies demandent une deuxième équipe. Le client ne voit pas le changement dans l'historique : pour lui, cela reste un dossier avec un numéro, quel que soit le nombre d'équipes qui y ont travaillé. Le nouveau statut « Open » après une transmission lui est visible dans l'en-tête du ticket.

Le ticket propose deux boutons côte à côte pour cela, et la différence est imprimée en dessous en petits caractères. « Involve another team » : tu restes responsable, l'autre équipe travaille à tes côtés dans un ticket lié. « Escalate to another team » : l'autre équipe prend le relais.

Quand tu transmets, la responsabilité change de mains sans qu'un second ticket naisse. Ton équipe garde l'accès en lecture et peut encore commenter, mais ne peut plus rien changer, ce que la boîte de dialogue te dit exactement avant que tu confirmes. Tu y choisis l'équipe cible et tu peux ajouter un motif.

Quand tu associes une équipe, ton ticket reste entre tes mains et reçoit un sous-ticket dans l'autre équipe. Le tien passe au statut « Waiting for other team » ; dès que l'autre équipe ferme le sien, le tien revient en « Back from other team ». Tu n'as donc pas à demander s'il s'est passé quelque chose là-bas. Les pièces jointes du sous-ticket sont copiées dans ton ticket avec la pastille « Internal », et le client ne les voit pas.

Quant à la classification : les catégories de l'équipe qui transmet restent sur le ticket, même quand la nouvelle équipe ne les a pas du tout. Elles y apparaissent avec leur origine, en grisé. Ainsi, la nouvelle équipe voit sous quoi le dossier a couru jusque-là et peut le reclasser dans sa propre liste si besoin.

Seule la personne responsable à l'instant peut transmettre un ticket. Une étape précédente voit encore le dossier mais ne peut pas le transmettre une seconde fois. Elle peut commenter, mais ne peut pas reprendre le ticket pour elle-même.

Dans la liste de ton équipe, le ticket affiche alors « Waiting for other team » tant que l'autre équipe travaille dessus. La case « Also show tickets this team handed over » est cochée comme réglage d'usine, et le choix propre à chaque utilisateur est conservé. Pour l'autre équipe, le ticket commence en « Open ».

Qui transmet le ticket en devient observateur. La boîte de dialogue le dit avant que tu confirmes. En tant qu'observateur, tu reçois un e-mail quand le statut change, quand le ticket est fermé ou quand quelqu'un commente. Comme tout observateur, tu te retires avec « Stop observing ».

Les deux boutons « Involve another team » et « Escalate to another team » encadrés en rouge, avec leurs explications en dessous.
Deux voies, visiblement séparées : laisser quelqu'un travailler à tes côtés, ou transmettre. La différence est imprimée juste sous le bouton.Ouvrir l'image en taille réelle
La boîte de dialogue « Escalate to another team? » avec le choix de l'équipe cible et le champ « Reason (optional) ».
La boîte de dialogue nomme la conséquence avant que tu confirmes : pas de second ticket, l'accès en lecture reste, seule la nouvelle équipe peut changer quelque chose.Ouvrir l'image en taille réelle
12

Champs personnalisés

Professional uniquement

Quand une information manque à tes tickets, le numéro d'inventaire, la fin de la garantie, le centre de coûts, tu l'ajoutes toi-même. Sous « Settings → Ticket Settings », tout en bas, se trouve la carte « Custom fields » ; le bouton s'appelle « Add custom field ».

Dans la boîte de dialogue, tu donnes un nom et un type de champ : « Text », « Multiline text », « Integer », « Decimal », « Date » ou « Yes / No ». Le type décide de ce qui peut être saisi. Un champ de date n'acceptera pas « la semaine prochaine », et c'est justement pour cela que tu pourras en faire un rapport plus tard.

Sous « Scope », tu décides où le champ s'applique : « All teams (including new ones) » ou « Selected teams only ». Le premier choix couvre aussi les équipes qui n'existent pas encore, le genre de différence qu'on ne remarque qu'un semestre plus tard.

Les trois interrupteurs sous « Defaults » sont « Mandatory by default », « Hidden for customer by default » et « Not editable by customer by default ». Ils ne s'appliquent à un champ que tant que rien n'a été enregistré pour ce champ dans les réglages du champ sur la même page. Dès que tu le règles là, ce sont les réglages du champ qui décident.

Sur le ticket, les champs personnalisés se trouvent dans une carte à part, « Additional information », entre la description et les commentaires. Sans modèle, le formulaire montre tous les champs personnalisés de l'équipe. Si tu choisis un modèle à la création d'un ticket, il montre exactement les champs que ce modèle liste, dans son ordre : « seulement les champs dont ce dossier a besoin ».

Un modèle peut en plus rendre un champ obligatoire. Ce que l'administrateur a caché aux clients reste caché, même quand un modèle le liste. Un champ obligatoire qu'un modèle ne liste pas n'est pas demandé, cette exigence ne s'applique donc pas aux tickets créés avec ce modèle.

Le nombre de champs personnalisés qu'une équipe peut avoir se règle sous « Settings → General Settings » dans la carte « Custom fields limit ». Tu te débarrasses d'un champ avec « Deactivate » : il disparaît du formulaire, mais ses valeurs restent sur les anciens tickets. L'interrupteur « Show deactivated » le ramène dans la liste.

La carte « Custom fields » avec trois champs et le bouton « Add custom field » encadré en rouge.
La liste des champs personnalisés se trouve sous « Settings → Ticket Settings », en bas de la page.Ouvrir l'image en taille réelle
La boîte de dialogue « New custom field » avec le nom, le type de champ, la portée et les trois valeurs par défaut.
Un nom, un type de champ, une portée : un champ n'a pas besoin de plus. Les trois interrupteurs en dessous sont des valeurs par défaut.Ouvrir l'image en taille réelle
La carte « Additional information » sur un ticket avec les champs « Asset tag », « Warranty until » et « Cost centre ».
Voilà comment l'agent voit les champs personnalisés : une carte à part sur le ticket, juste sous la description.Ouvrir l'image en taille réelle
13

Observateurs

Parfois, quelqu'un doit suivre un dossier sans y travailler : le responsable d'équipe sur une affaire délicate, le collègue qui reprend la semaine prochaine. C'est à cela que servent les observateurs. Sur le ticket, le champ « Observers » se trouve sur la carte « Actions », le bouton s'appelle « Add observer » ; le formulaire « Create new ticket » a le même champ. Sur le ticket, un changement à cet endroit est enregistré avec le « Save » de la carte « Details ».

Seuls les agents et les administrateurs de l'équipe à laquelle appartient le ticket peuvent être choisis. Un client ne peut pas être observateur, il recevrait sinon des messages sur le travail interne.

Un observateur reçoit un e-mail quand quelque chose se passe sur le ticket : un nouveau commentaire, un statut modifié, une nouvelle attribution, des champs modifiés. L'envoi n'est pas immédiat mais groupé : après le dernier changement, le système attend une minute et envoie ensuite UN message qui couvre tout ce qui s'est passé pendant ce temps. Traiter un ticket d'une traite ne déclenche donc pas sept messages. Si plusieurs commentaires arrivent pendant ce temps, ils figurent tous dans le message.

Qui observe fait partie de l'historique : un changement est consigné comme n'importe quel autre, avec l'ancien et le nouvel état.

Saisir des observateurs fait partie de Basic. Le message aux observateurs fait partie de Professional, car il a besoin de l'envoi de courrier. Sans cela, tu peux saisir des observateurs, mais rien ne part. Un observateur peut se retirer lui-même avec le bouton « Stop observing ». Il n'a pas besoin pour cela du droit de modifier le ticket.

Un observateur s'ajoute aussi automatiquement : qui transmet un ticket avec « Escalate to another team » en devient observateur. Il apprend ainsi ce que l'autre équipe en fait.

La carte « Actions » d'un ticket avec la section « Observers » encadrée en rouge : le bouton « Add observer » et un agent en dessous.
L'observateur se trouve sur la carte « Actions ». Le ticket n'est attribué à personne : observer un ticket et y travailler sont deux choses différentes.Ouvrir l'image en taille réelle
14

Travailler sur le même ticket en même temps

Quand deux personnes travaillent sur le même ticket en même temps, l’enregistrement le plus tardif pourrait écraser le précédent, et personne ne le remarquerait. C’est pourquoi le ticket montre qui d’autre l’a ouvert. Il refuse aussi un enregistrement qui repose sur un état périmé.

L’indication se trouve dans l’en-tête du ticket. « Marco Rossi is viewing this ticket » signifie que Marco a le ticket ouvert. « Marco Rossi is actively editing this ticket » signifie que Marco a des saisies non enregistrées. Il peut s’agir d’une réponse commencée, d’un commentaire en cours de modification, du titre ou de la description en mode édition, d’un suivi, d’un champ personnalisé ou d’une saisie de temps. Les champs modifiés dans les cartes « Actions » et « Details » comptent aussi, tant qu’ils n’ont pas été enregistrés avec « Save ». Une fenêtre ouverte sur le ticket compte également. Ce sont les fenêtres « Involve another team? », « Escalate to another team? », « Close ticket », « Resolve incident » et « Start a workflow », ainsi que la fenêtre du commentaire lors d’un changement de statut. Après deux minutes sans saisie, l’indication affiche de nouveau « viewing », même si le brouillon est toujours là.

Si plusieurs collègues ont le ticket ouvert, l’indication les regroupe, par exemple « Marco Rossi and 2 more are viewing this ticket ». Pointe sur l’indication pour voir tous les noms. Dès que quelqu’un modifie activement, la ligne ne compte plus que les personnes qui modifient. Tu ne te vois jamais toi-même. Si tu as le ticket ouvert dans deux onglets, tu comptes une seule fois. Si le ticket n’est ouvert que dans un onglet masqué, tu disparais de l’indication des autres au bout d’environ une minute.

Quand un collègue enregistre une modification, l’indication affiche « Marco Rossi changed this ticket », avec le bouton « Refresh » à côté. Un nouveau commentaire de quelqu’un d’autre affiche « Marco Rossi added a comment ». Si la modification ne vient d’aucune personne, par exemple d’une règle d’automatisation ou d’un e-mail entrant, l’indication affiche « This ticket was changed ». L’indication reste affichée jusqu’à ce que tu recharges.

« Refresh » charge l’état actuel du ticket, par exemple le statut, l’attribution, les champs et l’historique. La page entière n’est pas rechargée. Tes saisies non enregistrées restent. Une réponse commencée reste dans la zone de réponse, et un titre ou une description ouverts gardent ton texte. Si le texte enregistré a changé entre-temps, « The saved text has changed in the meantime. » apparaît sous le champ. Si tu enregistres alors, ton texte remplace le texte enregistré. Le bouton « Refresh » dans l’en-tête du ticket fait la même chose.

Si tu enregistres malgré tout sur un état périmé, l’enregistrement est refusé. La fenêtre « Ticket changed in the meantime » s’ouvre. Si une personne a fait la modification, la fenêtre la nomme. Ta modification n’a pas été enregistrée. Clique sur « Refresh », compare ta modification à l’état actuel et enregistre de nouveau. Cela vaut pour toute modification du ticket lui-même, par exemple le statut, l’attribution, la priorité, la carte « Details » et les champs personnalisés.

Les commentaires ne sont jamais refusés. Deux réponses ne s’écrasent pas l’une l’autre. Les deux arrivent sur le ticket. Il en va de même pour les pièces jointes et les saisies de temps. Les actions groupées sur la liste des tickets et les règles d’automatisation ne sont pas non plus vérifiées par rapport à l’état. Elles modifient le ticket directement. Celui qui l’a ouvert voit ensuite l’indication.

Les clients ne voient rien de tout cela. Ils n’apparaissent pas dans l’indication. Ils ne voient pas non plus qui travaille sur leur ticket.

Qui a un ticket ouvert n’est conservé que dans la mémoire du serveur. Environ une minute après que la personne a quitté le ticket, l’entrée disparaît. Rien de tout cela n’est écrit dans un journal. Le ticket enregistre qui l’a modifié en dernier. Cette entrée fait partie de l’export de données de cette personne. Quand la personne est anonymisée, elle est supprimée.

Plus à ce sujet dans la carte : Export des données d’une personne, Anonymiser des personnes

L’en-tête d’un ticket avec l’indication « Marco Rossi is actively editing this ticket » sous le titre, encadrée en rouge.
L’indication se trouve sous le titre du ticket. Ici, Marco Rossi a des saisies non enregistrées.Ouvrir l'image en taille réelle
L’en-tête d’un ticket avec l’indication « Marco Rossi changed this ticket » et, à côté, le bouton « Refresh » encadré en rouge.
Marco Rossi a enregistré pendant que le ticket était ouvert. « Refresh » charge l’état actuel.Ouvrir l'image en taille réelle
La fenêtre « Ticket changed in the meantime » qui nomme Marco Rossi, avec le bouton « Refresh » encadré en rouge.
Cette fenêtre apparaît quand tu enregistres sur un état périmé. Ta modification n’a pas été enregistrée.Ouvrir l'image en taille réelle
15

Tickets à partir d'e-mails, réponses et relances

Professional uniquement

Avant de commencer : Avec Google et Gmail, il te faut un mot de passe d'application, qui exige la connexion à deux facteurs ; Google refuse les identifiants ordinaires du compte. Microsoft 365 ne fonctionne pas du tout pour le moment : l'authentification de base pour IMAP y est désactivée, et les mots de passe d'application n'aident pas non plus.

Le canal de messagerie est une route à deux sens, et les deux vont ensemble : un message entrant devient un ticket, ta réponse part par courrier électronique, et la réponse du demandeur arrive comme commentaire sur le même ticket, pas sur un second.

Le rapprochement ne se fait pas à l'intuition : une réponse n'arrive sur le ticket existant que si le message porte la référence du dossier dans son objet ou apporte les en-têtes de réponse du logiciel de messagerie. Un message qui n'a ni l'un ni l'autre ouvre un nouveau dossier. Mieux vaut un ticket de trop que deux dossiers sans rapport fusionnés parce que l'objet se ressemblait.

Tout ce qu'il faut se trouve sous « Settings → E-Mail Settings ». La carte du haut, « SMTP settings », est la voie de sortie : l'hôte, le port, « Use SSL », l'utilisateur et le mot de passe, plus l'adresse et le nom de l'expéditeur. Avec « Send test e-mail », tu t'envoies un exemple. Enregistre d'abord, teste ensuite, comme la carte le dit elle-même.

La carte « IMAP settings » est la voie d'entrée : l'hôte, le port, l'intervalle de relève et les deux dossiers. Tu n'as pas à deviner le nom du dossier : « Read from server » récupère les dossiers qui existent réellement dans ta boîte aux lettres, « Create on server » en crée un nouveau. Le champ prend alors le chemin que ton serveur de messagerie utilise : un serveur écrit « INBOX/Processed », le suivant « INBOX.Processed », et les deux veulent dire la même chose.

Le « Processed folder » reçoit les messages que le système met de côté : messages d'expéditeurs bloqués, messages générés automatiquement et messages qu'un workflow déplace avec « Move to folder » sans dossier propre. Laisse-le vide et ils restent dans la boîte de réception. En dessous, tu règles le moment du nettoyage (« Hour », « Minute ») et l'âge qu'un message peut atteindre (« Retention (days) »). Sinon, la boîte aux lettres grossit sans bruit.

Les boîtes aux lettres appartiennent à l'équipe, pas au système : sous « Team mailboxes », chaque équipe saisit sa propre adresse avec un mot de passe. Cette adresse est en même temps l'expéditeur des messages de cette équipe, le demandeur répond donc là où le courrier est relevé.

Et maintenant la partie sans laquelle rien de tout cela n'arrive : le workflow. Une boîte aux lettres configurée ne fait rien du tout à elle seule. Si une équipe n'a aucun workflow activé, la boîte aux lettres n'est même pas relevée : pas de ticket, pas de confirmation, les messages restent là. La réponse automatique à tes clients n'existe qu'ici, et c'est toi qui la mets en place. C'est voulu : un système qui écrirait sans qu'on le lui demande à chaque adresse d'expéditeur serait pire qu'un système qui se tait.

Sous « E-Mail workflows », tu choisis l'équipe en haut et tu crées un workflow avec « + Add workflow ». Il reçoit un nom (pour toi seulement), un interrupteur « Enabled » et deux indications sur les cas où il s'applique : « Match » décide si toutes les conditions doivent être vraies (« All conditions ») ou si une seule suffit, et « Stop after match » met fin au traitement dès que ce workflow a correspondu. Un workflow plus bas n'a alors jamais son tour. Tu changes l'ordre avec les flèches à côté.

Sous « When? » se trouve la condition elle-même. « Every e-mail in this mailbox » prend chaque message ; « Only when subject or text contains » exige un mot dans l'objet ou dans le corps. « Advanced » rend cela précis : tu y choisis ce qui est examiné, « Subject or body », « Subject », « Body », « Sender (From) » ou « Recipient (To/Cc) », et comment la comparaison se fait : « Contains », « Equals » ou « Regex ». C'est ainsi que tu sépares par exemple les signalements envoyés à une adresse commune du reste.

En dessous se trouvent cinq actions sous forme d'interrupteurs. Elles sont le contenu même du workflow : ce qui n'est pas activé ne se produit pas.

« Create or append ticket » transforme le message en ticket, ou l'ajoute comme commentaire à un ticket existant quand la référence figure dans l'objet. Sans cette action, un message ne devient jamais un dossier.

« Set fields » définit la priorité, le statut, la catégorie principale et la sous-catégorie, l'équipe propriétaire et la personne responsable dès la création du ticket. Tout ce qui reste sur « — Keep default — » demeure comme ce serait sans workflow.

« Auto-reply » est la confirmation envoyée à l'expéditeur. Avec cet interrupteur désactivé, ton client ne reçoit aucune confirmation, quelle que soit la qualité du reste de la configuration. « Send mail » peut aussi écrire à l'expéditeur, comme le montre l'action suivante.

« Send mail » envoie un message supplémentaire : soit à l'expéditeur du message entrant, soit à des membres d'équipe choisis et à des adresses fixes. Il a ses propres « Send conditions » ; laisse-les vides et il part à chaque exécution de ce workflow.

« Move to folder » classe le message traité dans un dossier. Laisse le champ vide et le « Processed folder » général des paramètres IMAP ci-dessus s'applique.

L'action « Auto-reply » en détail : tu construis l'objet à partir d'éléments. « Original subject {originalSubject} » reprend l'objet du message entrant, « Ticket reference {ticketTag} » insère la référence du dossier. Ensemble, cela donne quelque chose comme « Printer problem [TICKET-99-a1b2c3] ».

La référence n'est pas ajoutée toute seule. Elle n'apparaît que là où tu places {ticketTag}. {ticketId} n'insère que le numéro nu, et le système ne reconnaît pas une réponse à cela. Sans la référence dans l'objet, une réponse est quand même rattachée si elle porte les en-têtes de réponse de la confirmation. Seul un message qui n'a ni l'un ni l'autre devient un nouveau ticket.

Le texte en dessous est ton message de confirmation. Écris-le en anglais : il passe par le même export et le même import que tous les autres textes, et ce n'est que par là qu'il peut être traduit dans les autres langues. Laisse-le vide et le système envoie son propre message par défaut. Les mêmes variables sont autorisées ici aussi.

« Reply language » décide de la langue dans laquelle l'objet et le texte partent : « Standard English » utilise l'anglais, « Fixed language » une langue que tu choisis, « Assigned agent's language » la langue de l'agent responsable, et « Team default language » la langue par défaut de l'équipe. Les traductions elles-mêmes s'entretiennent sur la page des langues.

Un conseil que le système imprime aussi au-dessus de la carte : tout ce qui appartient à un même dossier appartient à UN seul workflow. Seules les actions d'un même workflow connaissent le ticket qui vient d'être créé, c'est pourquoi la confirmation peut nommer son numéro et pourquoi une action d'un second workflow ne le peut pas.

Tout le canal de messagerie, entrée et sortie, fait partie de l'édition Professional. Dans Basic, le système n'envoie ni ne reçoit de courrier électronique ; les tickets y sont créés par le portail, par téléphone et par l'agent.

La carte « SMTP settings » avec l'hôte, le port, l'utilisateur, le mot de passe, l'adresse d'expéditeur et le bouton « Send test e-mail ».
La voie de sortie. Chaque champ porte son explication en dessous ; les ports 587 et 465 y sont nommés explicitement.Ouvrir l'image en taille réelle
La carte « IMAP settings » avec les boutons « Read from server » et « Create on server » encadrés en rouge.
Ne tape pas le dossier, récupère-le : « Read from server » liste les vrais dossiers, « Create on server » en crée un nouveau sous la boîte de réception.Ouvrir l'image en taille réelle
La section « Team mailboxes » avec les boîtes aux lettres des équipes Helpdesk et Network, les adresses encadrées en rouge.
Une boîte aux lettres par équipe. L'adresse est aussi l'expéditeur, c'est pourquoi elle se trouve ici et non dans les paramètres généraux.Ouvrir l'image en taille réelle
Un workflow avec son nom, « Match », « Stop after match », la condition sous « When? » et les cinq interrupteurs d'action encadrés en rouge.
Les cinq actions sont encadrées en rouge. Dans cet exemple, « Create or append ticket », « Auto-reply » et « Move to folder » sont activées ; « Set fields » et « Send mail » sont désactivées. Sans un workflow de ce genre, la boîte aux lettres n'est pas relevée du tout.Ouvrir l'image en taille réelle
L'action « Auto-reply » avec le champ de l'objet encadré en rouge, les éléments de construction, le texte anglais et le choix de la langue de réponse.
L'objet contient les éléments « {originalSubject} {ticketTag} », c'est à cela que le système reconnaît plus tard la réponse du client. En dessous, le texte et la langue de réponse, ici celle de l'agent responsable.Ouvrir l'image en taille réelle

Statut de l'agent (disponibilité)

Chaque agent indique s'il est disponible en ce moment, et quand tu attribues un ticket, l'état figure à côté du nom. Tout ce qui est dans ce bloc fait partie de Basic. La répartition automatique qui saute les agents absents est une fonction distincte et fait partie de Professional.

1

Disponible, occupé, absent

Chaque agent a l'un des trois états et le règle lui-même, dans le menu utilisateur en bas à gauche de la barre latérale. Les trois entrées se trouvent sous le titre « Availability ».

Un point montre l'état. « Available » porte un point vert, « Busy » un point orange, « Away » un anneau vide.

Les trois se distinguent non seulement par la couleur, mais aussi par le remplissage, pour qu'une personne qui distingue mal les couleurs voie quand même la différence.

Ton propre point se trouve sur ta photo de compte en bas à gauche, tu n'as donc pas besoin d'ouvrir le menu pour le voir.

Quand tu attribues un ticket, l'état figure derrière le nom. Si une fin d'absence a été enregistrée, elle y figure aussi.

Un agent qui n'est pas disponible reste sélectionnable et n'est que signalé comme tel. Le ticket lui est attribué ou non, c'est ta décision.

On ne te propose jamais que les agents de l'équipe à laquelle le ticket appartient.

Seuls les agents et les administrateurs ont un état. Un client n'en a pas.

Plus à ce sujet dans la carte : Attribuer plusieurs tickets à un agent en une fois

Le menu utilisateur dans la barre latérale avec les trois états « Available », « Busy » et « Away » et une coche sur l'état en cours.
Le menu utilisateur de l'agent. Les trois états figurent tout en haut, celui qui s'applique porte une coche. Le même point se trouve sur la photo de compte en dessous.Ouvrir l'image en taille réelle
Le sélecteur « Assign to » d'un ticket, ouvert, avec les agents de l'équipe et la mention « Away until » sur une entrée.
Le cadre rouge entoure l'entrée de Lena Chen. Derrière le nom figurent son état et la fin de l'absence. Elle reste sélectionnable. Seuls les agents de l'équipe à laquelle le ticket appartient sont proposés.Ouvrir l'image en taille réelle
2

La maladie et les congés sont saisis par un administrateur

Une personne malade se déclare rarement absente à l'avance. C'est pourquoi un administrateur peut régler l'état d'une autre personne, dans le formulaire de modification du compte sous « User management ».

Le formulaire a deux champs pour cela. « Availability » contient l'état, « Away until » contient la fin de l'absence.

Le second champ n'apparaît qu'avec « Away ». Il n'y a pas de fin à saisir pour « Busy » ou « Available ».

Sans date, l'absence dure jusqu'à ce que quelqu'un y mette fin. Avec une date, elle prend fin d'elle-même. L'indication sous le champ le dit : « Leave empty for an absence without a set end. »

Une date dans le passé n'est pas acceptée. Elle aurait expiré aussitôt, et ton collègue figurerait encore dans la liste comme disponible.

Les deux champs n'apparaissent que pour les agents et les administrateurs. Si tu mets le rôle sur « Customer » dans le même formulaire, ils disparaissent.

Un seul champ porte les deux. Un jour de maladie et trois semaines de congés sont la même chose pour le système, avec une date différente.

Le formulaire de modification d'un compte avec les champs « Availability » sur « Away » et « Away until » contenant une date.
Les cadres rouges entourent les deux champs. Ils se trouvent tout en bas du formulaire, et seulement pour les agents et les administrateurs.Ouvrir l'image en taille réelle
3

« Busy » se remet tout seul au bout d'une heure

« Busy » dure une heure. Ensuite, l'agent est de nouveau disponible sans avoir à faire quoi que ce soit. Enregistrer le formulaire utilisateur ne prolonge pas « Busy ».

Le menu montre le temps restant à côté de l'état, par exemple « 60 min left ».

L'heure est fixe. C'est un filet de sécurité contre l'oubli, pas une règle d'organisation. Qui est indisponible plus longtemps choisit « Away ».

La remise à zéro est un instant, pas une tâche. Le compte retient le moment où l'état prend fin, et l'état est calculé quand quelqu'un le lit. Si le serveur était éteint pendant cette heure, l'agent est simplement de nouveau disponible ensuite. Aucun retard n'est laissé à un service d'arrière-plan à rattraper.

« Away » n'expire que si une fin a été enregistrée. Sans elle, l'état demeure jusqu'à ce que quelqu'un le change.

Quand les agents se mettent eux-mêmes sur « Away », ils ne peuvent pas saisir de fin. Seul un administrateur attribue une date de fin. Si une date est déjà fixée, elle reste quand l'agent choisit de nouveau « Away ».

Le menu utilisateur avec l'état « Busy », le temps restant « 60 min left » et la coche à côté.
Le cadre rouge entoure l'état en cours. La coche est à droite, le temps restant à côté de l'état. Le point sur la photo de compte est maintenant orange.Ouvrir l'image en taille réelle
4

Aucun historique de disponibilité et aucune analyse par personne

Le système ne retient que l'état en cours. Il ne consigne pas qui a été occupé ou absent, ni quand.

C'est pourquoi la liste des utilisateurs montre l'état du moment et rien de plus. Il n'y a ni colonne d'historique ni rapport de présence.

C'est une décision, pas un manque. Les données de disponibilité par personne sont des données de comportement, et dans beaucoup d'entreprises le comité social et économique a son mot à dire.

Un historique n'est pas nécessaire non plus. L'état répond à une seule question : ce collègue est-il disponible en ce moment ? « Busy » prend fin de lui-même au bout d'une heure.

Le nombre de tickets d'un agent se voit dans la liste des tickets, où « Assigned to » filtre par personne. La durée d'absence de quelqu'un n'est notée nulle part.

La liste des utilisateurs avec l'état de chaque agent juste après son nom et les colonnes Name, Email, Team, Role et Actions.
Les cadres rouges entourent deux des trois agents qui ne sont pas disponibles. La liste montre l'état du moment. Il n'y a pas de colonne d'historique.Ouvrir l'image en taille réelle

Attribution automatique des tickets

Un nouveau ticket peut recevoir un responsable tout de suite. Le système utilise la disponibilité expliquée dans le bloc précédent, la répartition s'active par équipe, et elle est désactivée comme réglage d'usine. Tout ce bloc fait partie de Professional.

1

La répartition appartient à l'équipe

Professional uniquement

Sans répartition, chaque nouveau ticket arrive dans la file commune. Quelqu'un doit le prendre ou quelqu'un doit le distribuer, et les deux fonctionnent tant que quelqu'un surveille.

Active la répartition et chaque nouveau ticket reçoit un responsable dès sa création. Cela se produit immédiatement et non quelques minutes plus tard. Un ticket créé directement comme résolu ou fermé n'est pas réparti.

Le réglage se trouve sur l'équipe sous « Settings → Teams » et chaque équipe décide pour elle-même. Une équipe peut répartir pendant que l'équipe voisine travaille à partir de la file commune.

Comme réglage d'usine, chaque équipe est sur « Off ». Une installation existante ne change pas de comportement simplement parce que la fonction existe.

Les tickets vont aux membres de l'équipe. Un administrateur qui travaille dans la file et qui est membre de cette équipe reçoit des tickets comme un agent.

La section « Automatic assignment » dans la boîte de dialogue de l'équipe Helpdesk, réglée sur « Round robin », avec deux phrases d'explication en dessous.
Le réglage se trouve sur l'équipe. Sous le champ, une phrase explique la méthode choisie, et en dessous figure qui est sauté.Ouvrir l'image en taille réelle
Le champ de sélection ouvert avec ses trois entrées « Off », « Round robin » et « Least load ».
Trois entrées au choix. « Off » est le réglage d'usine.Ouvrir l'image en taille réelle
2

À tour de rôle ou au moins chargé

Professional uniquement

Il y a deux méthodes et tu en choisis une par équipe.

« Round robin » fait le tour à tour de rôle. Le nouveau ticket va à l'agent disponible dont la dernière attribution automatique est la plus ancienne, si bien qu'une personne qui vient d'arriver dans l'équipe passe en premier.

« Least load » regarde la charge de travail. Le nouveau ticket va à l'agent disponible qui a le moins de tickets ouverts.

Un ticket qui attend le demandeur compte pour moitié. Une personne qui a beaucoup de questions en attente n'est pas occupée de la même façon qu'une personne qui a une pile d'incidents frais.

Un ticket résolu ou fermé ne compte plus du tout. C'est vrai aussi pour un statut que tu as créé toi-même, tant qu'il est marqué comme résolu ou fermé.

Le résultat est calculable dans les deux méthodes. Quand deux agents sont à égalité, c'est toujours la même règle qui tranche, jamais le hasard.

La même section dans la boîte de dialogue de l'équipe réseau, réglée sur « Least load », avec la phrase sur les tickets qui comptent pour moitié.
Le même champ sur une autre équipe, ici sur « Least load ». La phrase en dessous change avec le réglage.Ouvrir l'image en taille réelle
3

Qui n'est pas là ne reçoit rien

Professional uniquement

Avant chaque attribution, la répartition demande l'état de l'agent. « Busy » et « Away » sont sautés.

Les comptes verrouillés et supprimés sont exclus également, tout comme toute personne qui n'est pas membre de l'équipe à laquelle le ticket appartient.

Si personne n'est disponible, le ticket reste sans responsable, et sa création se déroule quand même normalement.

C'est voulu. Tout le monde voit un ticket dans la file commune, et personne ne voit un ticket posé chez une personne absente.

L'historique du ticket porte la raison : on y lit « Nobody available » à la place d'un nom.

Plus à ce sujet dans la carte : Disponible, occupé ou absent

L'historique d'un ticket avec une entrée « Auto-assignment » qui nomme « Nobody available » au lieu d'une personne.
Personne n'était disponible et le ticket est resté dans la file commune. Le cadre rouge entoure l'entrée qui nomme la raison.Ouvrir l'image en taille réelle
4

Ce que la répartition touche et ce qu'elle ne touche pas

Professional uniquement

La répartition agit sur toutes les voies par lesquelles un ticket naît, et cela comprend les tickets venus de la boîte aux lettres. L'exception est un incident collectif : il reste à la personne qui l'a créé.

Elle agit de la même façon sur les sous-tickets d'une demande : chacun est réparti à l'intérieur de l'équipe qui le reçoit.

Un ticket qu'une personne a attribué n'est jamais touché par la répartition. Si tu choisis toi-même un responsable à la création d'un ticket, ton choix demeure.

Chaque attribution automatique est consignée dans l'historique du ticket, avec « Auto-assignment » comme auteur et le nom de l'agent à côté.

L'agent reçoit le même message qu'avec une attribution manuelle. Si le ticket est encore sur « Open », il passe à « Assigned ».

Plus à ce sujet dans la carte : Un e-mail devient un ticket

L'historique d'un ticket avec deux entrées « Auto-assignment » : l'attribution à un agent de l'équipe et le changement de statut de « Open » à « Assigned ».
L'historique nomme l'automatisation. Elle a attribué le ticket et a fait suivre le statut.Ouvrir l'image en taille réelle
5

Le rapport sur la répartition

Professional uniquement

Qui fait tourner une automatisation doit pouvoir vérifier ce qu'elle fait. Il y a une carte à part pour cela sur la page des rapports.

Deux nombres figurent en haut. À gauche, le nombre de tickets que l'automatisation a distribués ; à droite, le nombre de fois où personne n'était disponible.

Sous « Nobody available », après « Most recent: », figurent jusqu'à 20 tickets concernés en dernier, et un clic t'y mène.

En dessous figure une ligne par agent, avec son nombre et sa disponibilité. Les lignes viennent de l'appartenance à l'équipe.

Une ligne à zéro n'est donc pas une erreur. C'est à cela que sert le tableau.

Une personne qui est sur « Away » depuis des semaines n'a reçu aucun ticket et figure quand même dans la liste, avec la raison à côté du zéro.

Cette carte est un journal de la machine et non une notation des personnes. Il n'y a pas d'historique de disponibilité et pas de rapport sur la durée de présence de chacun.

Ici, les agents ne voient que leurs propres équipes, et seulement celles dont les « Agent Permissions » autorisent à voir les rapports. Sans filtre d'équipe, ils voient la première de ces équipes.

Plus à ce sujet dans la carte : Aucun historique de disponibilité, aucune analyse par personne

La page des rapports avec la carte « Automatic assignment » parmi les autres rapports.
La carte se trouve sur la page des rapports. Le cadre rouge montre où la trouver.Ouvrir l'image en taille réelle
L'encadré « Nobody available » avec son nombre, une phrase d'explication et le ticket le plus récent concerné.
Le second nombre figure à côté du premier, avec le même poids. En dessous figure le ticket le plus récent resté dans la file commune.Ouvrir l'image en taille réelle
Le tableau du rapport avec six agents, leurs nombres et leur disponibilité, dont une ligne à zéro avec une mention « Away ».
Une ligne par agent. Le cadre rouge entoure la ligne à zéro qui porte sa raison à côté.Ouvrir l'image en taille réelle

Demandes avec tâches et approbation

Certaines demandes ne sont pas un ticket unique. Une demande crée ses tâches au moment du dépôt, chacune comme un ticket à part dans l'équipe qui la traite, et les approbations sont possibles sans être obligatoires. Tout ce bloc fait partie de Professional.

1

Une demande crée ses propres tâches

Professional uniquement

« Un nouveau collègue arrive » n'est pas un ticket unique. C'est un ordinateur portable, deux comptes, une ligne téléphonique et peut-être un accès depuis l'extérieur. Chaque élément appartient à une autre équipe, et tu veux malgré tout un seul dossier qui te dise où en sont les choses.

C'est à cela que sert une demande. C'est un ticket qui crée ses tâches au moment du dépôt, et chaque tâche devient un ticket à part dans l'équipe qui la traite.

Une demande n'est pas une deuxième chose à entretenir. Elle vit sur un modèle de ticket : sous « Settings → Request workflows », tu trouves tous les modèles de ticket, et tu attaches les tâches à l'un d'eux.

Pour chaque tâche, tu remplis quelques champs. « Task » est le nom que le demandeur lit, « Handled by » est l'équipe qui la reçoit, et « Ticket title » et « What the team has to do » remplissent le ticket qui en sort.

Plusieurs tâches peuvent viser la même équipe. Cette équipe reçoit alors plusieurs tickets, pas un seul ticket avec une liste dedans.

Une tâche sans équipe n'est pas proposée du tout. Le champ le dit lui-même : « Not assigned yet — this task is not offered ». Tu peux ainsi enregistrer un plan qui n'est pas encore terminé.

Au-dessus des tâches figure une phrase qui résume tout le plan : ce qui est créé comme réglage d'usine, ce que le demandeur peut modifier, et qui donne la validation. Change un réglage et la phrase se réécrit.

Devant « Ticket title » figure le texte fixe « Parent ticket title - ». Le nouveau ticket commence par le titre de la demande, suivi de ton titre, par exemple « New colleague in accounting - Set up notebook and docking station ». L'équipe spécialisée voit ainsi à quelle demande appartient une tâche. Si tu laisses le champ vide, c'est le nom de la tâche qui suit à la place.

« Main category » et « Subcategory » préremplissent la catégorie du nouveau ticket. Tu n'obtiens que les catégories de l'équipe indiquée dans « Handled by », car c'est là que le ticket est créé. Si tu changes d'équipe, les deux champs sont vidés. Tu renseignes les deux ou aucun, et s'ils restent vides, le ticket est créé sans catégorie.

Le nom de la demande figure au-dessus des tâches. Le crayon à côté te permet de le renommer. Le nom appartient au modèle de ticket, il change donc aussi sous « Settings → Templates » et dans le formulaire de nouveau ticket.

La liste des modèles de ticket sous « Request workflows », chacun avec son nombre de tâches et un bouton « Edit tasks ».
Tous les modèles de ticket au même endroit, chacun montrant combien de tâches il porte. Le cadre rouge entoure l'accès au plan.Ouvrir l'image en taille réelle
Le plan avec le nom de la demande, le crayon pour la renommer, la phrase de résumé et la première tâche.
En haut, le nom de la demande, avec le cadre rouge sur le crayon pour la renommer. En dessous figure la phrase qui résume le plan, puis viennent les tâches.Ouvrir l'image en taille réelle
La première tâche avec « Handled by » réglé sur Helpdesk, la catégorie Notebook et New request, et le texte fixe « Parent ticket title - » devant le titre du ticket.
Les catégories viennent de l'équipe indiquée dans « Handled by ». Le titre de la demande figure toujours devant le titre du ticket.Ouvrir l'image en taille réelle
2

Le demandeur coche ce dont il a besoin

Professional uniquement

Quand quelqu'un choisit le modèle dans le formulaire de nouveau ticket, l'encadré « What is needed? » apparaît avec une ligne à cocher par tâche.

Il y a trois types, réglés par tâche. « Selectable, off by default » commence vide, « Selectable, on by default » commence coché et peut être décoché, et « Always — cannot be deselected » s'exécute toujours.

Une tâche qui s'exécute toujours est quand même affichée, avec la mention « (always included) ». Le demandeur doit voir ce qui se passe de toute façon.

Sous l'encadré, tu lis ce qui va en sortir : « Each selected item becomes its own ticket for the team that handles it. »

Un client peut lui aussi déposer une demande, tant que le modèle lui est ouvert. L'interrupteur correspondant se trouve sur le modèle.

Le client ne voit alors que sa propre demande. Les tickets des équipes spécialisées lui restent cachés, même si sa demande les a créés : ces tickets contiennent des identifiants et des notes internes. Leurs notes internes n'apparaissent pas non plus dans l'historique de la demande. Quand une équipe spécialisée ferme son ticket, ses pièces jointes sont copiées dans la demande avec la pastille « Internal », et le client ne les voit pas et ne les télécharge pas.

Si une demande arrive par e-mail, elle devient un ticket ordinaire. Tu lances alors le workflow après coup. C'est le rôle du bouton « Start workflow » dans l'en-tête du ticket.

Dans la boîte de dialogue, tu choisis le modèle adapté sous « Template ». En dessous, tu retrouves le même encadré « What is needed? » que dans le formulaire de nouveau ticket. Coche ce que la demande réclame.

Sous « Title », tu ajustes le titre du ticket. Les titres des tâches commencent par lui. En dessous se trouvent les champs supplémentaires du modèle. Saisis-y les informations de la demande. Les champs obligatoires portent une étoile.

Avec « Start », les tâches sont créées exactement comme pour une demande faite depuis le formulaire. Si le modèle exige une approbation, le ticket et ses tâches restent verrouillés jusqu'à ce qu'elle soit donnée.

On ne peut lancer qu'un seul workflow par ticket. Ensuite, le bouton disparaît. Il manque aussi sur les tickets fermés et sur les tickets qui sont eux-mêmes une tâche. Toute personne autorisée à travailler sur le ticket peut le lancer.

Plus à ce sujet dans la carte : Les modèles de ticket peuvent être ouverts aux clients, un par un

L'encadré « What is needed? » dans le formulaire de nouveau ticket avec quatre tâches à cocher.
L'encadré dans le formulaire de nouveau ticket du demandeur. La première ligne s'exécute toujours et ne peut pas être décochée, la deuxième est cochée comme réglage d'usine, et en dessous figure ce que chaque coche deviendra.Ouvrir l'image en taille réelle
La boîte de dialogue « Start a workflow » sur un ticket, avec le modèle, les tâches à cocher et le champ du titre.
La boîte de dialogue sur un ticket. La première tâche s'exécute toujours. Sous le champ du titre, tu lis comment s'appelleront les tâches.Ouvrir l'image en taille réelle
3

L'avancement de la demande

Professional uniquement

Sur la demande elle-même, les tâches sont listées sous « Workflow tasks », avec le compteur à côté, par exemple « 1 of 4 done ».

Chaque ligne montre le nom de la tâche, le numéro de son ticket, l'équipe et la personne responsable, et le nom est un lien vers ce ticket.

« Terminé » vient du statut du ticket, pas d'une coche séparée. Ce qui compte comme fermé dans la liste des tickets compte comme terminé ici. Deux façons de compter la même chose finiraient tôt ou tard par diverger.

Le bloc n'apparaît que sur une demande. Un ticket ordinaire ne l'affiche pas.

Quand une équipe spécialisée ferme son ticket, son « Closing comment » arrive dans la demande. Il y figure comme note interne, et sa première ligne indique le numéro et le nom de la tâche. Le client ne voit pas cette note.

Les identifiants et tout ce que l'agent de la demande doit transmettre ont leur place dans le commentaire de clôture. Tous les autres commentaires de l'équipe spécialisée restent dans son propre ticket. Si l'équipe ferme sans commentaire, aucune note n'est créée.

Le bloc « Workflow tasks » sur la demande avec quatre tâches, leurs numéros de ticket et leurs équipes.
Le cadre rouge entoure la ligne du compteur. En dessous, chaque tâche montre dans quel ticket et dans quelle équipe elle se trouve ; la coche à gauche vient du statut.Ouvrir l'image en taille réelle
Une note interne sur la demande : l'en-tête « Task #… (Notebook and docking station) was closed with this note: » et, en dessous, le commentaire de clôture de l'équipe spécialisée.
L'équipe Helpdesk a fermé la tâche avec un commentaire de clôture. Sur la demande, il figure comme note interne avec la pastille « Internal ».Ouvrir l'image en taille réelle
4

Une seule approbation pour toute la demande

Professional uniquement

Une approbation couvre toute la demande, pas chaque tâche isolée. Huit applications font un message au responsable, pas huit.

Tu mets cela en place sous « Approvals » dans le même plan, et la phrase au-dessus énonce la règle : « One approval covers the whole request. Add a second stage only when single tasks need their own release. » Chaque étape a cinq champs : « Name » est le nom de l'étape, « Covers » dit ce à quoi elle s'applique, « Decided by » dit d'où vient l'approbateur, « Approver » contient la personne, et « Remind after (hours) » règle le rappel.

L'approbateur n'a besoin d'aucun compte dans le système de tickets : tu saisis une adresse e-mail et il décide par un lien. Un responsable qui approuve deux fois par trimestre ne coûte donc aucune place d'agent.

Le message contient exactement un lien vers une page. Il n'y a volontairement aucun bouton d'approbation ou de refus dans le message lui-même : un antivirus qui ouvre chaque lien approuverait sinon.

La page porte comme titre le nom de l'étape. Elle montre le numéro et le titre de la demande, le demandeur, et sous « This decision covers » les tâches sur lesquelles porte cette décision, avec un champ de commentaire et les deux boutons en dessous.

Le lien ne dure pas éternellement, et la page nomme l'échéance : « Please decide by … ». Il est valable 14 jours. Ensuite, la page indique seulement que le lien n'est pas valide ou a expiré, et un administrateur renvoie la demande avec « Reassign ».

Une décision ne peut pas être reprise, et la page le dit ensuite : « A decision cannot be changed. »

La section « Approvals » du plan avec deux étapes, chacune avec un nom, une adresse et une relance.
Deux étapes sur un plan : la première couvre toute la demande, la seconde seulement les tâches qui la visent. L'approbateur est une adresse, pas un compte.Ouvrir l'image en taille réelle
Le message d'approbation dans la boîte aux lettres, avec un seul lien vers la page de décision.
Voilà comment la demande atteint l'approbateur. Le message contient un lien et rien d'autre à cliquer ; la décision se prend sur la page derrière.Ouvrir l'image en taille réelle
La page de décision de l'étape « Head of IT » avec la demande, le demandeur, la tâche couverte, le champ de commentaire et les boutons « Approve » et « Reject ».
La page de décision. « This decision covers » dit sur quoi elle porte. L'approbateur n'est pas connecté et n'a pas de compte.Ouvrir l'image en taille réelle
5

Une deuxième étape pour des tâches isolées

Professional uniquement

Certaines tâches ont besoin d'une validation propre. Un accès depuis l'extérieur n'est pas la même chose qu'un ordinateur portable.

Pour cela, tu ajoutes une deuxième étape et tu la choisis sur la tâche sous « Extra approval ». Tant qu'il est indiqué « None — the request approval is enough », l'approbation de la demande suffit. Les deux étapes sont interrogées en même temps, pas l'une après l'autre. Une étape n'est interrogée que si l'une des tâches choisies la concerne. L'étape pour toute la demande est toujours interrogée.

Une tâche est libérée une fois que toutes les étapes qui la concernent ont donné leur accord. Une tâche sans étape propre démarre tout de suite, sauf si l'étape pour toute la demande attend encore. Elle démarre alors dès que la demande est approuvée.

Jusque-là, la tâche est verrouillée. Son ticket est sur « Waiting for approval » et n'a pas de responsable. À la place des boutons de statut, la carte indique « This ticket is waiting for approval and cannot be worked on yet. » Avant cela, aucune voie ne lui attribue de responsable.

Le verrouillage vaut aussi pour les actions groupées sur la liste des tickets. Sélectionne un tel ticket et tu lis la raison : « This ticket is waiting for approval and cannot be worked on yet. »

Le ticket est quand même créé immédiatement, pour que l'équipe spécialisée voie ce qui arrive et que personne n'ait à surveiller la demande.

La carte des actions d'une tâche verrouillée avec le statut « Waiting for approval » et la remarque indiquant que la tâche ne peut pas encore être traitée.
La tâche qui attend son étape propre. Le cadre rouge entoure le statut actuel. Au-dessus, la carte dit pourquoi aucun statut ne peut être choisi.Ouvrir l'image en taille réelle
6

Une relance, mais aucune validation par le temps

Professional uniquement

Tu peux régler une relance par étape, indiquée en heures.

Si aucune réponse n'arrive, le même message repart après ce délai, avec le même lien que le premier. Celui qui a gardé le premier message peut encore s'en servir.

Sans relance, la demande attend simplement, sans redemander.

Ce qui n'existe pas, c'est une validation par expiration. Sous le champ, c'est écrit noir sur blanc : « A request is never approved automatically. If nobody reacts, it keeps waiting. » Un délai qui donnerait son accord tout seul ne serait pas une approbation, ce serait une formalité.

Une étape d'approbation avec le champ de relance, indiqué en heures, encadré en rouge.
La relance appartient à l'étape et s'indique en heures. Laisse-la vide et le système ne redemande pas.Ouvrir l'image en taille réelle
7

Un refus atteint le demandeur avec son motif

Professional uniquement

Refuser exige un motif. Sans texte, la page n'accepte pas le refus.

Le champ dit où va le texte : « Comment (required when you reject — the requester will see it) ». Une note interne n'a pas sa place ici.

Le demandeur reçoit un e-mail avec le motif et n'a pas à demander pourquoi rien ne bouge.

Approuver ne demande aucun motif. C'est l'issue attendue.

Si seule une deuxième étape refuse, le refus ne concerne que les tâches de cette étape. Le reste de la demande continue.

Une tâche refusée reçoit le statut « Rejected » et compte comme terminée, pour que la demande ne reste pas suspendue à quelque chose qui n'arrivera jamais.

Dès que la demande est refusée, les autres approbateurs ne reçoivent plus de messages. Leur lien indique alors « This request has already been rejected. Your decision is no longer needed. » Dans la liste sur le ticket, leur étape affiche « No longer needed: the request was rejected. »

La page de décision après le refus, avec « You rejected this request. » et la remarque qu'une décision ne peut pas être changée.
Après la décision : la page confirme ce que l'approbateur a fait et précise que cela reste ainsi.Ouvrir l'image en taille réelle
8

La piste d'audit et l'approbateur en congés

Professional uniquement

Sur la demande, « Approvals » montre une ligne par étape avec l'approbateur, l'état, et pour une demande ouverte la durée d'attente.

Après la décision, la ligne montre quand elle a été prise et avec quel commentaire. C'est la piste d'audit, et elle reste avec le dossier.

Si l'approbateur est en congés, un administrateur transfère la demande à une autre adresse. Le bouton s'appelle « Reassign » et n'apparaît que tant que la demande est ouverte.

Seul un administrateur peut le faire. Un agent qui pourrait réaffecter pourrait se réaffecter la demande et décider ensuite.

La réaffectation crée un nouveau lien, et l'ancien meurt aussitôt, même si quelqu'un l'a transféré.

Le transfert lui-même apparaît dans la même liste : qui l'a fait, quand, de qui vers qui.

Personne ne peut décider au nom d'un autre. Le lien est la seule voie, et la personne qui l'a reçu est consignée sur le dossier.

La boîte de dialogue « Reassign » qui demande la nouvelle adresse, avec le champ rempli.
La boîte de dialogue demande l'adresse à laquelle la demande doit aller à la place. Tu confirmes avec le même mot que celui qui l'a ouverte.Ouvrir l'image en taille réelle
La liste « Approvals » avec la première étape approuvée, la deuxième refusée, les deux commentaires et la remarque sur la réaffectation.
Les deux étapes avec leur décision, leur heure et leur commentaire. Le cadre rouge entoure l'étape qui a été transférée, et en dessous figure qui l'a transférée, de qui vers qui.Ouvrir l'image en taille réelle

Modèles de réponse et de ticket

Deux sortes de modèles pour deux moments : un modèle de réponse remplit l'éditeur de commentaire sur un ticket ouvert, un modèle de ticket remplit le formulaire de nouveau ticket. Les deux font partie de Basic. Seul l'envoi d'une réponse par e-mail dépend du canal de messagerie et donc de Professional ; le modèle lui-même, non.

1

Modèles de réponse : le texte et les actions sur les champs (statut, attribution, priorité …) en un seul choix

Avant de commencer : Gérer et appliquer sont deux droits différents. Les administrateurs et les agents peuvent faire les deux au départ. Appliquer est ouvert à toute personne qui peut travailler sur le ticket. Les actions d'un modèle demandent en plus le droit de piloter le ticket ; une équipe qui avait le ticket auparavant peut donc commenter, mais pas lancer d'actions. Même si un rôle ne peut pas gérer les paramètres, il peut quand même appliquer un modèle.

Les modèles se trouvent sous « Settings → Templates ». La ligne sous le titre dit ce qu'ils font et ce qu'ils ne font pas : « Reply templates fill the comment editor and suggest field actions. Nothing is sent automatically. » Un modèle est un geste préparé, pas une machine. C'est toujours toi qui envoies.

Il y a deux sortes et tu en choisis une à la création : « Add reply template » pour la réponse sur un ticket ouvert, « Add ticket template » pour le formulaire de nouveau ticket. La sorte ne peut pas être changée ensuite, parce qu'elle décide des champs que le formulaire affiche. La pastille au-dessus de chaque modèle te dit lequel tu as sous les yeux : « Reply template » en bleu, « Ticket template » en vert.

Un modèle de réponse se compose du texte de la réponse (« Reply text »), de la case « Internal note » et d'un nombre libre d'actions. Il y a six actions : « Set the status », « Set the priority », « Assign to a user », « Remove the assignee », « Hand over to another team » et « Set a follow-up ».

La liste « Assign to a user » commence par l'entrée « The agent who applies it ». Prends celle-ci quand plusieurs personnes partagent le modèle : le ticket appartient alors à la personne qui l'a appliqué, et non à une personne fixe de la liste. « Set a follow-up » demande une quantité et une unité (minutes, heures, jours, minutes ouvrables, heures ouvrables, jours ouvrables), plus la note qui te dira plus tard pourquoi le ticket est revenu.

L'encadré bleu à la fin de chaque modèle écrit en une phrase ce qu'il va faire, par exemple « Inserts the text as a public comment, sets status to Waiting for Service Provider Response, assigns to the applying agent, sets a follow-up in 3 days. » La phrase se reconstruit pendant que tu modifies. C'est ta contre-vérification : si elle dit autre chose que ce que tu avais en tête, un réglage est faux.

Le texte n'est pas obligatoire. « Transmettre ceci à l'équipe réseau sans écrire un mot » est un modèle valable. La phrase se lit alors « Suggests actions without a reply text ». L'action « Set the status » suit les mêmes règles qu'un changement de statut à la main. Appliqué à plusieurs tickets à la fois, le modèle ignore les tickets verrouillés et en donne la raison.

La fenêtre « Close ticket » propose aussi des modèles de réponse, dans le champ « Template ». Elle ne liste que les modèles dont l'action active « Set the status » définit un statut qui compte comme résolu ou fermé. Les modèles internes n'y sont pas proposés. Si tu en choisis un, la fenêtre reprend son texte comme commentaire. Si le modèle envoie un e-mail et que la fenêtre propose l'envoi d'e-mails, elle ne reprend le destinataire que s'il s'agit de « Requester » ou d'une adresse fixe. Les autres actions du modèle ne s'exécutent pas à cet endroit, et ses pièces jointes ne sont pas ajoutées. Le ticket est fermé comme d'habitude.

La page « Templates » avec les boutons « Add reply template » et « Add ticket template » encadrés en rouge.
La sorte se choisit à la création : deux boutons au lieu d'un interrupteur. En dessous, les modèles sont visibles, chacun avec sa pastille et sa portée.Ouvrir l'image en taille réelle
Les trois lignes d'action d'un modèle de réponse, encadrées en rouge, avec la phrase bleue en clair en dessous.
Trois actions sur un modèle : le statut, l'attribution à la personne qui applique, la relance dans trois jours. La phrase en dessous dit la même chose d'un seul tenant.Ouvrir l'image en taille réelle
2

Les actions proposées peuvent être retirées une par une avant l'envoi

Sur un ticket ouvert, le bouton « Template » se trouve au-dessus de l'éditeur de commentaire. Un clic ouvre la recherche instantanée (« Search templates… »), et le choix d'un modèle remplit l'éditeur de commentaire. Rien d'autre ne se passe, et la ligne en dessous le dit : « Nothing happens until you add the comment. »

Chaque action du modèle devient une pastille à côté du bouton, en mots simples et non en jargon : « sets status to Waiting for Service Provider Response », « assigns to the applying agent », « sets a follow-up in 3 days ». Cliquer sur une pastille la barre : elle est retirée et ne s'exécutera pas. Un autre clic la ramène.

Les actions retirées sont barrées, pas supprimées. Cela laisse visible ce que le modèle aurait proposé, et cela garde la décision réversible tant que tu n'as pas envoyé.

Les pastilles actives au départ sont décidées par le modèle : dans les paramètres, chaque action porte un interrupteur « Suggested ». Cet interrupteur est la proposition pour tous les cas ; la pastille sur le ticket est la décision pour celui-ci.

Le « × » derrière les pastilles retire de nouveau le modèle. Le texte reste dans l'éditeur, tu l'as peut-être déjà réécrit. Seul l'effet disparaît, c'est-à-dire les actions, le message et les pièces jointes.

Tu envoies avec le bouton de commentaire habituel. C'est seulement alors que le commentaire est créé, et c'est seulement après que s'exécutent les actions encore actives.

L'éditeur de commentaire d'un ticket avec le modèle appliqué, trois pastilles à côté, la dernière barrée, et le texte inséré en dessous.
Deux actions s'exécuteront, la troisième est retirée : la relance dans trois jours ne convient pas à ce dossier, le reste si. Le texte est dans l'éditeur et peut encore être modifié.Ouvrir l'image en taille réelle
3

Variables (demandeur, numéro de ticket, titre …) : l'insertion du modèle met les vraies valeurs dans le texte

Le texte de la réponse peut utiliser cinq variables ; la liste se trouve sous le champ : « {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName} ». Écris-les avec des accolades, exactement comme elles apparaissent là.

« {ticketRef} » est la référence du ticket sous la forme « [TICKET-8-…] ». C'est à elle que le système reconnaît la réponse d'un client quand elle revient par courrier électronique. « {ticketId} », en revanche, n'est que le numéro nu.

Elles sont résolues au moment où le modèle est APPLIQUÉ, pas à l'enregistrement : la page des paramètres continue d'afficher « {requesterName} », l'éditeur de commentaire sur le ticket affiche le vrai nom. La raison est pratique : résoudre à l'enregistrement graverait pour de bon dans le modèle les valeurs d'UN seul ticket.

Tu lis ainsi le texte terminé avant que quoi que ce soit ne quitte l'entreprise. Si la formule d'appel ne convient pas, tu la changes dans l'éditeur comme n'importe quel autre texte.

Qui compte comme « demandeur » est décidé par le ticket, pas par le compte : le demandeur enregistré sur le ticket passe avant le compte qui l'a déposé. Si un agent dépose un ticket pour un collègue après un appel téléphonique, la réponse salue quand même le collègue et non l'agent.

Une variable mal écrite est refusée à l'enregistrement, et elle est nommée : « Reply text: unknown placeholders {requesterNam}. Available here: {requesterName}, {ticketId}, {ticketTitle}, {ticketRef}, {agentName}. » Tu la remarques donc en écrivant le modèle, pas sur un client.

L'objet de l'e-mail a sa PROPRE liste, plus courte (« {originalSubject}, {ticketTag}, {ticketId} »), c'est pourquoi elle y est imprimée une seconde fois. « {ticketRef} » y fonctionne aussi et signifie la même chose que « {ticketTag} ». « {requesterName} », « {ticketTitle} » et « {agentName} » ne fonctionnent pas dans l'objet et sont refusées de la même façon.

Le champ « Reply text » d'un modèle avec les variables dans le texte, encadré en rouge, et la liste des variables autorisées en dessous.
Voilà à quoi ressemble le modèle dans les paramètres : avec les variables, pas avec des valeurs. La ligne en dessous liste celles qui existent.Ouvrir l'image en taille réelle
Le même modèle appliqué sur un ticket : l'éditeur de commentaire contient le nom, le titre et la référence du ticket écrits en clair.
Le même texte sur le ticket : « Hello Amir Khan », le titre du ticket, la référence « [TICKET-8-…] », et en signature l'agent qui a inséré le modèle. Rien n'a encore été envoyé.Ouvrir l'image en taille réelle
4

La réponse peut être envoyée par e-mail au demandeur

Professional uniquement

Avant de commencer : Le canal de messagerie dans son ensemble est du Professional, en entrée comme en sortie. En plus, l'envoi sur les actions de ticket doit être activé sur la boîte aux lettres de l'équipe. Sinon, la pastille de message n'est pas proposée du tout sur le ticket ; les actions du modèle s'exécutent comme d'habitude, seul le message est abandonné. Aucun avertissement ne le signale non plus.

L'interrupteur « Send the comment as e-mail » fait aussi du commentaire le message. Il n'y a volontairement pas de second champ de texte pour cela : ce qui est dans le ticket est ce que le client lit. Deux textes finiraient tôt ou tard par diverger.

Sous « Recipient », tu choisis entre « Requester », « Assignee », « Observers » et « Fixed address ». L'identité du demandeur est résolue par le serveur au moment où le modèle est appliqué : un modèle ne connaît pas encore le ticket. On n'écrit jamais au compte de la boîte de réception elle-même, ce serait un message à nous-mêmes. Si le champ « User » contient un nom sans adresse, aucun message ne part vers le demandeur. Il n'est pas non plus envoyé à la place à la personne qui a saisi le ticket.

L'objet peut porter « {originalSubject} », « {ticketTag} » et « {ticketId} ». Garde « {ticketTag} » dedans : c'est à cette référence que le système reconnaît la réponse du client et l'ajoute au même ticket. Sans elle, chaque réponse devient un nouveau ticket.

Le message part en texte simple. Le gras, les listes et les liens sont retirés avant l'envoi, sinon le client lirait le balisage brut. À l'intérieur du ticket, le commentaire garde sa mise en forme.

Sur le ticket, le message est une pastille de plus à côté des actions (« E-mail to Requester ») et se retire aussi facilement qu'elles. Un modèle n'envoie donc jamais rien sans que tu l'aies vu. La pastille n'apparaît que si la boîte aux lettres de l'équipe envoie les messages liés aux actions de ticket.

Les pièces jointes d'un modèle (« Attachments ») sont ses propres copies des fichiers. Appliquer le modèle les ajoute au TICKET, avec leur propre ligne dans l'historique ; elles ne font pas partie du message. Porter des pièces jointes sur un modèle ne demande aucune licence Professional, seul l'envoi en demande une. Un modèle avec la case « Internal note » cochée n'ajoute aucun fichier.

Le bloc de messagerie d'un modèle avec l'interrupteur « Send the comment as e-mail » encadré en rouge, le destinataire et l'objet.
Interrupteur, destinataire et objet. L'objet contient « {ticketTag} », la référence à laquelle la réponse du client est reconnue.Ouvrir l'image en taille réelle
5

Créer un modèle directement à partir d'un ticket existant

La plupart des modèles ne naissent pas sur une planche à dessin, mais au moment où tu écris la même réponse pour la deuxième fois. C'est pourquoi chaque commentaire d'un ticket porte à droite une petite icône de feuille, intitulée « Make template ». Elle prend exactement ce commentaire comme texte de départ, y compris le commentaire d'un collègue. Seules les personnes qui peuvent gérer les modèles voient l'icône.

Si le ticket a des pièces jointes, une boîte de dialogue demande d'abord lesquelles doivent suivre : « Tick only the attachments the template should carry — one of them may be a customer's screenshot. Nothing is ticked by default. » Rien n'est coché d'avance, et c'est voulu.

Ensuite, tu arrives sur la page des modèles avec un brouillon qui n'est PAS encore enregistré. En haut se trouve la bannière orange « Draft from ticket #… — name it and review the text (it may contain customer details), then save. » Le nom est vide : tu dois en donner un, sinon il ne s'enregistre pas.

Ce qui est repris : le texte, la case « Internal note », l'équipe du ticket, et l'état du ticket comme proposition ; son statut et sa priorité sont déjà là sous forme de deux actions. Ce qui n'est pas repris : le demandeur, l'adresse et le titre. Ceux-ci appartiennent à ce seul dossier.

Lis le texte avant d'enregistrer. Il vient d'un vrai dossier et peut contenir le nom d'une personne, un numéro de commande ou un local. Rien n'est anonymisé pour toi. La bannière le dit, mais le faire est ton travail.

Seul « Save » crée le modèle ; les pièces jointes cochées sont alors copiées et un message le confirme.

Un commentaire sur un ticket avec l'icône de feuille « Make template » encadrée en rouge, à côté des boutons de modification et de suppression.
Le chemin commence au commentaire, pas dans les paramètres : l'icône de feuille à droite de la réponse que tu veux réutiliser.Ouvrir l'image en taille réelle
La boîte de dialogue « Make a template from this comment » avec les deux pièces jointes du ticket, aucune n'étant cochée.
Deux pièces jointes sont accrochées à ce ticket, aucune n'est cochée. L'une d'elles est la capture d'écran du client, elle n'a pas sa place dans une bibliothèque de réponses toutes faites.Ouvrir l'image en taille réelle
6

Les brouillons restent privés jusqu'à la publication ; la portée se règle par équipe ou globalement

« Applies to » décide à qui le modèle est proposé : une équipe précise ou « All teams ». Un nouveau modèle commence avec une équipe concrète ; « All teams » est un choix que quelqu'un doit faire, pas un réglage par défaut silencieux.

Sur un ticket, on te propose les modèles de l'équipe propriétaire et les modèles globaux. Si le ticket passe à une autre équipe après une transmission, la liste suit : ce sont les modèles de la nouvelle équipe que tu peux choisir.

L'interrupteur « Draft » fait du modèle ton atelier : « Only you can see this template until you publish it. » Le brouillon de quelqu'un d'autre n'apparaît dans aucune liste et n'est pas non plus joignable par son adresse, pas même par les administrateurs. Un nouveau modèle commence comme brouillon ; c'est seulement quand tu désactives cela et que tu enregistres que les autres le voient.

Deux modèles ne peuvent pas porter le même nom s'ils peuvent se croiser : un modèle global entre en conflit avec tout modèle du même nom, dans n'importe quelle équipe. Un modèle de réponse et un modèle de ticket peuvent en revanche porter le même nom, ils n'apparaissent jamais côte à côte dans la même liste.

« Duplicate » fait une copie, et la copie est toujours un brouillon : « Duplicated. The copy is a draft only you can see. » C'est la voie confortable vers une variante sans que la version à moitié faite soit proposée à quelqu'un d'autre.

L'en-tête d'un modèle avec les pastilles « Reply template » et « Draft », le champ « Applies to » encadré en rouge et l'interrupteur « Draft » encadré de la même façon.
Ce modèle appartient au helpdesk et c'est un brouillon. Personne d'autre que son auteur ne le voit.Ouvrir l'image en taille réelle
7

Modèles de ticket : le formulaire de nouveau ticket prérempli (titre, description, catégorie, priorité, équipe)

Un modèle de ticket remplit le formulaire « Create new ticket ». Il n'a pas de texte de réponse, pas d'actions et pas de message : à ce moment-là, il n'y a aucun ticket sur lequel agir. Le formulaire montre donc d'autres champs que pour un modèle de réponse, et le cadre vert te dit que tu as un modèle de ticket sous les yeux.

Tu peux préremplir « Ticket title », « Owning team of the new ticket », « Main category », « Subcategory », « Priority » et la « Ticket description ». Chaque champ peut rester sur « Not prefilled » ; ce qui reste vide est rempli plus tard par la personne qui utilise le formulaire.

Fais attention à la différence entre les deux champs d'équipe : « Applies to » en haut dit QUI voit le modèle. « Owning team of the new ticket » dit OÙ va le nouveau ticket. Ce sont deux questions différentes, et elles peuvent avoir des réponses différentes.

Les catégories sont regroupées par équipe, parce qu'une catégorie appartient à une équipe. Si tu en choisis une d'une autre équipe, le formulaire te le dit et l'enregistrement est refusé : sur le formulaire de nouveau ticket de l'équipe cible, cette catégorie ne serait pas proposée du tout, le préremplissage n'aboutirait donc à rien.

Il n'y a pas de variables ici, et l'indication sous le texte le dit : « No placeholders here: the template only prefills the form, nothing is resolved or sent. » Un « {requesterName} » se retrouverait tel quel dans le nouveau ticket, c'est pourquoi il est refusé à l'enregistrement.

L'encadré bleu résume ici aussi ce que fait le modèle : « Prefills the new ticket with title 'New notebook for a colleague' · category Notebook / New request · priority Medium · team Helpdesk · the description. »

Sur le formulaire lui-même, tu choisis le modèle avec le bouton « Template » ; à côté figure « Prefills the form - nothing is created until you submit. » Tout ce qui est prérempli peut encore être changé, et rien n'est créé tant que tu n'as pas envoyé.

Un modèle d'exemple est livré avec le système : « Example: create accounts for a new colleague ». Il montre la forme de la chose et ne fait rien de lui-même. Reconstruis-le ou supprime-le.

L'éditeur d'un modèle de ticket avec les champs de titre, d'équipe cible, de catégorie et de priorité encadrés en rouge.
Cinq préremplissages plus la description. Le champ « Owning team of the new ticket » n'est pas la portée au-dessus : il dit où va le ticket.Ouvrir l'image en taille réelle
Le formulaire « Create new ticket » après le choix d'un modèle : le bouton « Template » et le titre prérempli sont encadrés en rouge.
Le même formulaire que d'habitude, mais déjà rempli : le titre, l'équipe et la priorité sont là. La catégorie et la description suivent plus bas sur la même page.Ouvrir l'image en taille réelle
8

Les modèles de ticket peuvent être ouverts aux clients, modèle par modèle

L'interrupteur « Offer this template to customers » est désactivé au départ. L'indication à côté dit les deux choses à savoir : « Customers can pick this template when they create a ticket. A draft stays hidden either way. »

Pourquoi il est désactivé par défaut : un modèle porte souvent un nom en vocabulaire interne et est écrit pour des collègues. Le rendre visible aux clients est une prise de parole vers l'extérieur ; quelqu'un doit le faire délibérément, pas par accident.

Le client voit le même bouton « Template » au-dessus du formulaire de nouveau ticket, mais seulement les modèles ouverts. Un brouillon reste caché même avec l'interrupteur activé : les deux règles se suivent, elles ne sont pas côte à côte.

L'enjeu n'est pas le confort, c'est le premier contact : une demande qui arrive complète évite l'échange de questions qui coûterait sinon deux jours. Mets ces questions dans la description du modèle, le client y répond en créant le ticket.

Tu peux aller plus loin avec « Fields to ask for ». Le modèle décide alors des champs personnalisés que le formulaire demande, dans quel ordre, et lesquels sont obligatoires. Cette sélection REMPLACE les champs habituels de l'équipe, elle ne s'y ajoute pas. C'est précisément son but. Les champs personnalisés eux-mêmes font partie de Professional ; leur carte s'appelle « Champs personnalisés ». Ouvrir un modèle aux clients fonctionne dans toutes les éditions.

Un champ caché aux clients reste caché, même si un modèle le liste. La sélection de champs est un outil d'ordre et de découpe, pas un moyen de contourner les réglages des champs.

L'interrupteur « Offer this template to customers » encadré en rouge, avec son texte d'indication.
Un interrupteur par modèle ; ici il est activé, ce modèle est donc proposé aux clients. L'indication dit clairement qu'un brouillon reste caché malgré tout. En dessous se trouve la sélection de champs.Ouvrir l'image en taille réelle
Le formulaire de nouveau ticket tel qu'un client le voit, avec la liste des modèles ouverte et les modèles ouverts dedans.
La même liste côté client : elle ne contient que les modèles ouverts. Les autres modèles de ticket de cette installation n'y apparaissent pas.Ouvrir l'image en taille réelle
9

Chaque utilisation est traçable dans l'historique du ticket

Chaque utilisation qui fait plus qu'insérer du texte écrit UNE entrée dans l'historique, sous le nom de champ « Template ». Elle nomme le modèle. Les actions exécutées écrivent leurs propres lignes. Sans cela, il n'y aurait aucun moyen d'expliquer plus tard pourquoi un ticket est soudain passé à « In Progress » : les actions individuelles écrivent bien leurs propres lignes, mais aucune ne nomme le modèle.

L'image se lit ainsi : « Template ‘First reply: we have your ticket’ applied ». Ce que le modèle a fait figure dans les lignes de ses propres actions, comme le changement de statut.

Les actions retirées n'y figurent pas : elles n'ont pas eu lieu. Un échec y figure, et il est nommé comme tel, derrière le mot « failed ». Un modèle de texte seul, sans actions, message ni pièces jointes, ne laisse aucune entrée « Template » sur un ticket isolé. Il n'a fait qu'insérer du texte. Appliqué à plusieurs tickets à la fois, l'entrée est toujours écrite, avec la ligne interne « Bulk ».

L'entrée est INTERNE, le demandeur ne la voit pas. Le nom d'un modèle est du vocabulaire interne (« refus standard »), et l'historique est ouvert aussi à la personne qui a créé le ticket. Les changements de champs eux-mêmes lui restent visibles ; seule leur origine dans un modèle ne l'est pas.

L'auteur est l'agent, pas « system » ni le modèle. C'est voulu : l'appliquer était sa décision. Contrairement à une règle d'automatisation, ce qui figure ici sur le ticket est une personne.

L'historique d'un ticket avec l'entrée « Template » encadrée en rouge, qui nomme le modèle appliqué, et les lignes de ses actions.
Une entrée par utilisation, avec l'agent comme auteur. Chaque action exécutée écrit sa propre ligne. L'entrée du modèle dit d'où elles viennent.Ouvrir l'image en taille réelle

Automatisation et suivis

Deux voies vers le même but : aucun dossier ne reste en plan parce que plus personne ne l'a en tête. Un suivi est quelque chose que tu poses toi-même, cela fait partie de Basic. Les règles le font sans toi, et elles font partie de Professional.

1

Suivi manuel sur un ticket (date et note, filtres Aujourd'hui, Cette semaine, En retard)

Avant de commencer : Seuls les agents et les administrateurs voient le suivi, et le ticket le dit : « Only agents and administrators see this — the requester never does. » Le demandeur ne le voit jamais.

Le suivi se trouve sur le ticket dans la carte « Details » à droite, sous les délais. Tant qu'aucun n'est posé, il indique « No follow-up set. » avec un bouton « Set follow-up ». Tu choisis une date et une heure (« Date and time ») et tu ajoutes une note (« Note (optional) », texte d'exemple « Why is this coming back? »). Ensuite, les boutons deviennent « Change » et « Remove ».

C'est dans la note que se trouve la valeur. Dans deux semaines, une date seule ne te dira pas pourquoi ce ticket est revenu sur ton bureau. C'est aussi pourquoi la note est accrochée à la date : retire la date et la note part avec elle. Un motif sans date est quelque chose que personne ne reverrait jamais.

Au-dessus de la liste des tickets se trouve une ligne « Follow-up: » avec quatre boutons, « No filter », « Today », « This week » et « Overdue », et la liste elle-même a une colonne « Follow-up ». Elle ne se trouve volontairement pas dans le bloc de filtres replié : c'est la question par laquelle un agent commence sa journée.

« Overdue » comprend ceux du jour. Sinon, un suivi disparaîtrait exactement le jour où il compte, dès que son heure serait passée.

La carte « Details » d'un ticket avec la section « Follow-up » encadrée en rouge, contenant la pastille « Overdue », la note et les boutons « Change » et « Remove ».
La date de ce ticket est dans le passé, d'où la pastille rouge « Overdue ». La note dit pourquoi le ticket revient.Ouvrir l'image en taille réelle
La liste des tickets avec la ligne « Follow-up: » encadrée en rouge au-dessus du tableau et la colonne « Follow-up » encadrée de la même façon.
Trois tickets de cette page portent une date. Les boutons au-dessus réduisent la liste à aujourd'hui, à cette semaine ou aux retards.Ouvrir l'image en taille réelle
2

Règles temporelles : réagir à l'ABSENCE d'une action

Professional uniquement

Avant de commencer : Une nouvelle règle est TOUJOURS créée désactivée, même si tu essaies de la créer activée depuis l'interface. Une règle qui parcourt tout ton stock au moment de sa création est l'accident que le système t'évite ici. Elle n'entre en service qu'au prochain « Save ».

Les règles se trouvent sous « Settings → Automation ». La ligne sous le titre dit de quoi il s'agit : « Rules that act when nobody else does. » Une règle appartient à une équipe et agit sur les tickets de cette équipe ; le sélecteur « Team » en haut décide des règles que tu as sous les yeux.

La différence avec tout le reste du système : ces règles ne réagissent pas à un événement, elles réagissent à son ABSENCE. Aucune réponse du demandeur depuis trois jours, aucun mouvement depuis une semaine, créé il y a quatre heures et toujours sans responsable. Aucun clic ne déclenche cela, et c'est justement pour cette raison que personne ne le remarque.

Un message avec une coche verte en haut te dit que les vérifications tournent : « The automation checks every minute. 2 of 6 rule(s) are enabled. » Sans règle activée, tu reçois l'avertissement « No rule is enabled. Nothing is being checked and tickets behave exactly as before. », et alors il ne se passe vraiment rien.

Une règle examine tous les tickets de son équipe, quel que soit leur nombre. En un passage, elle agit sur 500 d'entre eux au maximum. Les autres suivent au passage suivant.

Une règle qui a été désactivée ne rattrape pas son retard. Quand tu la réactives, elle n'agit pas sur ce qui est arrivé à échéance pendant la pause. Les règles sans condition de temps sont l'exception : elles rattrapent. La première fois qu'une règle est activée, elle agit sur tout ce que montre son aperçu.

Le haut de la page « Automation » avec le message sur l'intervalle de vérification encadré en rouge, le filtre d'équipe et le bouton « Add rule ».
Six règles sont enregistrées ici, deux d'entre elles tournent. Les quatre exemples fournis se trouvent plus bas sur la même page, tous désactivés.Ouvrir l'image en taille réelle
3

Constructeur de règles QUAND/SI/ALORS avec une phrase en clair mise à jour en direct

Professional uniquement

Une règle a trois blocs. « WHEN » est l'absence à laquelle elle réagit (« Something has not happened for a while. This is what the automation reacts to. »). « IF » précise les tickets concernés (« Which tickets it applies to. »), par statut, priorité, équipe, catégorie, personne responsable ou évaluation. « THEN » est ce qui se produit.

Au-dessus des blocs, la règle apparaît sous forme d'une phrase, qui se réécrit à chaque changement : « When a ticket has seen no activity for more than 5 minutes and has the priority "High", then set a follow-up in 4 hours. » S'il manque encore quelque chose, la phrase le dit à cet endroit précis au lieu de le cacher.

Dans le bloc « IF », tu décides aussi comment les conditions se combinent : « All conditions must apply » ou « Any condition is enough ». La phrase au-dessus change de forme en conséquence ; avec un « et », elle prétendrait sinon le contraire de ce que fait la règle.

Deux champs règlent la façon dont plusieurs règles travaillent ensemble : « Order » fixe l'ordre, et l'interrupteur « Skip the following rules for a ticket this rule applies to » arrête toutes les règles suivantes pour un ticket auquel celle-ci s'applique.

Une nouvelle règle commence avec la condition de temps « Time without any activity » « longer than » 3 « days » dans le bloc « WHEN ». Modifie-la ou retire-la si ta règle a besoin d'autre chose.

Plus à ce sujet dans la carte : Une mauvaise évaluation comme déclencheur

Une règle avec la phrase en clair encadrée en rouge au-dessus et les trois blocs WHEN, IF et THEN en dessous.
Le même contenu deux fois : une fois sous forme de formulaire, une fois sous forme de phrase. En lisant la phrase, tu remarques tout de suite si tu as configuré autre chose que ce que tu voulais.Ouvrir l'image en taille réelle
4

Quatre règles d'exemple fournies (désactivées à l'installation, active celles que tu veux)

Professional uniquement

Chaque installation est livrée avec quatre règles : « Example: remind the requester after 3 business days », « Example: close after 10 days without a reply », « Example: raise the priority of unassigned tickets » et « Example: follow up on tickets nobody touched for a week ». Elles se suivent sur la page « Automation ».

Les quatre sont désactivées : chacune porte la pastille « Off » et « Last run: never ». Ce sont un point de départ à lire et à reconstruire, pas un comportement que quelqu'un t'aurait glissé sans le dire. Renomme-les, modifie-les, active-les ou supprime-les.

Elles s'appliquent aussi à « Every team », le seul endroit du système où cela arrive sans choix explicite. Avant d'en activer une, vérifie donc si elle est vraiment destinée à toutes tes équipes.

La première des quatre règles d'exemple avec la pastille « Off » encadrée en rouge, son nom et la phrase en clair.
Voilà à quoi ressemble la première ; les trois autres sont plus bas sur la même page et sont désactivées elles aussi. « Every team » signifie qu'elle s'appliquerait à chacune de tes équipes.Ouvrir l'image en taille réelle
5

Un aperçu avant l'activation : il montre les tickets que la règle toucherait en ce moment, sans rien changer

Professional uniquement

Sous chaque règle se trouve le bouton « Which tickets would this affect? » Un clic montre la liste « Tickets this rule would affect right now », les tickets auxquels la règle s'applique à cet instant, avec le numéro et le titre.

En dessous, il est écrit ce que l'aperçu ne fait pas : « The preview only reads. It changes nothing and writes no log entry. Unsaved changes are not included. » Cette dernière partie compte : l'aperçu travaille sur la règle enregistrée, pas sur ce qui se trouve actuellement dans le formulaire.

Si la règle ne correspond à rien pour le moment, il le dit aussi : « No ticket matches this rule right now. » C'est la réponse que tu veux avant l'activation, pas après, sur les tickets de tes clients.

L'aperçu ouvert d'une règle avec le titre « Tickets this rule would affect right now », deux tickets et l'indication encadrée en rouge que l'aperçu ne fait que lire.
Cette règle toucherait deux tickets en ce moment. L'indication en dessous précise que rien de tout cela ne s'est produit quand tu as cliqué sur le bouton.Ouvrir l'image en taille réelle
6

Actions : e-mail, statut, priorité, attribution, transmission à une autre équipe, pose d'un suivi

Professional uniquement

Avant de commencer : L'action « Send an e-mail » passe par le même canal de messagerie que le reste du système. Sans envoi de courrier configuré, rien ne se produit, et une installation Basic n'a pas ce canal du tout. L'historique n'enregistre le message que s'il est vraiment parti. Sinon, l'exécution affiche « Failed » dans le journal de la règle, avec la raison.

Dans le bloc « THEN », tu choisis parmi sept actions : « Send an e-mail », « Set the status », « Set the priority », « Assign to a user », « Remove the assignee », « Hand over to another team » et « Set a follow-up ». « Add action » en ajoute d'autres ; chacune a son propre interrupteur « Active », tu peux donc en faire taire une seule sans désactiver toute la règle.

Pour « Send an e-mail », tu coches les destinataires un par un : « the requester », « the assignee », « the observers » et « a fixed address », ce dernier avec son propre champ pour l'adresse. Pour « Set a follow-up », tu donnes un nombre, une unité et la note qui se trouvera plus tard sur le ticket.

Pour « Hand over to another team », l'indication est juste en dessous : « The ticket moves to that team and the current assignee is cleared. No second ticket is created. » Aucun doublon n'apparaît donc, le même dossier change simplement de mains.

Une règle ne peut pas fermer un ticket qui attend une approbation, ni un incident collectif qui a encore des signalements ouverts.

Le bloc « THEN » d'une règle avec le sélecteur d'action encadré en rouge et les champs de nombre, d'unité et de note du suivi.
Une action avec ses compléments : « Set a follow-up », 4 « hours », plus la note que l'agent lira plus tard sur le ticket.Ouvrir l'image en taille réelle
7

Des durées réglables par condition : en heures et jours ouvrables du calendrier de l'équipe, ou en temps continu

Professional uniquement

Chaque condition de temps du bloc « WHEN » a trois parties : le type, la comparaison « longer than » et un nombre avec une unité. Il y a cinq types : « Time since the ticket was created », « Time without any activity », « Time without a reply from the requester », « Time without a public reply from an agent » et « Time without a status change ».

L'unité décide de la façon dont le temps est compté, et elle le fait par condition : « minutes », « hours » et « days » courent en continu, la nuit et le week-end aussi. « business minutes », « business hours » et « business days » comptent selon le calendrier d'heures ouvrables de l'équipe, seul ce qui tombe dans les horaires d'ouverture est donc compté.

Au quotidien, la différence est grande : trois jours sont trois jours, tandis que trois jours ouvrables comptés à partir d'un jeudi dans une semaine du lundi au vendredi tombent le mardi suivant. Un jour ouvrable est un jour travaillé dans le calendrier de l'équipe à laquelle appartient le ticket, même pour une règle « Every team ». Les jours fériés ne comptent pas. Si le temps démarre en dehors des heures d'ouverture, il compte à partir de la reprise du travail suivante. L'action « Set a follow-up » compte les « business days » de la même façon.

Une condition de temps dans le bloc « WHEN » avec le nombre et l'unité encadrés en rouge, à côté du sélecteur du type de condition.
Cette condition compte en « business days » : trois jours ouvrables selon le calendrier de l'équipe, pas trois jours de calendrier.Ouvrir l'image en taille réelle
8

Un journal par règle, et le nom de la règle comme auteur dans l'historique du ticket

Professional uniquement

Sous chaque règle se trouve un bouton « Log ». Il ouvre le tableau « What this rule did » avec une ligne par ticket concerné : « When », « Ticket », « Cycle », « Result » et « Details ». « Details » contient ce qui a été fait exactement, par exemple « Set a follow-up: 01.10.2026 22:36 ». Si une règle n'a encore rien fait, il le dit : « This rule has not done anything yet. »

La colonne « Cycle » est la raison pour laquelle une règle ne te crie pas dessus chaque minute : elle agit une fois par cycle sur un ticket. Un cycle ne se termine que lorsque la règle ne s'applique plus à ce ticket. Si le client répond puis se tait de nouveau, le cycle 2 commence et la règle agit de nouveau.

Sur le ticket lui-même, la règle apparaît comme auteur. Dans l'historique, elle figure sous son propre nom avec le préfixe « Automation: », par exemple « Automation: High priority: bring it back to us ». Sur chaque dossier, tu peux donc vérifier si c'est un être humain ou une règle qui a agi, et si c'est une règle, laquelle. Les clients voient « System » comme auteur au lieu du nom de la règle.

La ligne d'en-tête de chaque règle porte aussi « Last run: » avec l'heure de son dernier passage, ou « never » pour une règle qui n'a jamais tourné.

Le tableau « What this rule did » ouvert avec trois lignes et les colonnes « Cycle » et « Details » encadrées en rouge.
Trois passages sur deux tickets : sur le ticket 4 resté sans réponse, la règle a agi une seconde fois, d'où le « 2 » dans la colonne « Cycle ». « Details » contient la date de suivi posée à chaque fois.Ouvrir l'image en taille réelle
L'historique d'un ticket avec deux lignes encadrées en rouge dont l'auteur est « Automation: High priority: bring it back to us ».
Le même événement vu depuis le ticket : la date et la note apparaissent comme deux lignes dans l'historique, avec la règle comme auteur.Ouvrir l'image en taille réelle

Actions groupées sur la liste des tickets

Coche plusieurs tickets et modifie-les d'un seul coup. Tout cela fait partie de Basic. Seul l'e-mail au client envoyé par un modèle dépend du canal de messagerie et donc de Professional. Le vrai enjeu n'est pas le nombre de tickets mais le traitement honnête d'un résultat partiel : chaque règle s'applique au ticket isolé, le système dit donc à l'avance à combien de tickets l'action convient, et ensuite lesquels n'ont pas suivi et pourquoi.

1

Changer le statut de plusieurs tickets d'un coup

La liste des tickets a une colonne de cases à cocher tout à gauche. Elle est là pour les administrateurs et les agents. Un client ne la voit jamais.

La case de la ligne d'en-tête sélectionne toutes les lignes de la page que tu regardes. Elle ne sélectionne pas l'ensemble du résultat. S'il t'en faut davantage, resserre le filtre : un filtre est une façon plus honnête d'énoncer une quantité qu'une case qui couvrirait aussi des tickets que tu ne vois pas.

La sélection s'efface dès que tu changes de page, que tu filtres, que tu cherches ou que tu changes d'équipe. Aucune sélection ne voyage ainsi alors qu'elle n'est plus à l'écran.

La liste de l'image ne montre pas tous les tickets. En haut à droite, à côté de « Filter », figure le mot « active », et à côté « Reset » : les tickets fermés sont masqués, parce qu'une action groupée vise les dossiers encore en cours. Une sélection ne couvre jamais que ce que la liste montre à cet instant.

Dès la première coche, une barre apparaît au-dessus de la liste. Elle affiche « 20 selected », à côté « Clear selection » et les boutons « Change status », « Assign », « Assign to me » et « Apply template ». Plus à droite se trouvent « Multiple report » et « Group into incident » ; ces deux-là concernent les signalements en double et sont expliqués dans le bloc suivant.

« Change status » ouvre une petite boîte de dialogue. Tu choisis le statut cible, et la ligne en dessous dit aussitôt à combien des tickets sélectionnés il s'applique.

Si le statut cible exige un commentaire, une zone de texte apparaît. En dessous figure le nombre de tickets auxquels le texte est destiné. Il va à chaque ticket modifié, pas seulement au premier.

Tous les statuts n'apparaissent pas dans la liste. Les statuts système manquent, parce que personne ne les pose à la main. « Waiting for other team » manque également : ce statut crée un sous-ticket pour une équipe cible, et tu choisis cette équipe par ticket. Dans un lot, il n'y aurait qu'une seule saisie pour cela.

Un ticket sans responsable t'est attribué quand tu changes son statut sur la page de détail. Dans un lot, cela n'arrive pas : « fermer 30 tickets » voudrait sinon dire en silence « 30 tickets attribués à moi » et 30 e-mails.

Cette boîte de dialogue ne change rien d'autre. La priorité, la catégorie et tout le reste se règlent en lot par un modèle de réponse.

Plus à ce sujet dans la carte : Une deuxième étape pour des tâches isolées

La liste des tickets avec des lignes cochées et la barre au-dessus qui montre le nombre de tickets sélectionnés et les boutons d'action groupée.
Le cadre rouge entoure la barre qui n'apparaît qu'à la première coche. À gauche le nombre de tickets sélectionnés, à droite les actions.Ouvrir l'image en taille réelle
La boîte de dialogue « Change status » avec un statut cible choisi et la ligne qui indique la portée.
Le statut cible est choisi ; en dessous, la portée et le motif pour chaque ticket qui ne suivra pas. Les deux sont là avant que tu cliques sur « Apply ».Ouvrir l'image en taille réelle
2

Attribuer plusieurs tickets à un agent en une fois

« Assign » ouvre la liste des agents. Les agents absents restent sélectionnables et ne sont que signalés comme tels, exactement comme sur un ticket isolé.

« Assign to me » est la même boîte de dialogue avec ton propre nom présélectionné. C'est un raccourci, pas une deuxième voie, et les mêmes règles s'y appliquent.

Une attribution peut envoyer un e-mail à l'agent. Il faut pour cela Professional et l'interrupteur « Send assignment e-mails » de l'équipe. Les messages lors d'une attribution à soi-même sont désactivés par défaut. La boîte de dialogue en indique le nombre à l'avance : « This sends 11 e-mail(s) to the selected agent. » Onze tickets font onze messages.

L'agent doit appartenir à l'équipe du ticket concerné. Une sélection qui couvre deux équipes ne peut donc pas être confiée d'un seul tenant à une seule personne. Ce n'est pas une limite de l'action groupée : la même règle s'applique sur un ticket isolé.

Une attribution ne peut pas être remise sur « personne ». Cela n'existe pas sur un ticket isolé, cela n'existe donc pas non plus dans un lot.

La boîte de dialogue « Assign » avec l'agent choisi, la portée et l'avertissement sur le nombre d'e-mails.
Sous le sélecteur figurent la portée et le nombre d'e-mails. L'encadré en dessous nomme chaque ticket qui ne suivra pas, avec son motif. Certains appartiennent déjà à Marco Rossi, les autres appartiennent à une équipe dont il ne fait pas partie.Ouvrir l'image en taille réelle
3

Appliquer un modèle de réponse à plusieurs tickets, les variables étant résolues par ticket

« Apply template » applique un modèle de réponse à tous les tickets sélectionnés. Chaque ticket reçoit le même commentaire qu'il recevrait si tu appliquais le modèle à la main.

La liste propose les modèles de toutes les équipes présentes dans la sélection. Un modèle apparaît dès qu'il convient à au moins un ticket sélectionné ; à combien il convient vraiment, c'est l'aperçu qui le dit ensuite.

Le serveur résout les variables par ticket, chaque client reçoit donc sa propre formule d'appel et son propre numéro de ticket. L'indication dans la boîte de dialogue le dit également.

Les actions du modèle sur les champs s'exécutent avec, et ses pièces jointes sont copiées sur chaque ticket.

Dans un lot, toutes les actions du modèle s'exécutent. Tu ne peux en retirer une que sur un ticket isolé ; si tu ne veux pas d'une action, utilise un modèle qui ne l'a pas.

S'il n'existe aucun modèle pour les équipes de la sélection, la boîte de dialogue le dit : « No reply template is available for the teams of the selected tickets. »

La boîte de dialogue « Apply template » avec un modèle choisi et l'indication que les variables sont résolues par ticket.
Le cadre rouge entoure l'indication sur les variables, ce qui distingue cela d'un texte formulé de la même façon pour tout le monde. En dessous figure la raison pour laquelle le modèle convient à 14 des 20 tickets : six d'entre eux appartiennent à une équipe à laquelle il n'est pas proposé.Ouvrir l'image en taille réelle
4

Un aperçu avant l'exécution, le résultat après, et les tickets sautés restent sélectionnés

Les trois boîtes de dialogue affichent la même ligne avant que quoi que ce soit ne se passe : « Applies to 19 of 20 selected ticket(s) ».

En dessous figure l'encadré « Will be skipped » avec une ligne par ticket qui ne suit pas, chacune nommant le numéro du ticket et le motif. Tu lis donc avant le clic pourquoi le nombre est plus petit que ta sélection.

Après l'exécution, il est indiqué « 19 changed, 1 skipped » et le même encadré devient « Not changed ». Le contenu est le même ; il a seulement cessé d'être une prévision pour devenir un constat.

Les motifs sont ceux du ticket isolé. Un ticket est déjà dans le statut cible. La transition n'est pas autorisée depuis son statut actuel. Il appartient à une équipe dont tu n'es pas responsable. L'agent choisi ne fait pas partie de son équipe. Il attend une approbation. C'est un incident collectif avec des signalements ouverts. C'est un ticket principal avec un sous-ticket ouvert.

Les tickets sautés restent sélectionnés, les tickets modifiés non. Un deuxième essai avec une autre cible est donc à un clic, et personne n'a à deviner lesquels sont encore en suspens.

L'aperçu est un deuxième avis, pas une autorisation. Quand l'action s'exécute, le serveur vérifie de nouveau chaque ticket : un ticket peut changer entre l'affichage et le clic.

Un appel accepte au maximum 200 tickets. Avec 20 lignes par page, on en est loin.

La boîte de dialogue après l'exécution : le nombre de tickets modifiés et sautés, et en dessous l'encadré « Not changed » avec les motifs.
L'encadré « Not changed » nomme le motif par ticket. Ici, un ticket attend encore son approbation.Ouvrir l'image en taille réelle
5

L'e-mail aux demandeurs est désactivé par défaut

Professional uniquement

Une case d'envoi de message n'apparaît que pour les modèles qui en envoient un, et seulement si le canal de messagerie est ouvert. Elle est vide par défaut, une action groupée n'écrit donc rien vers l'extérieur tant que tu ne l'as pas cochée.

Si le canal est fermé, le motif prend la place de la case : soit l'envoi d'e-mails est désactivé, soit les boîtes aux lettres des équipes sélectionnées n'envoient pas les messages liés aux actions de ticket. Tu le lis avant le clic, pas après dans le résultat.

Dès que tu la coches, un avertissement orange apparaît avec le nombre : « This sends 20 e-mail(s) to customers. » Le nombre vient de l'aperçu et correspond au nombre de tickets auxquels le modèle convient réellement.

Changer le statut et attribuer n'écrivent jamais aux clients. L'attribution envoie bien un e-mail, mais à l'agent. Appliquer un modèle en lot est la seule voie sur laquelle un message au client naît.

L'envoi dépend du canal de messagerie et donc de Professional. S'il est désactivé, aucun message ne part et l'historique n'en mentionne pas non plus. Il ne prétend jamais à une remise qui n'a pas eu lieu.

La boîte de dialogue « Apply template » avec la case d'envoi cochée et l'avertissement orange sur le nombre de messages aux clients.
La case est cochée et l'avertissement orange indique le nombre de messages. Sans la coche, aucun ne part.Ouvrir l'image en taille réelle
6

Chaque changement groupé apparaît dans l'historique du ticket isolé

Chaque changement fait par une action groupée apparaît dans l'historique du ticket isolé. Il y ressemble à n'importe quel autre changement, avec une ancienne et une nouvelle valeur.

Le demandeur voit ces lignes également. Pour lui, un changement de statut est le même événement, qu'il ait été déclenché seul ou en lot. Le cacher ne serait pas plus discret, seulement pire.

Une attribution groupée écrit la ligne avec la nouvelle personne responsable. Pour un ticket qui était sur « Open », une deuxième ligne suit avec le statut, parce que le ticket attribué passe alors à « Assigned ».

S'y ajoute une ligne interne qui porte la référence de l'exécution. Cette référence permet de retrouver plus tard tous les tickets de la même exécution. Le demandeur ne voit pas cette ligne.

Chaque ligne nomme la personne qui a déclenché l'action groupée.

Un ticket sauté ne reçoit aucune entrée, pas même une sur la tentative. Ce qui n'a pas eu lieu n'apparaît pas dans l'historique.

L'historique d'un ticket avec la ligne d'attribution et, en dessous, la ligne interne qui nomme l'exécution groupée.
La ligne la plus récente est en haut. Sous les lignes sur le temps et le centre de coûts figurent le statut, l'attribution et la référence de l'exécution. Le cadre rouge entoure la ligne interne, celle que le demandeur ne voit pas.Ouvrir l'image en taille réelle

Signalements multiples et incidents collectifs

Deux situations se ressemblent et n'en sont pas une. Si la même personne signale deux fois la même chose, un signalement doit disparaître. Si beaucoup de personnes signalent une panne, aucun ne doit disparaître. Chacune a sa voie, et la différence est le demandeur.

1

Fusionner deux signalements de la même personne

Coche les lignes dans la liste des tickets et clique sur « Multiple report ». Le bouton devient utilisable à partir de deux lignes cochées.

La boîte de dialogue demande d'abord : « Which ticket stays? » Le ticket le plus ancien est présélectionné, pour que le délai coure depuis le premier contact du demandeur et non depuis sa seconde tentative. Tu peux en choisir un autre.

En dessous figure le sens avec les deux numéros : « #11 will be closed and moved into #10. » Avant le clic, il est donc clair quel ticket reste.

Tout suit : les commentaires, les pièces jointes et la description du second signalement. La description devient un commentaire sur l'original, avec son auteur d'origine et sa date. La boîte de dialogue indique les nombres à l'avance.

Le temps saisi est déplacé, pas copié. Sinon, le même travail figurerait sur deux tickets et serait facturé deux fois.

Le second signalement n'est pas supprimé. Il est fermé et renvoie désormais à l'original, et son numéro reste valable.

Le demandeur ne reçoit pas d'e-mail séparé. Il est sur l'original et y voit tout. Le signalement fermé porte un commentaire qui nomme l'original, et il peut le lire.

Il n'y a pas d'annulation. C'est pourquoi tout figure dans la boîte de dialogue avant que tu cliques sur « Merge ».

Ensuite, l'historique des deux tickets consigne qui a fusionné quoi et quand.

La liste des tickets avec trois lignes cochées et la barre au-dessus contenant les boutons « Multiple report » et « Group into incident ».
Les cadres rouges entourent les deux boutons. Ils sont côte à côte et veulent dire deux choses différentes. Dans les lignes 12 à 14, on voit aussi la marque de l'incident collectif en cours.Ouvrir l'image en taille réelle
La boîte de dialogue « Multiple report for the same issue » avec le choix du ticket qui reste et le résumé.
Le cadre rouge entoure le sens. Il nomme les deux numéros, personne n'a donc à deviner quel ticket disparaît.Ouvrir l'image en taille réelle
La liste des tickets, réduite par la recherche à deux tickets : l'original et le signalement fusionné, qui est fermé.
La recherche contient un mot des deux titres, l'original et le signalement sont donc côte à côte. Le cadre rouge entoure le signalement fusionné. Il est fermé et figure quand même dans la liste, avec un renvoi vers le ticket dans lequel il a été déplacé.Ouvrir l'image en taille réelle
2

Les réponses à l'ancien numéro de ticket arrivent quand même

Professional uniquement

Avant de commencer : Cela demande la boîte de réception. Sans elle, il n'y a pas de réponse par courrier électronique à acheminer.

Le demandeur a l'ancien numéro de ticket dans sa boîte aux lettres. Il ne sait rien de la fusion de deux signalements et répond au message qu'il a.

Cette réponse arrive dans l'original. Le système suit la référence que porte le signalement fermé.

C'est pourquoi un signalement fusionné n'est jamais supprimé. Sans lui, la référence n'existerait pas et la réponse n'arriverait nulle part.

Toute personne qui a participé à l'ancien signalement peut aussi écrire sur l'original. La vérification se fait sur le ticket nommé dans le message.

Le signalement fermé avec le renvoi vers l'original et le commentaire que le demandeur y lit.
Les cadres rouges entourent le renvoi dans la carte de droite et le commentaire. C'est ce renvoi que suit une réponse par courrier électronique.Ouvrir l'image en taille réelle
3

Les signalements de personnes différentes ne peuvent pas être fusionnés

Si tu sélectionnes des tickets de personnes différentes, la boîte de dialogue ne les prend pas. Elle nomme chaque ligne refusée et son motif avant que tu cliques.

Le motif se lit : « Different requester — this is an incident, not a multiple report. » Il t'indique aussi où aller à la place.

C'est le garde-fou le plus important de toute la fonction. Si tu fusionnais trente signalements de trente personnes, vingt-neuf d'entre elles perdraient leur ticket et n'auraient jamais de nouvelles.

L'identité du demandeur est décidée d'abord par l'adresse e-mail du ticket. S'il n'y en a pas, c'est un nom tiers dans le champ « User » qui décide, et le même nom compte comme la même personne. Sinon, c'est le compte qui a créé le ticket qui compte.

C'est pourquoi le garde-fou vaut aussi pour les appels téléphoniques. Si un agent enregistre deux appels, les deux tickets ont été créés par lui. Des appelants différents restent malgré tout des appelants différents, parce que leurs noms sont dans le champ.

Si le demandeur ne peut pas être déterminé d'un côté, c'est refusé également. Inconnu n'est pas la même chose que la même personne.

D'autres motifs apparaissent dans le même encadré. Un incident collectif ne peut pas être fusionné. Un original fermé ne reprend plus rien. Et un signalement qui a déjà ses propres signalements ne suit pas, pour qu'aucune chaîne ne se forme.

L'encadré « Cannot be merged » dans la boîte de dialogue, avec le numéro du ticket et le motif.
Le cadre rouge entoure le motif. Le ticket 15 appartient à une autre personne, il reste donc à l'écart. Les deux autres tickets sont fusionnés malgré tout.Ouvrir l'image en taille réelle
4

Regrouper de nombreux signalements d'une même panne sous un seul incident collectif

Professional uniquement

Quand le serveur de fichiers tombe, vingt personnes le signalent. Chacun de ces signalements est un dossier à part avec son propre demandeur. Fusionner serait faux ici, car dix-neuf personnes perdraient leur ticket.

Coche les signalements et clique sur « Group into incident ». La boîte de dialogue propose trois voies : les ajouter à un incident collectif déjà ouvert, déclarer l'un des tickets sélectionnés comme l'incident collectif, ou créer un nouvel incident collectif avec son propre titre.

Si l'équipe a déjà un incident collectif ouvert, cette voie est présélectionnée. C'est la plus fréquente : la panne est connue depuis longtemps, seuls de nouveaux signalements continuent d'arriver.

Chaque ticket rattaché garde son demandeur, son statut et son propre délai. Rien ne disparaît. L'incident collectif ne regroupe que la réponse.

Tous les signalements d'un incident collectif doivent appartenir à la même équipe. Si une panne touche deux équipes, chacune a son propre incident collectif. Sinon, la résolution d'une équipe viderait la file de l'autre.

Tu peux aussi rattacher les retardataires depuis le ticket isolé. Si l'équipe a un incident collectif ouvert, une indication apparaît en haut avec « Assign » et « Not related ». Le système ne rattache jamais rien de lui-même : un ticket rattaché à tort recevrait une résolution qui ne le concerne pas, et serait fermé au passage.

Le ticket d'incident collectif indique combien de signalements y sont rattachés. Les tickets rattachés portent à leur tour le numéro de leur incident collectif, dans la liste et dans la carte de droite.

« Resolve incident » ferme l'incident collectif et répond à tous les signalements d'un coup. Le texte de résolution est obligatoire : c'est tout l'intérêt de la fonction, car il part vers toutes les personnes concernées.

Chaque ticket rattaché reçoit le texte comme commentaire public, est mis dans le statut choisi, et son demandeur reçoit son propre e-mail. Aucun envoi groupé, cela exposerait les adresses de toutes les personnes concernées.

Le message qui suit indique combien de tickets ont été fermés et combien de demandeurs ont été prévenus. Les deux nombres sont séparés, parce qu'un ticket sans adresse joignable reçoit un commentaire et un statut, mais pas d'e-mail.

Un ticket auquel tu as répondu et que tu as fermé toi-même entre-temps n'est pas touché. Il n'est pas fermé une seconde fois et on ne lui écrit pas de nouveau.

Tant que des signalements ouverts sont accrochés à un incident collectif, il ne peut pas être fermé par le changement de statut habituel. Sinon, vingt personnes resteraient sans réponse, en silence.

La boîte de dialogue « Group into incident » avec les trois voies et l'incident collectif ouvert, avec son nombre de tickets rattachés.
Le cadre rouge entoure l'incident collectif ouvert, avec à droite le nombre de signalements qui y sont déjà rattachés. Au-dessus des voies figure la phrase qui distingue ce cas de la fusion : rien ne disparaît.Ouvrir l'image en taille réelle
La barre d'indication sur un ticket isolé avec l'incident collectif ouvert et les boutons « Assign » et « Not related ».
Le cadre rouge entoure la barre d'indication. C'est une proposition, pas une action : la faire disparaître ne change rien sur le ticket.Ouvrir l'image en taille réelle
Le ticket d'incident collectif avec le nombre de signalements rattachés, le bouton « Resolve incident » et la case pour la bannière.
Les cadres rouges entourent le bouton qui résout, la case pour la bannière et le nombre de signalements rattachés.Ouvrir l'image en taille réelle
La boîte de dialogue « Resolve incident » avec le statut de fermeture et le texte de résolution saisi.
Le cadre rouge entoure l'indication au-dessus du champ. Elle dit où va ce texte unique : vers chaque ticket rattaché et vers chaque demandeur.Ouvrir l'image en taille réelle
Le signalement d'une personne concernée après la résolution : résolu, avec le texte de résolution comme commentaire public.
Le cadre rouge entoure la réponse. Elle figure sur le ticket de ce demandeur, avec son numéro et son historique. La même réponse figure sur le ticket de chaque autre personne concernée.Ouvrir l'image en taille réelle
5

L'incident collectif comme bannière et comme remarque dans la réponse automatique

Professional uniquement

La boîte de dialogue et le ticket d'incident collectif portent tous deux la case « Also show as a banner on the sign-in page ». Grâce à elle, tout le monde apprend la panne avant d'écrire un ticket de plus.

La bannière figure sur la page de connexion et dans le système une fois connecté. Elle nomme « Known incident » et le titre de l'incident collectif ; ce titre est donc un texte destiné aux clients.

Si plusieurs annonces sont actives, elles s'affichent l'une sous l'autre. Une maintenance annoncée pour samedi ne chasse pas la panne du jour, ni l'inverse.

Si quelqu'un crée quand même un nouveau ticket, la réponse automatique nomme l'incident collectif. Cela vaut pour un ticket déjà rattaché et pour chaque nouveau ticket de cette équipe, tant que l'incident collectif est ouvert et annoncé. Cela demande l'envoi d'e-mails.

Une fois l'incident collectif résolu, la bannière disparaît d'elle-même. Personne n'a à penser à la désactiver.

Sur la page « Maintenance and incident notices », tu peux voir quel incident collectif tourne actuellement comme bannière. L'interrupteur de cette page concerne la maintenance planifiée et ne s'applique pas aux incidents collectifs.

Le ticket d'incident collectif avec la case cochée et la bannière qui apparaît en bas en conséquence.
Le cadre rouge entoure la case. Elle prend effet aussitôt : l'annonce court en bas, sur chaque page du système.Ouvrir l'image en taille réelle
La page de connexion avec la bannière de l'incident collectif en cours entre le logo et le formulaire de connexion.
Le cadre rouge entoure la bannière. Elle est là avant la connexion, elle atteint donc aussi la personne qui veut seulement vérifier si elle doit écrire un ticket.Ouvrir l'image en taille réelle
Le ticket d'incident collectif après la résolution : résolu, avec le texte de résolution comme commentaire.
Le cadre rouge entoure le texte de résolution. Avec cette fermeture, la bannière a disparu elle aussi.Ouvrir l'image en taille réelle

SLA, calendrier et escalades

Des délais qui correspondent à tes horaires d'ouverture : une politique dit à quelle vitesse tu dois répondre et résoudre, un calendrier dit quand l'horloge tourne. Tout ce qui est dans ce bloc fait partie de Professional.

1

Politiques SLA avec des délais pour la première réponse et la résolution

Professional uniquement

Avant de commencer : Sans politique active, le système ne mesure rien : pas de délai, pas de colonne, pas de message. Et les horloges naissent à la CRÉATION d'un ticket : tout ce qui est arrivé avant que tu actives la politique ne reçoit pas de délai rétroactif. C'est voulu, sinon mille anciens tickets seraient dépassés le lendemain matin.

Tu mets en place les délais sous « Settings → SLA ». La page elle-même t'indique en haut quand aucune politique n'est active. Une politique a trois parties : un nom, les conditions et les objectifs. Les nouvelles politiques sont volontairement créées inactives, pour que tu puisses finir de les configurer avant qu'elles ne fassent quoi que ce soit.

Les conditions sont « Team », « Priority », « Main category » et « Subcategory ». Vide signifie « Any », c'est-à-dire « s'applique à tout », et non « ne s'applique à rien ». Si plusieurs politiques correspondent, celle qui a le plus petit numéro sous « Order » l'emporte ; c'est pourquoi la politique étroite est en haut et la générale en dessous.

Les deux champs de catégorie sont regroupés par équipe, parce que les catégories appartiennent à une équipe, mais on te les propose toutes, y compris celles des autres équipes. C'est voulu : lors d'une transmission, le ticket bouge, la catégorie non. Un ticket que le helpdesk a transmis à l'équipe réseau porte encore la classification du helpdesk, et une politique peut viser précisément cela. Une fois une catégorie principale choisie, le champ en dessous ne propose que les sous-catégories qui lui sont liées ; une paire qui ne peut pas exister sur un ticket est refusée à l'enregistrement.

Chaque politique a deux objectifs. « Time to first response » se termine avec la première réponse publique d'un agent ; un accusé de réception automatique et une note interne ne comptent explicitement pas. « Time to resolution » se termine dès que le ticket atteint un statut qui compte comme résolu (lequel, tu le règles sous « Settings → General → Status »). Les deux objectifs ont leurs propres minutes, leur propre calendrier et leur propre réaction à un dépassement.

Sur le ticket, les délais se trouvent à droite dans la carte « Details », et en dessous « Show deadline history » : un journal qui consigne chaque étape, démarré, en pause, repris, tenu, manqué, chacune avec un motif et le temps de travail consommé. Seuls les agents et les administrateurs le voient ; pour les clients, il n'est pas consultable.

Si quelqu'un change plus tard la priorité ou l'équipe, l'horloge passe à la politique qui correspond alors : le temps de travail consommé jusque-là est arrêté avec l'ancien calendrier, et ensuite les nouvelles valeurs s'appliquent. Si plus aucune politique ne correspond, l'horloge s'arrête sans verdict : elle ne compte ni comme tenue ni comme dépassée.

Si aucune politique ne correspondait à la création du ticket, l'horloge démarre la première fois qu'une politique correspond après un changement, par exemple une priorité plus élevée. Elle compte à partir de ce moment. L'horloge de la première réponse ne démarre que si personne n'a encore répondu.

De nouvelles horloges ne naissent que lorsqu'un ticket est rouvert. Les autres changements de statut ne créent pas de nouvelles horloges.

Une politique SLA avec son nom, son ordre, son interrupteur d'activation, les quatre conditions Team, Priority, Main category et Subcategory encadrées en rouge et les deux objectifs en dessous.
La politique s'applique à toutes les équipes, mais seulement à la priorité « High ». En dessous, les deux objectifs : 15 minutes pour la première réponse, 240 pour la résolution.Ouvrir l'image en taille réelle
Les délais d'un ticket : « Time to first response » avec la pastille « In time », en dessous « Time to resolution » avec le temps restant et l'historique des délais ouvert.
La première réponse est arrivée à temps, la résolution court encore. Le journal nomme le motif de chaque étape. À lire de bas en haut : démarré, recalculé avec « ticket fields changed », et enfin tenu avec la première réponse publique.Ouvrir l'image en taille réelle
2

Calendrier d'heures ouvrables par équipe

Professional uniquement

Un calendrier dit quand l'horloge tourne. Il a un nom, son propre fuseau horaire et un nombre libre de plages par jour de la semaine ; une pause de midi est simplement un jour à deux plages. Une plage peut passer minuit ; il apparaît alors « ends next day » à côté.

Le calendrier qui s'applique à une équipe se règle sur l'équipe (« Settings → Teams »). Sur l'objectif isolé d'une politique, tu peux le remplacer : « From the team » prend celui de l'équipe, ou tu en choisis un autre. C'est exactement ce qui produit le cas habituel : les pannes comptent 24 heures sur 24, tout le reste seulement pendant les heures de bureau.

Ce qui est compté, c'est le temps qui s'écoule réellement à l'intérieur de la plage, pas la différence entre deux lectures de l'horloge. Au changement d'heure, cela fait une différence : une journée continue en octobre a 25 heures, une équipe de nuit de 22 h à 6 h en fait sept au printemps au lieu de huit. Une plage de bureau de 9 h à 17 h n'est jamais concernée, parce que dans l'Union européenne le changement se fait la nuit.

Si aucun calendrier avec des heures d'ouverture ne peut être trouvé, aucun délai n'est créé : mieux vaut aucun qu'un délai deviné. Sur le ticket, une remarque apparaît à la place d'une date.

Le calendrier « Helpdesk business hours » avec le fuseau horaire Europe/Berlin encadré en rouge, les plages du lundi au vendredi de 09:00 à 17:00 et le bouton « Add opening hours ».
Cinq jours, une plage par jour. Le fuseau horaire appartient au calendrier, pas au serveur : un deuxième site reçoit simplement un deuxième calendrier.Ouvrir l'image en taille réelle
3

Jours fériés par import .ics ou saisis à la main

Professional uniquement

Avant de commencer : Nous ne livrons aucune donnée de jours fériés. Les jours fériés dépendent du LIEU, pas de la langue : 16 Länder allemands, 26 cantons suisses, 50 États américains, et cela change chaque année. Une liste livrée serait fausse un jour sans que personne le remarque. Prends le fichier .ics officiel de ta région, c'est une minute de travail par an.

Sous chaque calendrier se trouve la liste « Closed days ». Un clic sur « Import holidays (.ics) » prend un fichier de calendrier et rapporte ensuite quatre nombres : combien de jours ont été repris, combien remplacés, combien illisibles et combien étaient déjà là. Tu peux aussi saisir des jours isolés à la main.

Le symbole ↻ derrière un jour signifie « se répète chaque année ». Il n'est correct que pour les dates fixes : le 3 octobre tombe à la même date chaque année, le Vendredi saint et le lundi de Pentecôte dépendent de la date de Pâques et se déplacent. Les fêtes mobiles figurent donc dans la liste avec leur date concrète pour chaque année ; sur l'image, « Good Friday » sans le symbole.

Un jour de fermeture avale toute la plage de ce jour, y compris la partie qui déborde sur le jour suivant. Et quand un calendrier ne connaît aucun jour de fermeture pour les douze prochains mois, la page le dit explicitement ; sinon, le système compte en silence à travers les jours fériés et produit des délais faux.

Le bouton « Import holidays (.ics) » encadré en rouge et en dessous la liste des jours de fermeture, encadrée de la même façon.
Cinq jours de fermeture. Quatre portent le symbole ↻ pour « même date chaque année », le Vendredi saint non : il se déplace.Ouvrir l'image en taille réelle
Le calendrier « Around the clock » avec la remarque orange encadrée en rouge indiquant qu'il ne connaît aucun jour de fermeture pour les douze prochains mois.
La remarque n'est pas une erreur mais un avertissement : ce calendrier compte à travers tous les jours fériés. Pour un calendrier d'astreinte, c'est exactement ce qu'il faut.Ouvrir l'image en taille réelle
4

L'horloge se met en pause pendant l'attente du demandeur

Professional uniquement

La dispute la plus fréquente au sujet des délais est celle-ci : le ticket attend depuis trois jours la réponse du client, et l'horloge continue de tourner. C'est pourquoi chaque objectif a l'interrupteur « Pause while waiting for the requester », individuellement et non pour toute la politique.

C'est le statut qui décide si tu attends : sous « Settings → General → Status », chaque statut porte une marque indiquant s'il compte comme « en attente du demandeur ». Avec l'interrupteur activé, le délai se repose tant que le ticket est dans un tel statut. L'horloge murale continue de tourner, c'est pourquoi la liste affiche « Paused » au lieu d'un temps restant, et l'historique des délais contient « Paused » et « Resumed » avec leurs heures. Le temps d'attente ne compte pas non plus si le ticket est résolu directement depuis un tel statut.

Pour la première réponse, tu laisses en général l'interrupteur désactivé : tu dois la première réponse quoi qu'on attende. Pour la résolution, il est en général activé. L'image montre exactement ce réglage.

Les deux objectifs d'une politique avec les interrupteurs « Pause while waiting for the requester » encadrés en rouge, désactivé sur le premier objectif, activé sur le second.
Le même interrupteur, deux réponses : l'horloge de la première réponse tourne en continu, celle de la résolution se repose tant que c'est au client de jouer.Ouvrir l'image en taille réelle
5

Le temps restant dans la liste des tickets, avec un filtre sur les délais dépassés

Professional uniquement

Dès qu'une politique est active, la liste des tickets reçoit la colonne « Deadline ». Elle montre le temps restant du prochain délai ouvert (« 14h 53m »). Une fois qu'aucun délai du ticket ne court plus, le verdict s'y affiche : la pastille « In time » pour un délai tenu, le « Breached » rouge pour un délai manqué. Un ticket sans aucune horloge reçoit un tiret neutre, et c'est voulu : un ticket antérieur à la politique n'est pas un échec.

Si aucune politique n'est active, la colonne est absente ; elle ne reste pas là, vide. La même chose vaut pour le filtre : sous « Filter », la case « Breached only » n'apparaît que s'il y a des délais.

Un ticket a deux horloges mais la colonne n'a qu'une place : elle montre le délai OUVERT le plus urgent. Si la première réponse a été manquée et que la résolution court encore, la colonne montre le temps restant de la résolution avec un « ! » rouge à côté. Cette marque dit qu'un délai de ce ticket a déjà été dépassé, et c'est exactement ainsi que le filtre « Breached only » le trouve, parce qu'il demande n'importe quel délai dépassé, y compris un délai terminé depuis longtemps. Lequel des deux a été touché est écrit dans le ticket lui-même.

Tu peux aussi trier dessus : sous le même titre « Deadline » se trouve un champ avec « Due soonest first » et « Due latest first ». Les tickets sans horloge en cours finissent toujours en dernier ; ils ne sont pas les moins urgents, ils ne sont simplement pas concernés. Le tri par délai l'emporte sur le tri par « Updated at » : aucune liste ne peut satisfaire deux ordres à la fois.

La liste des tickets avec la case « Breached only » cochée, le filtre encadré en rouge et la colonne « Deadline » encadrée de la même façon.
Avec la case « Breached only » cochée, il ne reste qu'un seul ticket. Sur le ticket 4, la première réponse a été manquée. La colonne montre encore un temps restant en cours, parce qu'elle montre le prochain délai OUVERT, et ici c'est la résolution. Le « ! » rouge à côté nomme le dépassement.Ouvrir l'image en taille réelle
Un ticket avec la pastille rouge « Breached » sur la première réponse et un temps restant en cours sur la résolution, en dessous l'historique des délais.
Le même ticket, deux horloges, deux états. Le journal contient le motif : « due date passed », après 16 minutes de temps de travail consommé.Ouvrir l'image en taille réelle
6

En cas de dépassement : prévenir, ou transmettre le ticket à une autre équipe

Professional uniquement

Avant de commencer : La transmission n'est volontairement pas le réglage par défaut. Elle déplace la responsabilité, libère la personne responsable et remet le statut à zéro : un ticket sur lequel quelqu'un travaille en ce moment se retrouve ensuite ailleurs. Choisis-la seulement quand c'est exactement l'intention.

Par objectif, tu règles sous « When breached » ce qui se passe en cas de dépassement : « Record only » se contente de le consigner, « Notify assignee and observers » envoie un message à la personne responsable et aux observateurs (pas à toute l'équipe), « Hand over to another team » transmet le ticket. Pour la transmission, tu dois choisir une équipe cible ; une politique sans équipe cible est refusée à l'enregistrement, parce qu'elle aurait l'air configurée et ne ferait rien.

L'action s'exécute exactement une fois par horloge. Sans ce verrou, un redémarrage du serveur renverrait le même message. La marque « déjà fait » est posée même quand l'envoi a échoué : un message qui n'est pas arrivé vaut mieux qu'une boucle qui en envoie un nouveau chaque minute.

Le dépassement lui-même est daté du moment où l'échéance est tombée, pas du passage de vérification ; sinon, les rapports dépendraient du rythme du service de contrôle. Et il se mesure au temps de travail consommé : une horloge en pause ne peut pas être dépassée, même quand l'échéance est passée depuis longtemps.

La transmission remet le statut sur « Open ». Les lignes d'historique qui s'y rapportent sont internes ; le client ne voit sur le ticket que le nouveau statut et la nouvelle équipe.

Une politique d'exemple inactive avec le choix « When breached: Hand over to another team » encadré en rouge et l'équipe cible « Network ».
La phrase sous l'équipe cible dit ce qui se passe : le ticket passe à cette équipe, la personne responsable actuelle est libérée. L'interrupteur « Active » est désactivé ici ; une politique inactive ne fait rien.Ouvrir l'image en taille réelle
7

Les indicateurs SLA dans les rapports

Professional uniquement

Sous « Reports », tu choisis la période et tu appuies sur « Generate report » ; sans ce clic, la page reste vide. Le rapport contient ensuite le bloc « Service level agreements » avec une ligne par objectif : tenus, dépassés, encore en cours, taux atteint et temps moyen consommé.

Le comptage se fait par objectif, pas par ticket ; c'est aussi écrit sous le tableau. Un ticket qui a les deux objectifs apparaît donc deux fois, une fois dans chaque ligne.

Le taux atteint ne compte que les horloges tranchées. Celles qui courent n'ont pas leur place au dénominateur, sinon tout SLA fraîchement activé aurait l'air catastrophique au début et s'améliorerait tout seul. S'il n'y a pas encore une seule horloge tranchée, un tiret apparaît, et non « 0 % ».

Si tu travailles avec des incidents collectifs, il y a une ligne supplémentaire « Achieved without group incidents » : un seul incident collectif avec cent tickets rattachés fausserait sinon le taux dans les deux sens. Elle laisse de côté chaque ticket lié à un incident collectif.

Dans ce bloc, les agents ne voient que leurs propres équipes. Sans Professional, le bloc n'apparaît que s'il existe des données de délais antérieures ; il reste alors lisible.

Le bloc de rapport « Service level agreements » avec les colonnes Met, Breached, Still running, la colonne « Achieved » encadrée en rouge et le temps moyen consommé.
Pour la première réponse, trois délais sont tenus et un est dépassé, dix courent encore. Cela fait 75 %. Les deux colonnes à droite n'apparaissent que s'il existe des incidents collectifs : elles laissent de côté chaque ticket lié à un incident collectif.Ouvrir l'image en taille réelle

Suivi du temps par ticket

Les agents saisissent le temps qu'a coûté un dossier. Il s'agit du travail sur le ticket, pas de la présence d'une personne : ce n'est explicitement pas une pointeuse. Tout ce bloc fait partie de Professional.

1

L'activer avant que quoi que ce soit ne soit saisi

Professional uniquement

Le suivi du temps est désactivé comme réglage d'usine. Tant qu'il est désactivé, il n'y a ni champ ni colonne. La carte « Time spent » du rapport n'apparaît alors que si du temps a été saisi dans la période choisie.

Un champ mort serait pire que pas de champ du tout, la fonction disparaît donc complètement au lieu de rester là, grisée.

L'interrupteur se trouve sous « Settings → General » sur la carte « Time tracking per ticket » et s'appelle « Enable time tracking ».

Toutes les équipes y participent alors. Pour en exclure une, tu le désactives sur l'équipe elle-même, sous « Settings → Teams » dans l'encadré « Team details ».

Une entreprise avec une équipe informatique interne et une équipe en contact avec les clients n'en a souvent besoin que pour la seconde.

Si tu désactives le suivi du temps plus tard, les entrées existantes restent lisibles et exportables : elles sont une base de facturation, pas un confort. Rien de nouveau ne peut être saisi. Les entrées existantes ne peuvent alors plus être modifiées ni supprimées non plus.

La carte « Time tracking per ticket » sous « Settings → General » avec l'interrupteur principal, l'arrondi, les boutons rapides et le chronomètre.
Tous les réglages du suivi du temps sur une seule carte. Le cadre rouge entoure l'interrupteur principal, et en dessous figure ce que sa désactivation signifie.Ouvrir l'image en taille réelle
L'encadré « Team details » avec l'interrupteur « Time tracking » et sa phrase d'explication.
Sur l'équipe, tu exclus une équipe isolée. Le cadre rouge entoure l'interrupteur ; les entrées existantes restent visibles même alors.Ouvrir l'image en taille réelle
2

Saisir le temps passé sur un ticket

Professional uniquement

Le ticket porte une carte appelée « Time spent ». « Log time » ouvre la saisie.

Des boutons rapides se trouvent à côté du champ : un clic sur « 30m » saisit trente minutes. Les boutons qui apparaissent se règlent dans les paramètres.

Le champ « Duration » accepte aussi la saisie libre : « 90 » fait quatre-vingt-dix minutes, « 1.5h » une heure et demie, et « 1h 30m » également. Un nombre sans unité est toujours en minutes.

Une saisie que le système ne comprend pas entièrement est refusée. « 1h in the evening » ne devient pas une entrée d'une heure, cela devient un message d'erreur.

Dans « What for (optional) », tu écris à quoi le temps a servi. Le texte part dans l'export et n'apparaît pas dans l'historique du ticket.

Plusieurs agents saisissent du temps sur le même ticket. Chaque entrée porte son jour, sa note et le nom de la personne qui a fait le travail.

Le temps est saisi sur un jour, pas sur une heure précise. La saisie a pour cela un champ de date qui commence à aujourd'hui ; pour compléter la veille, tu y choisis le jour précédent. Un jour dans le futur n'est pas accepté. Une heure précise revendiquerait une exactitude que la saisie n'a pas.

La saisie ouverte de la carte « Time spent » avec les boutons rapides, le champ de durée, la date, l'interrupteur « Billable » et le champ de note.
Le cadre rouge entoure les boutons rapides. À côté, le champ accepte la saisie libre. Son texte d'exemple montre les formats acceptés.Ouvrir l'image en taille réelle
La liste des entrées de temps d'un ticket avec trois entrées de deux agents, chacune avec une date, une note et un nom.
Trois entrées, deux agents, un ticket. Le cadre rouge entoure une entrée : durée, jour et nom en haut, la note en dessous.Ouvrir l'image en taille réelle
3

Le chronomètre

Professional uniquement

Pour les longues séances, il y a un chronomètre sur le ticket : « Start timer » le lance, « Pause » l'arrête.

Le chronomètre ne crée jamais d'entrée de lui-même. Il propose le temps écoulé, et rien n'est enregistré tant que tu n'as pas appuyé sur le bouton « Log … », qui indique le temps. Ce qui est saisi, c'est le temps réellement écoulé.

Il remplace le calcul mental, pas la connaissance. Sans lui, la fonction est complète, parce que taper la valeur est la voie principale.

Ouvrir un autre ticket met en pause le chronomètre en cours, et le nouveau ticket t'indique à quel ticket il est rattaché. Si du temps non saisi attend encore sur un autre ticket et que tu démarres le chronomètre ici, l'application pose d'abord la question. La question « Start timer » propose « Log … » pour le temps de l'autre ticket, « Discard » et « Cancel ». Elle apparaît à partir d'une minute écoulée.

Une fenêtre masquée n'est pas une pause. Le chronomètre continue de tourner si tu te contentes de cliquer ailleurs.

Contre un chronomètre laissé en marche toute la nuit, il y a une durée maximale. La valeur est plafonnée, jamais jetée, et l'agent en est informé.

Le chronomètre est désactivé comme réglage d'usine. Tu le trouves dans les paramètres sous « Stopwatch on the ticket ».

Le chronomètre en marche sur la carte « Time spent » avec son affichage, « Pause », « Discard » et le bouton qui enregistre.
Le chronomètre tourne. Le cadre rouge entoure le bouton qui reprend l'affichage ; jusque-là, rien n'est enregistré.Ouvrir l'image en taille réelle
4

Facturable ou non

Professional uniquement

Chaque entrée porte un interrupteur « Billable ». Le temps est saisi une fois, et l'interrupteur décide s'il va sur la facture.

C'est pourquoi le ticket peut montrer deux totaux : tout ce qui est saisi à gauche, la somme facturable à droite. Le second total n'apparaît que lorsqu'il diffère du premier.

Il n'y a pas de type distinct pour le geste commercial. Le geste commercial, le travail sous garantie et les reprises internes portent un nom différent dans chaque entreprise, et le système ne connaît que la seule distinction dont dépend l'argent.

Voici comment saisir un geste commercial : saisis le temps comme d'habitude, désactive « Billable » et écris le motif dans la note.

L'entrée porte alors visiblement « not billable ». Les minutes restent dans le total saisi, parce que le travail a bien eu lieu.

Qui ne saisit pas du tout le temps perd justement le chiffre qui explique plus tard pourquoi un client a été si peu facturé.

Si l'essentiel de ton travail n'est pas facturable, inverse le réglage par défaut avec l'interrupteur « New entries are billable by default ».

La carte « Time spent » avec les deux totaux dans son en-tête et une entrée portant la marque « not billable ».
Les deux totaux sont côte à côte en haut. Le cadre rouge entoure l'entrée sans coche : ses minutes comptent à gauche et pas à droite.Ouvrir l'image en taille réelle
5

À la minute ou arrondi vers le haut

Professional uniquement

Comme réglage d'usine, tout est facturé à la minute. Qui facture au quart d'heure règle deux valeurs.

« Rounding increment (minutes) » est le pas. Chaque entrée est arrondie vers le haut au multiple suivant.

« Minimum per entry (minutes) » est le plancher. Chaque entrée est facturée au moins à cette valeur.

Les deux agissent l'un après l'autre : d'abord le plancher, puis le pas. Avec un plancher de 20 et un pas de 15, cinq minutes deviennent trente, parce que le résultat doit satisfaire les deux.

Sous les deux champs figure une phrase d'exemple avec tes propres valeurs. Elle est calculée, pas affirmée.

Seule la valeur facturée est arrondie, et seulement par entrée, jamais le total. Deux petites entrées sont donc arrondies vers le haut deux fois.

Le temps saisi reste intact. Changer l'arrondi plus tard ne fausse aucune donnée ancienne, parce que la valeur est calculée au moment de l'affichage.

Tu vois les deux sur l'entrée : là où l'arrondi change la valeur, le résultat figure à côté entre parenthèses.

Les champs « Rounding increment » et « Minimum per entry » avec la phrase d'exemple calculée et la remarque en dessous.
Le cadre rouge entoure la phrase d'exemple, calculée à partir des valeurs au-dessus. La phrase en dessous dit ce à quoi l'arrondi ne touche pas.Ouvrir l'image en taille réelle
Une entrée de temps de cinq minutes avec la valeur facturée à côté, entre parenthèses.
Le cadre rouge entoure l'entrée que l'arrondi change. À gauche figure ce qui a été saisi, entre parenthèses ce qui est facturé.Ouvrir l'image en taille réelle
6

Une saisie de temps avant la fermeture

Professional uniquement

Un prestataire ne veut souvent aucun ticket fermé sans temps saisi. Il y a un interrupteur pour cela.

Il s'appelle « Require a time entry before resolving or closing » et est désactivé comme réglage d'usine.

Il ne s'applique que lorsqu'une personne change le statut, et seulement aux personnes qui peuvent saisir du temps. Il s'applique aussi quand un modèle de réponse définit le statut sur un ticket isolé. Un agent sans entrée reçoit un message et le ticket reste ouvert.

La fermeture automatique, la fusion et les actions groupées ne sont jamais bloquées. Sinon, il y aurait des tickets que plus personne ne pourrait fermer.

C'est l'interrupteur le plus dangereux de toute la fonction. Ne l'active que lorsque ton équipe saisit vraiment le temps à chaque fois.

L'interrupteur « Require a time entry before resolving or closing » avec la phrase qui nomme les exceptions.
Le cadre rouge entoure l'interrupteur. La phrase en dessous nomme les trois cas qui ne sont jamais bloqués.Ouvrir l'image en taille réelle
7

La colonne « Time » dans la liste des tickets

Professional uniquement

La liste des tickets reçoit une colonne « Time » qui montre combien a déjà été saisi sur un dossier.

Tu ne l'actives pas. Elle apparaît dès que le suivi du temps est activé. Seuls les agents et les administrateurs la voient. Tu peux la retirer de ta liste avec « Columns ».

Sur les fenêtres étroites, elle est l'une des premières à disparaître de nouveau. La liste garde alors les colonnes sans lesquelles un ticket ne se trouve pas.

La liste des tickets avec une colonne « Time » et des valeurs sur les tickets qui portent du temps saisi.
Le cadre rouge entoure la colonne. Seuls les tickets avec du temps saisi portent une valeur.Ouvrir l'image en taille réelle
8

Le rapport

Professional uniquement

Un temps qui ne figure que sur un ticket isolé n'est pas une base de facture. C'est pourquoi la page des rapports porte une carte « Time spent ». Seules les personnes qui ont l'autorisation « Time tracking: see the report » voient la carte.

Quatre nombres figurent en haut : le temps saisi, le temps facturé, le nombre d'entrées et le nombre de tickets qui portent du temps.

Ce dernier nombre est le plus important après le total. Quarante heures sur trois tickets sur cinq cents n'est pas une analyse, ce sont trois agents qui sont les seuls à saisir.

En dessous viennent les répartitions : par demandeur, par équipe, par catégorie et par jour.

S'y ajoute un tableau par champ personnalisé. C'est la voie vers une facturation par société ou par centre de coûts : tu crées un champ personnalisé, tu le remplis sur le ticket, et le rapport regroupe dessus.

La période en haut de la page porte sur le jour où le travail a été fait. Un travail de juillet sur un ticket de juin figure donc dans le rapport de juillet.

Une remarque sous les boutons d'export mérite d'être prise au sérieux : les chiffres viennent d'entrées faites par des personnes et de tes règles d'arrondi. Ce sont une base de travail, pas une facture auditée.

La page des rapports avec la carte « Time spent », ses quatre nombres et les tableaux en dessous.
La carte se trouve sur la page des rapports. Le cadre rouge montre où la trouver.Ouvrir l'image en taille réelle
Les quatre tuiles de la carte : temps saisi, temps facturé, entrées et tickets avec du temps.
Le cadre rouge entoure le nombre de tickets avec du temps. Il met en perspective le total à sa gauche.Ouvrir l'image en taille réelle
Les tableaux par demandeur, par champ personnalisé, par équipe et par catégorie, chacun avec le temps saisi et le temps facturé.
Le cadre rouge entoure la répartition par catégorie. Chaque ligne nomme les deux totaux.Ouvrir l'image en taille réelle
Le tableau du champ personnalisé « Cost centre » avec une ligne par centre de coûts.
Un tableau par champ personnalisé. Le cadre rouge entoure la répartition par centre de coûts.Ouvrir l'image en taille réelle
9

L'export pour la comptabilité et pour le client

Professional uniquement

Trois boutons se trouvent sous la carte. Ils livrent les entrées individuelles, pas les totaux de la page. Ils contiennent exactement les entrées qui correspondent à tes filtres.

Ce sont deux destinataires, pas trois formats de fichier. « Export entries (CSV) » et « Export entries (Excel) » vont à la comptabilité : les deux sont complets et ne sont jamais coupés.

« Export entries (PDF) » est le document destiné à un être humain. Il va au client en pièce jointe de la facture. Le PDF n'a pas de colonne pour la note.

Le PDF est plafonné à 20 000 entrées, et le document le dit lui-même. Personne ne lit de toute façon une facture avec plus de lignes que cela.

Les trois fichiers sont construits à partir de la même source : les filtres, l'arrondi, les colonnes et les chiffres n'existent qu'une fois, les trois ne peuvent donc pas diverger.

Une entrée non facturable a une cellule vide dans la colonne facturable, pas un zéro. Un zéro serait additionné dans un tableau croisé dynamique.

Si la « Per-agent evaluation » du suivi du temps est désactivée, la colonne « Agent » manque dans les trois fichiers. Si ta licence repasse en Basic, les entrées existantes restent lisibles et exportables.

Les trois boutons « Export entries (CSV) », « (Excel) » et « (PDF) » avec les phrases qui nomment la différence.
Le cadre rouge entoure les trois boutons. Les phrases en dessous disent à qui chaque fichier est destiné.Ouvrir l'image en taille réelle
Une page du PDF généré avec le tableau des entrées individuelles. Les totaux figurent en page 1.
Voilà le document que le client reçoit. Chaque ligne est une entrée avec sa date, son ticket, son agent, sa note et les deux valeurs.Ouvrir l'image en taille réelle
10

Les clients ne voient pas le temps saisi

Professional uniquement

Un client ne voit jamais les entrées de temps, pas même sur son propre ticket.

Ce n'est pas un réglage mais un verrou dans le serveur. Il n'y a aucun interrupteur qui l'ouvre.

La raison se trouve dans les entrées elles-mêmes : les notes sont écrites pour l'équipe. Elles disent ce qui a mal tourné et combien de temps la recherche de la cause a pris.

Les autres systèmes de ce genre font la même chose. Là où le temps atteint le client, il l'atteint sous forme de document.

C'est à cela que sert l'export PDF : il part avec la facture et non sur le ticket dans le portail client.

Plus à ce sujet dans la carte : L'export pour la comptabilité et pour le client

Le même ticket tel que le client le voit : la description, les commentaires et le statut, mais pas de carte « Time spent ».
Le même ticket, vu par le demandeur. La carte avec le temps manque entièrement.Ouvrir l'image en taille réelle
11

La répartition par agent peut être désactivée

Professional uniquement

Le rapport peut en plus montrer qui a saisi combien. Comme réglage d'usine, il ne le fait pas.

Le temps par personne est une donnée de performance, et dans beaucoup d'entreprises le comité social et économique a son mot à dire.

L'interrupteur s'appelle « Per-agent evaluation » et se trouve dans les paramètres.

Tant qu'il est désactivé, le serveur ne livre même pas les chiffres. Le tableau n'est pas masqué, il n'existe pas.

Cette différence compte. Un verrou que seul l'affichage connaît n'est pas un verrou.

Plus à ce sujet dans la carte : Aucun historique de disponibilité, aucune analyse par personne

Le rapport avec les tableaux par équipe et par jour, sans tableau par agent.
Voilà le rapport comme réglage d'usine. Entre la catégorie et le jour, il n'y a pas de tableau par agent.Ouvrir l'image en taille réelle
Le même endroit avec l'interrupteur activé : un tableau « By agent » avec une ligne par agent.
Le même endroit après l'activation de l'interrupteur. Entre « By category » et « By day », il y a maintenant un tableau par agent.Ouvrir l'image en taille réelle

Rapports et tableaux de bord

Le tableau de bord montre où en est une équipe. Le rapport répond à une question que tu poses. Les deux ne font que lire ; aucun des deux ne change jamais un ticket. À part tes propres champs, tout ce bloc fait partie de Basic.

1

Le tableau de bord : où en sont les choses

En haut, il y a une tuile par statut avec son compteur. En dessous figurent trois chiffres pour toute l'équipe : « Total tickets », « Tickets which are not Closed » et « Avg. resolution time ».

Le chiffre du milieu est le plus important. Il dit combien de travail est actuellement ouvert. Les tickets résolus y comptent jusqu'à leur fermeture.

« Avg. resolution time » reste vide tant qu'aucun ticket n'a été résolu. Un tiret est plus honnête qu'un zéro.

La carte « Top 3 longest open tickets » nomme les trois dossiers ouverts les plus anciens avec leur âge. Ce sont ceux dont plus personne ne parle. La carte « Top agents closed tickets » compte les tickets fermés par chaque agent. Une sélection sur la carte règle combien de jours elle remonte.

En dessous se trouvent trois graphiques : « Tickets by status », « Tickets by priority » et « Tickets by category ».

Le tableau de bord montre l'état actuel. Tu ne peux pas y choisir de période pour tout le tableau de bord, c'est à cela que sert le rapport.

Le tableau de bord de l'équipe Helpdesk avec les tuiles de statut en haut et les trois chiffres clés en dessous.
Le cadre rouge entoure le total. Dans cet exemple, l'équipe a 22 tickets, dont 18 non fermés.Ouvrir l'image en taille réelle
La carte « Top 3 longest open tickets » avec trois dossiers et leur âge.
Un clic sur une entrée ouvre le ticket.Ouvrir l'image en taille réelle
Les graphiques « Tickets by status », « Tickets by priority » et « Tickets by category ».
Les catégories sont celles de l'équipe. Une autre équipe en montre d'autres ici.Ouvrir l'image en taille réelle
2

Chaque équipe a son propre tableau de bord

La barre latérale porte une entrée par équipe. Elle s'appelle « Dashboard » suivi du nom de l'équipe.

Chaque entrée ne montre que les tickets de son équipe. Les chiffres, les catégories et les dossiers les plus anciens sont donc différents d'une équipe à l'autre.

Il n'y a pas d'autorisation par tableau de bord. Les agents voient les tableaux de bord de toutes les équipes dont ils font partie, les administrateurs les voient tous. Les clients ne voient le tableau de bord d'une équipe que si l'interrupteur de l'équipe « Can see their own tickets of this team in the dashboard and in reports » est activé.

Une personne sans droit sur un tableau de bord ne voit pas l'entrée du tout. Une entrée bloquée mais visible ne fait que soulever des questions.

Le tableau de bord de l'équipe Helpdesk, avec l'entrée « Dashboard · Helpdesk » de la barre latérale mise en évidence.
Le cadre rouge entoure l'entrée de la barre latérale. Dans cet exemple, Helpdesk affiche 22 tickets.Ouvrir l'image en taille réelle
Le même tableau de bord pour l'équipe réseau, avec d'autres chiffres et d'autres catégories.
La même page, une autre équipe. Ici, ce sont 6 tickets, et les catégories sont « Wi-Fi » et « Firewall ».Ouvrir l'image en taille réelle
3

Générer et filtrer le rapport

La page « Reports » est vide quand tu l'ouvres. Seul l'encadré des filtres est là.

Seul le clic sur « Generate report » lance le calcul. Cela prend un instant, parce que toutes les sections sont calculées d'un coup.

C'est voulu. Un rapport qui recalculerait à chaque frappe serait inutilisable sur un grand jeu de données.

Ensuite, quatre chiffres clés figurent en haut et les graphiques en dessous.

Chaque graphique nomme ses chiffres. Les anneaux impriment le compte et la part dans la légende à côté ; les barres impriment le compte au-dessus de la barre.

L'encadré des filtres au-dessus est l'endroit où tu poses la question. Tu peux choisir la période avec « From » et « To », l'équipe, le statut, l'agent, le demandeur, le site, la priorité, la catégorie principale et la sous-catégorie, ainsi que le canal par lequel le ticket est arrivé.

Si tu remplis plusieurs champs, ils s'appliquent en même temps. « Période de juillet, équipe Helpdesk, priorité High » est une seule question.

La période porte sur le jour de création du ticket.

Il y a une exception. Le rapport du temps porte sur le jour où le travail a été fait. Un travail de juillet sur un ticket de juin apparaît donc dans le rapport de juillet.

Après chaque changement de filtre, tu dois cliquer de nouveau sur « Generate report ».

Cette page porte aussi les analyses des autres fonctions. Elles n'apparaissent que si la fonction est activée et qu'il s'est passé quelque chose dans la période choisie.

Elles sont expliquées là où elles ont leur place : les délais dans « Les indicateurs SLA dans les rapports », les évaluations dans « Le rapport sur les évaluations », la répartition dans « Le rapport sur la répartition » et le temps passé dans « Le rapport ».

La page des rapports juste après son ouverture : seulement l'encadré des filtres, aucun chiffre.
Le cadre rouge entoure « Generate report ». Tant que personne ne clique dessus, la page reste vide.Ouvrir l'image en taille réelle
L'encadré des filtres de la page des rapports avec la période, l'équipe, le statut, l'agent, les catégories et le canal.
Tous les champs s'appliquent en même temps. Vide signifie « tous ».Ouvrir l'image en taille réelle
Le rapport généré avec quatre chiffres clés et les premiers graphiques en dessous.
Dans cet exemple, il y a 28 tickets. Chaque barre porte son compte au-dessus, et les anneaux montrent le compte et la part à côté.Ouvrir l'image en taille réelle
4

Filtrer et regrouper selon tes propres champs

Professional uniquement

Si tu as créé tes propres champs, le rapport les propose comme les champs intégrés. Cela vaut pour chaque type de champ, y compris « Integer », « Decimal », « Date » et « Yes / No ».

Chacun de tes champs reçoit un filtre dans l'encadré et son propre graphique dans le rapport.

Cela répond à des questions que seule ton entreprise se pose. « Combien de tickets vont à quel centre de coûts ? » en fait partie.

Les noms des graphiques sont les noms de tes champs. Ils ne sont pas traduits, parce qu'ils viennent de ton installation.

Où créer tes propres champs est décrit sous « Champs personnalisés ».

Deux graphiques construits à partir de champs personnalisés : « Asset tag » et « Cost centre ».
Cet exemple a les champs « Asset tag » et « Cost centre ». Ton installation montre les tiens ici.Ouvrir l'image en taille réelle
5

Les colonnes que le rapport montre

Sous « Settings → Report Settings », tu décides des champs que le rapport propose.

La page a trois sections : « Admin », « Agent » et « Customer ». Chaque section porte la même liste avec ses propres interrupteurs.

Un champ que tu désactives ici disparaît pour ce rôle du filtre et de l'export. Cela comprend les fichiers CSV et Excel.

Comme réglage d'usine, les administrateurs et les agents voient tout. Les clients voient moins, parce qu'ils n'ont besoin ni de l'agent, ni du site, ni de la priorité.

Tes propres champs apparaissent sous « Custom fields » dans la même liste.

La page « Report Settings » avec les trois sections « Admin », « Agent » et « Customer ».
Le cadre rouge entoure la section « Customer ». Chaque rôle a sa propre liste.Ouvrir l'image en taille réelle
6

Les clients tirent leur propre rapport

Un client peut ouvrir le même rapport qu'un agent. Il n'y voit que ses propres tickets.

La limite est dans le système, pas dans le filtre. Un client ne peut pas la contourner, même en tapant l'adresse à la main.

Tu l'ouvres sur l'équipe. L'interrupteur se trouve sous « Settings → Teams » et s'appelle « Can see their own tickets of this team in the dashboard and in reports ».

Comme réglage d'usine, il est désactivé. Tant qu'il l'est, un client ne trouve ni le tableau de bord ni les rapports.

Les colonnes que le client voit viennent de la section « Customer » des paramètres de rapport.

La sortie en fichier lui est ouverte également. Un client peut télécharger ses propres tickets en CSV, en Excel ou en PDF.

L'interrupteur d'équipe qui ouvre le tableau de bord et les rapports à un client.
L'interrupteur se trouve dans l'encadré « Customer permissions ». Il s'applique à cette seule équipe.Ouvrir l'image en taille réelle
La page des rapports depuis un compte client, avec moins de filtres et des chiffres plus petits.
La même page depuis le compte de Julia Becker. Dans cet exemple, elle voit 8 tickets au lieu de 28, et le filtre par agent manque.Ouvrir l'image en taille réelle
7

Exporter en CSV, en Excel ou en PDF

Sous l'encadré des filtres se trouvent trois boutons : « CSV export », « Excel export » et « PDF export ».

Les trois utilisent les filtres tels qu'ils sont au moment où tu cliques.

Le fichier Excel a la feuille « Key figures » avec les chiffres. La feuille « Tickets » avec les dossiers individuels n'est ajoutée que si tu coches « Include ticket table in export ».

Les chiffres et les graphiques sont toujours inclus. La liste des tickets individuels seulement si tu coches « Include ticket table in export ».

Quand tu la coches, le nombre réel de tickets et le nombre de pages estimé apparaissent en dessous.

Avec un très grand nombre de tickets, un avertissement rouge apparaît en plus. Il dit que l'export peut prendre un moment.

Le CSV et l'Excel contiennent toutes les lignes. Le PDF s'arrête à 20 000 tickets et l'écrit dans le document.

La limite apparaît déjà sur la page avant l'export. Une limite qu'on n'apprend que dans le document terminé arrive trop tard.

Les trois boutons d'export et en dessous la case du tableau des tickets.
Le cadre rouge entoure la case. Ce n'est qu'une fois cochée que la ligne avec le nombre de tickets apparaît. Dans cet exemple, cela fait 28 tickets et environ 4 pages.Ouvrir l'image en taille réelle
8

Le PDF imprime les chiffres à côté des graphiques

Le PDF est fait pour être transmis. Il contient les mêmes graphiques que ceux affichés à l'écran.

Sous chaque graphique figurent le chiffre à partir duquel il a été construit et la part en pourcentage.

C'est pour cela qu'ils sont là. Une barre peut être regardée, mais pas vérifiée.

À l'écran, le pointeur de la souris montre le même chiffre. Sur une feuille imprimée, il n'y a pas de pointeur.

Le document nomme la période et le jour de sa création en haut. Sans date dans le filtre, il n'y a pas de période à nommer.

Une page du PDF généré avec des graphiques et leurs chiffres en dessous.
Le document tel que le destinataire le reçoit. Sous chaque graphique figurent le compte et la part.Ouvrir l'image en taille réelle

Enquêtes de satisfaction (CSAT)

Une fois un ticket fermé, tu demandes à tes clients comment cela s'est passé. Tout ce bloc fait partie de Professional.

1

L'enquête après la fermeture

Professional uniquement

Avant de commencer : Deux choses doivent être en place, sinon rien ne se passe. L'envoi d'e-mails doit être configuré. Et sous « Settings → Security », l'adresse publique de cette installation doit être correcte, parce que le lien du message est construit à partir d'elle. Avec une mauvaise adresse enregistrée là, le système envoie quand même l'enquête, et ton client aboutit sur une page qui n'existe pas.

Quand un ticket est fermé, le demandeur reçoit un e-mail avec cinq lignes numérotées, une par note d'une à cinq étoiles. Chaque ligne est un lien à part, et un clic constitue toute la réponse.

Le message ne part pas immédiatement. Le système attend une heure après la fermeture, et à partir de là un service d'arrière-plan envoie toutes les dix minutes les enquêtes arrivées à échéance. L'heure d'attente est voulue : un ticket rouvert aussitôt ne doit pas déclencher d'enquête.

Il y a exactement une enquête par ticket. Même si un ticket est rouvert puis refermé plus tard, le système ne demande pas une seconde fois.

Le lien ne demande aucun compte client et reste valable 30 jours. Jusque-là, ton client peut changer son évaluation ; un clic sur la mauvaise étoile est plus fréquent qu'un abus.

Un commentaire est facultatif. Cliquer sur une étoile est déjà une évaluation ; qui veut ajouter quelque chose trouve un champ pour cela sur la page et confirme avec « Update rating ».

La page ne montre que le numéro et le titre du ticket. La description, les commentaires et l'historique n'y figurent pas : le lien est un droit d'évaluer, pas un droit de lire. Il peut être transféré, ou atterrir dans une boîte aux lettres partagée.

Le clic depuis le message n'écrit l'évaluation qu'une fois la page chargée. C'est pourquoi les antivirus et les services d'aperçu n'évaluent pas tes tickets : ils appellent l'adresse, mais n'exécutent pas de JavaScript. Pour un être humain, cela reste un seul clic.

L'évaluation qui revient se trouve sur le ticket, où les agents et les administrateurs de l'équipe responsable peuvent la voir. Le client ne la voit jamais là, pas même la sienne.

Tous les tickets fermés ne sont pas interrogés. Sans adresse pour le demandeur, aucun message ne part du tout. Aucune enquête ne part non plus si le demandeur a fermé le ticket lui-même ou si son adresse figure sur la liste de blocage. Les signalements en double fusionnés ainsi que les signalements rattachés à un incident collectif restent également à l'écart. Résoudre un incident collectif ferme chaque signalement rattaché d'un seul clic, et sans cette exception chaque personne ayant signalé serait interrogée sur le même travail. Les personnes externes ne reçoivent en outre l'enquête qu'après avoir donné leur consentement. La carte « Qui reçoit l'enquête » explique qui compte comme externe.

Chaque e-mail d'enquête se termine par un lien de désabonnement. Après une évaluation, la page de l'enquête affiche aussi le lien « Stop receiving surveys ». La carte « Consentement et désabonnement » explique les deux.

Plus à ce sujet dans la carte : Qui reçoit l'enquête, Consentement et désabonnement

Le message d'enquête dans la boîte aux lettres du client, avec cinq liens d'évaluation numérotés et le lien vers la page d'enquête.
Voilà comment l'enquête arrive. Chacune des cinq lignes est un lien à part, en dessous se trouve le chemin vers la page avec le champ de commentaire. L'adresse des liens est celle que tu as enregistrée sous « Security ».Ouvrir l'image en taille réelle
La page d'enquête avec cinq étoiles, l'évaluation posée, le commentaire et le message de remerciement.
La page après le clic sur la cinquième étoile : l'évaluation est enregistrée, le champ de commentaire reste ouvert. Seuls le numéro et le titre du ticket sont affichés.Ouvrir l'image en taille réelle
L'évaluation sur le ticket avec cinq étoiles et le commentaire du client.
Le même résultat sur le ticket. Le cadre rouge entoure l'évaluation ; elle est là pour l'équipe, pas pour le client.Ouvrir l'image en taille réelle
2

L'activer et la limiter

Professional uniquement

L'enquête a exactement un endroit où on la configure : sous « Settings → General », dans la carte « Customer Satisfaction Score (CSAT) ». Cette carte explique les trois commandes d'envoi. Le champ « Own e-mail domains » de la même carte est expliqué dans la carte « Qui reçoit l'enquête ».

« Send satisfaction surveys » active l'envoi ; il est désactivé comme réglage d'usine. Seuls les tickets fermés après l'activation font l'objet d'une enquête, sinon tout ton stock recevrait un message d'un coup.

Si tu le désactives de nouveau, les évaluations déjà obtenues restent visibles. Simplement, plus rien de nouveau ne part.

Au-dessus des interrupteurs, tu vois l'adresse à partir de laquelle les liens sont construits. Elle est là pour être vérifiée, pas pour être modifiée : tu la changes au seul endroit où elle est entretenue, et l'indication à côté t'y emmène.

L'interrupteur du milieu, « Per-agent evaluation », appartient au rapport. Ce qu'il y fait, et pourquoi il est désactivé comme réglage d'usine, se trouve sur la carte consacrée au rapport. Il reste utilisable même quand l'enquête est désactivée.

« At most one survey per requester within » limite la fréquence à laquelle la même personne est interrogée. Le réglage d'usine est de 7 jours : une personne qui signale plusieurs tickets dans cette fenêtre n'est interrogée qu'une fois.

Avec 0, tu interroges sur chaque ticket fermé. Pour un helpdesk interne, c'est en général trop, parce que ce sont toujours les mêmes personnes qui signalent ; un service client avec beaucoup d'expéditeurs différents n'atteint presque jamais la limite.

L'enquête est volontairement simple. L'échelle est fixée de une à cinq étoiles, tout comme le délai d'une heure et la validité de 30 jours. Deux échelles différentes dans la même base de données feraient que le rapport moyennerait des choses non comparables.

Plus à ce sujet dans la carte : Le rapport sur les évaluations, Qui reçoit l'enquête

La carte « Customer Satisfaction Score (CSAT) » avec deux interrupteurs et le champ numérique de la limite.
Tout le réglage sur une seule carte. Les cadres rouges entourent les deux interrupteurs et le champ de la limite ; au-dessus figure l'adresse à partir de laquelle les liens sont construits.Ouvrir l'image en taille réelle
La carte « Public address of this installation » avec le champ d'adresse et la ligne « Currently in use ».
L'adresse elle-même s'entretient sous « Settings → Security ». La ligne en dessous t'indique quelle adresse est utilisée en ce moment et d'où elle vient.Ouvrir l'image en taille réelle
3

Qui reçoit l'enquête

Professional uniquement

Avant de commencer : Après la mise à jour vers 1.11.0, les personnes externes ne reçoivent l'enquête qu'après avoir donné leur consentement. Saisis donc les domaines e-mail de ton entreprise. Sinon, tes collaborateurs comptent eux aussi comme externes et ne reçoivent plus d'enquête.

L'enquête distingue deux groupes de destinataires. Les collaborateurs de ton entreprise la reçoivent sans qu'on leur demande d'abord. Toutes les autres personnes comptent comme externes. Les personnes externes ne reçoivent l'enquête qu'après avoir donné leur consentement.

Les collaborateurs peuvent se désabonner à tout moment. Les personnes externes peuvent retirer leur consentement à tout moment. La carte « Consentement et désabonnement » explique comment.

Tu décides qui compte comme collaborateur dans le champ « Own e-mail domains ». Il se trouve sous « Settings → General », dans la carte « Customer Satisfaction Score (CSAT) ». Seuls les administrateurs peuvent voir et modifier le champ. Saisis-y les domaines de ton entreprise, séparés par des virgules. Clique ensuite sur « Save domains ».

Une adresse compte comme celle d'un collaborateur si son domaine figure dans la liste. Une entrée couvre aussi ses sous-domaines. Ainsi « example.com » vaut aussi pour « it.example.com », mais pas pour « myexample.com ».

À l'enregistrement, le système met la liste en ordre. Les majuscules deviennent des minuscules, un « @ » au début est supprimé et les doublons disparaissent. Si une entrée n'est pas un domaine valide, le message « These entries are not valid domains: » apparaît avec cette entrée. Rien n'est enregistré dans ce cas.

Si le champ est vide, chaque adresse compte comme externe. C'est le réglage d'usine.

Pour un compte précis, tu peux remplacer la décision du domaine. Ouvre le compte sous « User management » avec « Edit ». Dans le champ « Satisfaction survey », tu choisis « Automatic by domain », « Employee » ou « External ». Le réglage d'usine est « Automatic by domain ». À côté, « Result: … » indique ce que la liste de domaines signifie pour ce compte.

Le choix sur le compte s'applique à l'adresse e-mail de ce compte. Il aide par exemple pour un collaborateur dont l'adresse a un autre domaine.

Après la mise à jour vers 1.11.0, le champ contient les domaines autorisés de tes fournisseurs d'authentification unique. Si tu n'utilises pas l'authentification unique, le champ est vide.

Tant que l'enquête est activée et que personne n'a enregistré le champ, la carte affiche un encadré : « Since version 1.11.0, external people receive the survey only after giving consent. Enter your company's e-mail domains so that your employees keep receiving the survey. » Seuls les administrateurs voient l'encadré.

Les administrateurs voient aussi la même phrase sous forme de bandeau en haut de chaque page. Tant que l'encadré est affiché, le bandeau apparaît dès qu'au moins une enquête n'a pas été envoyée au cours des 30 derniers jours. « Open the survey settings » mène à la carte. « Hide for 30 days » le masque pour ton compte pendant 30 jours.

Il y a une seule chose à faire : saisir les domaines et cliquer sur « Save domains ». Cela vaut aussi si la liste est déjà correcte ou doit rester vide. Ensuite, l'encadré et le bandeau disparaissent.

Sous le champ, une ligne compte les enquêtes qui n'ont pas été envoyées au cours des 30 derniers jours, par exemple « Surveys not sent in the last 30 days: 2 without consent, 1 after unsubscribing. » Chaque ticket compte une fois. Les autres raisons, comme la liste de blocage, ne sont pas comptées. Le lien « Show consents and unsubscribes » à côté ouvre la liste de la carte « Consentement et désabonnement ». Seuls les administrateurs voient la ligne et le lien.

La règle ne concerne que l'enquête de satisfaction. Tous les autres e-mails partent comme avant, par exemple les réponses des agents.

Plus à ce sujet dans la carte : Consentement et désabonnement

La carte « Customer Satisfaction Score (CSAT) » avec l'encadré sur la mise à jour, le champ « Own e-mail domains », « Save domains » et la ligne du décompte.
Les cadres rouges entourent le champ « Own e-mail domains » et « Save domains ». En haut figure l'encadré qui reste jusqu'au premier enregistrement du champ.Ouvrir l'image en taille réelle
La boîte de dialogue « Edit user » avec le champ « Satisfaction survey » et la ligne « Result: … » à côté.
Le cadre rouge entoure le champ « Satisfaction survey ». À côté, tu vois ce que la liste de domaines signifie pour ce compte.Ouvrir l'image en taille réelle
5

Le rapport sur les évaluations

Professional uniquement

Sous « Reports », la satisfaction a sa propre section, « Customer satisfaction (CSAT) ». Elle apparaît dans le même rapport que tout le reste, mais ne suit que deux des filtres : la période et l'équipe. Sans date, elle couvre les 30 derniers jours.

Cinq tuiles figurent en haut. « Average score » est la moyenne des étoiles, « Satisfaction rate (4-5 stars) » indique la part de personnes satisfaites, « Response rate » est le nombre de personnes ayant répondu, et « Surveys sent » compte les enquêtes envoyées. Sous les deux taux, tu trouves en petits caractères la fraction sur laquelle ils reposent.

« Closed without survey » est la cinquième tuile. Elle compte les tickets fermés qui n'ont jamais fait l'objet d'une enquête, avec en dessous le nombre total de tickets fermés. Sans ce nombre, tu prendrais un taux pour l'image de tes clients, et il reposerait sur un sous-ensemble que tu ne vois pas.

Le chiffre le plus important n'est pas la moyenne, c'est le taux de réponse. Une bonne note construite sur peu de réponses dit peu de chose de tes clients.

En dessous vient la répartition : pour chaque nombre d'étoiles, de cinq à une, une barre montre la fréquence, avec le nombre à côté. Vient ensuite « Trend », une ligne pour chaque jour où quelqu'un a répondu, avec la date, la moyenne du jour sous forme de barre et le nombre de réponses. Enfin viennent « By agent », avec une ligne par agent, et « Latest comments », avec ce que les gens ont réellement écrit. Une répartition « By team » s'y ajoute dès que plus d'une équipe a des tickets évalués.

Tu peux désactiver la répartition par agent. « Per-agent evaluation » est désactivé comme réglage d'usine, parce que les évaluations par personne sont des données de performance. Dans beaucoup d'entreprises, le comité social et économique a son mot à dire, et chez les fournisseurs cloud cette analyse ne peut souvent pas être désactivée du tout.

L'interrupteur agit sur le serveur et pas seulement à l'écran : une fois désactivé, le serveur ne livre pas du tout la répartition.

L'évaluation isolée sur un ticket n'est pas concernée et reste visible pour l'équipe. L'interrupteur règle l'analyse entre personnes, pas ce qui est montré sur un dossier. La section CSAT n'a pas d'export propre. Ici, les agents ne voient que les équipes dont les « Agent Permissions » autorisent à voir les rapports.

Le filtre « Satisfaction » réduit le rapport aux évaluations. « Rated only » montre les tickets évalués, « Not rated » ceux qui ne le sont pas, et avec « Score from » et « Score to » tu peux regarder tous les tickets à une ou deux étoiles. Le filtre s'applique au tableau et aux deux exports.

La section « Customer satisfaction (CSAT) » du rapport avec cinq chiffres clés et la répartition des étoiles.
Les cinq tuiles de la section. Le cadre rouge entoure « Closed without survey », le nombre qui met le taux de réponse en perspective.Ouvrir l'image en taille réelle
La section « Trend » avec une ligne par jour, la moyenne sous forme de barre et le nombre de réponses.
L'évolution dans le temps. Pour chaque jour, tu vois la date, la moyenne sous forme de barre avec le chiffre à côté, et à droite le nombre de réponses arrivées ce jour-là. Dans l'exemple, les deux réponses sont arrivées le même jour, il n'y a donc qu'une ligne.Ouvrir l'image en taille réelle
La répartition « By agent » avec une ligne par agent, et les derniers commentaires.
La répartition par agent, avec les commentaires tels qu'ils ont été écrits. C'est cette partie du rapport que tu peux désactiver.Ouvrir l'image en taille réelle
6

Une mauvaise évaluation comme déclencheur

Professional uniquement

Une évaluation peut déclencher une règle. Dans l'éditeur de règles sous « Settings → Automation », il y a une condition pour cela, « Satisfaction rating (CSAT) », et à côté tu choisis « is at most », « is at least », « is » ou « is not ». Le troisième champ contient les étoiles, de une à cinq, avec le nombre à côté.

Le cas habituel est « is at most 2 ». Au-dessus de la règle, tu lis alors la phrase que l'éditeur écrit au fil de l'eau : « When a ticket was rated 2 stars or fewer, then send an e-mail to the assignee. »

Cette règle n'a besoin d'aucune condition de temps. Une nouvelle règle arrive avec la condition « Time without any activity » « longer than » 3 « days » dans le bloc « WHEN » ; retire-la pour que le bloc soit vide. C'est ce qui en fait l'exception parmi les règles : toutes les autres attendent que rien ne se soit passé pendant un moment, celle-ci attend un événement.

Comme action, tu disposes de tout ce qu'une règle peut faire de toute façon : envoyer un message, augmenter la priorité, transmettre le ticket à une autre équipe, ou poser un suivi.

Une chose fonctionne différemment ici. Les règles laissent normalement les tickets fermés tranquilles, mais une évaluation arrive presque toujours sur un ticket fermé. Une règle avec cette condition atteint donc aussi les tickets fermés. Toutes les autres règles, non.

La condition ne s'applique jamais à un ticket sans évaluation, y compris avec « is not ». Sinon, « pas cinq étoiles » toucherait tout ton stock non évalué. Si tu veux savoir combien n'ont pas répondu, c'est le taux de réponse dans le rapport.

La règle agit une fois par évaluation. En dessous, « Log » ouvre le tableau « What this rule did » avec une ligne par ticket, tu peux donc voir quand elle a tourné et ce qu'elle a fait.

L'éditeur de règles avec la condition « Satisfaction rating (CSAT) is at most 2 » et la phrase au-dessus.
La condition dans l'éditeur. Les cadres rouges entourent la condition et la phrase au-dessus, et cette phrase se réécrit à chaque changement.Ouvrir l'image en taille réelle
Le tableau « What this rule did » avec une ligne pour le ticket mal évalué.
Le journal de la règle. La ligne montre le ticket, l'heure et l'action exécutée.Ouvrir l'image en taille réelle

Base de connaissances

La partie qui évite des tickets : des solutions écrites une fois, retrouvées par ton équipe, et proposées au demandeur pendant qu'il tape encore. Tout ce qui est dans ce bloc fait partie de Basic, sauf l'e-mail sur les entrées en attente d'approbation.

1

Tuiles de thèmes avec articles et pièces jointes

Tu accèdes à la base de connaissances par « Knowledge Base » dans la barre de gauche. La vue d'ensemble se compose de tuiles, une par thème. Le nombre en haut à droite d'une tuile est le compte des entrées publiées ; en dessous figurent le nom et la description du thème. Un clic sur la tuile mène à la liste des entrées, chacune avec son auteur, sa date de modification et les premières lignes de son texte.

Tu ne crées pas les thèmes ici mais sous « Settings → Knowledge Base » (voir la carte « Visibilité par thème »). Sans un seul thème, la vue d'ensemble ne montre qu'une remarque : une entrée a toujours besoin d'un thème.

Tu écris avec « New entry » sur la page d'un thème. L'éditeur demande trois choses : « Title », « Topic » et « Content ». C'est le même éditeur que dans un ticket, avec la même barre d'outils : « Bold », « Italic », « Underline », « Strikethrough », « Text color », « Highlight color », « Bullet list », « Numbered list », « Quote », « Link » et « Clear formatting ». Un lien se fait comme dans un ticket : sélectionne le texte, clique sur « Link », saisis l'adresse. Les adresses web et de messagerie sont autorisées (http, https, mailto). « Save » reste gris tant que le titre ou le thème manquent, et une entrée sans texte est refusée : des pièces jointes seules ne font pas une entrée.

Les images entrent dans le texte par le presse-papiers, comme dans un ticket : fais une capture d'écran, colle-la dans l'éditeur avec Ctrl+V. Un marqueur comme « [inline-image:1] » apparaît dans le texte ; à l'enregistrement, le système envoie l'image et l'affiche exactement à cet endroit. Elle apparaît en plus en dessous sous « Attachments », c'est là que tu la supprimes de nouveau. On peut coller du PNG, du JPEG et du GIF.

Tu joins des fichiers seulement une fois l'entrée enregistrée : en bas de la page de l'entrée se trouve la carte « Attachments » avec « Upload file ». Les types de fichiers autorisés et la taille sont les mêmes que pour un ticket (jusqu'à 50 Mo par fichier). Celui qui a envoyé un fichier peut le retirer ; les administrateurs peuvent retirer n'importe lequel.

Les administrateurs peuvent toujours écrire, les agents tant que l'interrupteur des paramètres l'autorise (voir la carte « Approbation »). Les clients ne font que lire. Un administrateur peut supprimer n'importe quelle entrée ; un agent ne peut supprimer que ses propres entrées qui n'ont jamais été publiées.

La page de vue d'ensemble de la base de connaissances avec trois tuiles de thèmes et l'entrée de menu « Knowledge Base » encadrée en rouge.
L'accès : « Knowledge Base » dans la barre de gauche. Chaque tuile est un thème ; le nombre nomme les entrées publiées, la pastille orange celles qui attendent.Ouvrir l'image en taille réelle
L'éditeur « New entry » avec les champs Title et Topic, la barre d'outils de l'éditeur et le bouton « Save » grisé.
Titre, thème, contenu. Tant qu'aucun thème n'est choisi, « Save » reste gris ; dans le cadre rouge, le choix qui manque encore ici.Ouvrir l'image en taille réelle
Une entrée de la base de connaissances avec du texte mis en forme, une image collée de l'écran de l'imprimante, une liste numérotée et la carte « Attachments » contenant deux fichiers.
Une entrée terminée : l'en-tête avec le thème, l'auteur et l'approbation, en dessous le texte avec une image collée. En bas figurent les deux fichiers, le guide rapide à télécharger et l'image collée.Ouvrir l'image en taille réelle
3

Visibilité par thème : interne seulement ou ouvert aux clients

Avant de commencer : La visibilité est accrochée au THÈME, pas à l'entrée isolée. Une note interne dans un thème ouvert aux clients est lisible par les clients dès sa publication. Prévois tes thèmes en conséquence, et déplace une entrée vers un autre thème par « Edit » s'il le faut.

Tu entretiens les thèmes sous « Settings → Knowledge Base » dans la carte « Topics ». Chaque ligne porte un nom, une description, un numéro de tri pour l'ordre des tuiles, l'interrupteur « Visible to customers » et deux boutons pour enregistrer et supprimer ; tu enregistres par ligne, pas toute la carte.

Avec l'interrupteur désactivé, seuls les agents et les administrateurs voient le thème, ses entrées et leurs pièces jointes ; un client n'obtient même pas la tuile et ne trouve pas non plus les entrées par la recherche. Une fois activé, les clients voient le thème et les entrées publiées qu'il contient ; les brouillons restent invisibles de toute façon.

Tu crées un nouveau thème dans la ligne en pointillés en dessous : saisis un nom, choisis la visibilité, « Add topic ». Un thème ne peut être supprimé que tant qu'il est vide ; sinon, tu supprimerais ses entrées avec lui, sans les voir.

La carte « Topics » avec trois thèmes ; l'interrupteur « Visible to customers » est activé pour le premier thème et désactivé pour « Internal runbooks ».
La différence est dans les deux cadres rouges : « Printing » est ouvert aux clients, « Internal runbooks » ne l'est pas. Tu enregistres par ligne avec le bouton bleu à droite.Ouvrir l'image en taille réelle
4

Des solutions proposées pendant la création d'un ticket

Dès que trois caractères figurent dans le champ « Title » du formulaire « Create new ticket », le système cherche en arrière-plan et affiche l'encadré « Possible solutions from the knowledge base », avec jusqu'à cinq entrées correspondant au titre. Qui y trouve sa réponse ne crée pas de ticket ; c'est tout l'intérêt.

Seul le TITRE est parcouru, pas la description. La même règle que dans la recherche s'applique : une proposition doit contenir au moins la moitié des mots du titre. Plus le titre est précis, moins il y a de propositions et mieux elles conviennent. Un clic sur une proposition l'ouvre dans un nouvel onglet, pour que le formulaire à moitié rempli ne soit pas perdu ; « Open knowledge base » en bas mène à la vue d'ensemble complète.

La visibilité s'applique ici aussi : un client ne se voit proposer que les entrées publiées des thèmes ouverts aux clients. En tant qu'agent, tu vois en plus les thèmes internes et les entrées qui attendent encore leur approbation.

Le champ « Title » du formulaire de nouveau ticket avec l'encadré « Possible solutions from the knowledge base » et les propositions en dessous.
Seul le titre a été tapé, l'encadré en dessous apparaît tout seul. En haut figurent les entrées qui correspondent le mieux au titre.Ouvrir l'image en taille réelle
5

Transformer un ticket résolu en entrée

Avant de commencer : TOUT est repris : la description et chaque commentaire, y compris les commentaires internes. Le texte est une copie, pas un lien. Relis-le et retire les noms, les numéros de téléphone, les adresses e-mail et les numéros de commande avant d'enregistrer. Ensuite, toute personne qui peut voir le thème pourra le lire.

En haut à droite de chaque ticket se trouve « Add to knowledge base ». Le bouton ouvre l'éditeur pour une nouvelle entrée, prérempli avec le titre du ticket et tout son déroulé : la description comme premier paragraphe, chaque commentaire en dessous sous forme de citation.

Cela seul ne t'apporte rien, c'est de la matière brute. L'enjeu est d'en faire un guide : réduis-le à ce qui aidera la prochaine fois, et réécris le titre s'il sonne comme un cas isolé (« Printer on 2nd floor pulls two sheets » devient « Résoudre un bourrage papier »).

Aucun thème n'est présélectionné, c'est toi qui choisis. L'entrée s'enregistre comme n'importe quelle autre : publiée aussitôt en tant qu'administrateur, envoyée en approbation en tant qu'agent. Ensuite, la référence interne « Source: Ticket #1 » reste sur l'entrée ; c'est un retour vers le dossier et elle n'est pas visible par les clients.

Un ticket avec le bouton « Add to knowledge base » encadré en rouge en haut à droite.
Le bouton se trouve en haut à droite de chaque ticket, quel que soit le statut du ticket à cet instant. Il est fait pour le dossier qui a été résolu.Ouvrir l'image en taille réelle
L'éditeur « New entry » prérempli avec le titre et le déroulé du ticket, au-dessus la remarque encadrée en rouge sur le ticket d'origine.
La remarque dans le cadre rouge dit l'essentiel. Dans le texte en dessous figure la note interne avec le numéro de commande, exactement ce qui doit partir avant l'enregistrement.Ouvrir l'image en taille réelle
6

Approbation : les entrées d'un agent attendent l'administrateur

Le fait que les agents puissent écrire est décidé par l'interrupteur « Agents can create entries » sous « Settings → Knowledge Base ». Il est activé par défaut. Désactivé, c'est une frontière dure : le bouton « New entry » et le bouton « Add to knowledge base » du ticket disparaissent, et l'appel direct de l'éditeur est refusé également.

Il y a exactement deux états, « Awaiting review » et « Published » ; il n'y a pas de brouillon sur lequel travailler tranquillement sans que personne le voie. C'est l'auteur qui détermine l'état : un administrateur publie immédiatement. Un agent produit une entrée marquée « Awaiting review », visible par les agents et les administrateurs, pas par les clients. Sur la tuile du thème apparaît alors la pastille orange « 1 awaiting review ».

Les administrateurs reçoivent en plus un e-mail dès qu'une entrée est soumise à approbation. Ce message fait partie de Professional. C'est un complément, pas une condition : sans envoi de courrier configuré, la pastille reste le moyen de repérer une approbation en attente. Tu approuves sur la page de l'entrée avec « Approve & publish » ; ensuite, il y est indiqué qui a approuvé.

Si un agent modifie plus tard une entrée publiée, elle repart en approbation. Le changement n'est de nouveau visible par les clients qu'après le prochain « Approve & publish ». Une personne déjà en attente qui enregistre encore une fois ne déclenche pas un second message. Il en va de même quand un agent ajoute ou retire une pièce jointe.

La page des paramètres de la base de connaissances avec l'interrupteur « Agents can create entries » encadré en rouge.
L'interrupteur se trouve tout en haut de « Settings → Knowledge Base ». La phrase à côté dit ce qui en dépend : les entrées des agents attendent l'approbation.Ouvrir l'image en taille réelle
Une entrée marquée « Awaiting review » avec le bouton « Approve & publish » encadré en rouge.
L'entrée vient de l'agent Marco Rossi et attend. Un clic sur « Approve & publish » la rend visible à toute personne qui peut voir le thème.Ouvrir l'image en taille réelle
7

Historique des modifications de la base de connaissances

Sous « Settings → Knowledge Base », la carte « History » se trouve tout en bas. Elle liste les 200 derniers événements, les plus récents d'abord : ce qui s'est passé, quelle entrée ou quel thème était concerné, qui l'a fait et quand.

Sept événements sont consignés : entrée créée, modifiée, approuvée et supprimée, plus thème créé, modifié et supprimé. Une entrée supprimée ne disparaît donc pas sans laisser de trace : la ligne reste, même quand l'entrée n'est plus là.

Deux lignes d'un coup ne sont pas une erreur : quand un administrateur crée une entrée, « Entry created » y figure et, juste au-dessus, « Entry approved ». Il publie sans passer par l'approbation. Pour un agent, seul « Entry created » apparaît d'abord ; l'approbation vient plus tard et avec le nom de l'administrateur.

Seule une personne autorisée à ouvrir la page des paramètres de la base de connaissances voit l'historique, les administrateurs par défaut. C'est un historique pour toute la base de connaissances, pas un par entrée.

La carte « History » avec des lignes comme « Entry created », « Entry approved » et « Topic created », chacune avec un nom et une heure.
Tout en haut, l'entrée de l'agent qui attend encore son approbation ; elle n'a pas encore de ligne « Entry approved ». En dessous, les entrées de l'administrateur, chacune avec les deux lignes.Ouvrir l'image en taille réelle

Sauvegarde et restauration

Les sauvegardes ont leur propre application. Elle est livrée avec le système et l'installation la met en place, il n'y a donc rien à acheter et rien à configurer. Ce bloc montre ce qu'elle sauvegarde, quand elle tourne et comment tout récupérer le jour où cela compte. Tout ce bloc fait partie de Basic.

1

L'application de sauvegarde et de restauration

L'application s'appelle « Ticket System Backup & Restore ». Elle se trouve à côté du système de tickets et a son propre raccourci sur le bureau.

Il y a une version pour Windows et une pour Linux. C'est la même application, simplement construite pour chaque système d'exploitation.

Elle a six onglets. « Restore » liste les sauvegardes dont tu disposes, « Create Backup » en fait une nouvelle, « Schedule » gère l'horaire, « Encryption » montre la clé de récupération, « Settings » montre les chemins et « Log » le journal.

Les paramètres sont déjà remplis. À son premier démarrage, l'application détermine elle-même où se trouve le système de tickets.

Le dossier des sauvegardes se trouve sous « Backup directory ». Tu peux le changer, par exemple pour un autre disque.

Sous Windows, l'application demande des droits d'administrateur au démarrage. Ses réglages valent pour tous les administrateurs de l'ordinateur et se trouvent dans « %ProgramData%\SMITEY\backup-app ».

L'onglet « Restore » avec cinq sauvegardes, chacune avec son heure, sa taille, son type et son chiffrement.
Le cadre rouge entoure la colonne « Encryption ». Les nouvelles sauvegardes se terminent par « .smbk » et sont « Encrypted ». Les anciennes sauvegardes au format ZIP affichent « Not encrypted ». La colonne « Type » dit si une sauvegarde vient de l'horaire, a été faite à la main ou a été prise avant une mise à jour.Ouvrir l'image en taille réelle
L'onglet « Settings » avec le dossier des sauvegardes et les informations sur la base de données.
Le cadre rouge entoure le nom du conteneur PostgreSQL. Plus bas se trouvent les volumes sauvegardés en même temps.Ouvrir l'image en taille réelle
2

L'horaire tourne dès l'installation

Avant de commencer : Sous Windows, l'application démarre toujours avec des droits d'administrateur et enregistre l'horaire avec ces droits. Si Windows ne laisse pas la tâche tourner sans utilisateur connecté, elle reste liée à une connexion, et l'application te le dit.

L'installation met en place la sauvegarde quotidienne toute seule. Elle tourne à 23 h dans le fuseau horaire du système de tickets.

L'horaire vit dans le système d'exploitation. Sous Windows, c'est le planificateur de tâches, sous Linux le service cron. Aucun service supplémentaire ne tourne donc juste pour les sauvegardes.

La sauvegarde n'a besoin de personne de connecté. Sur un serveur où personne ne se connecte jamais, elle tourne quand même.

La ligne sous les boutons te dit si la tâche existe vraiment dans le système d'exploitation. Une case cochée ne dit que ce qui a été enregistré.

Les sauvegardes sont conservées sur cinq niveaux : 14 jours, 4 semaines, 12 mois, 4 trimestres et 5 années. Une sauvegarde reste tant qu'elle est la plus récente de sa période dans l'un de ces niveaux.

Ce qui compte, ce sont les jours du calendrier, pas les fichiers. Deux sauvegardes le même jour font un jour.

Les sauvegardes que tu crées à la main ne sont jamais supprimées automatiquement. C'est ce que veut dire le 0 à « Keep manual ».

Si tu changes l'horaire, ton changement survit à une mise à jour. L'installation ne le pose que si tu n'as jamais posé d'horaire. Si tu as désactivé la sauvegarde, elle reste désactivée. « Remove all scheduled tasks » tient aussi : une mise à jour ne remet pas l'horaire en place ensuite.

L'onglet « Schedule » avec « Daily » coché et l'heure réglée sur 23:00.
Les cadres rouges entourent « Daily » et l'heure. La phrase au-dessus nomme les deux voies : le planificateur de tâches et cron.Ouvrir l'image en taille réelle
La ligne « Registered with the operating system: yes (Daily) » sous les boutons.
Cette ligne est vérifiée de nouveau à chaque démarrage. Si elle indique « NO », rien ne tourne tout seul ; utilise alors « Apply schedule » en tant qu'administrateur.Ouvrir l'image en taille réelle
Les six champs de conservation : 14, 4, 12, 4, 5 et 0.
Le cadre rouge entoure les niveaux. « Keep manual (0 = keep all) » signifie que les sauvegardes faites à la main sont conservées.Ouvrir l'image en taille réelle
L'onglet « Schedule » après « Apply schedule », avec « 02:00 (America/New_York) » et « Registered with the operating system: yes (Daily) » en dessous.
Les cadres rouges sont posés sur « Apply schedule » et sur les lignes en dessous. Entre parenthèses figure le fuseau horaire du système de tickets. L'heure vaut dans ce fuseau et non dans le fuseau horaire de l'ordinateur.Ouvrir l'image en taille réelle
3

Ce que contient une sauvegarde

Une sauvegarde contient tout ce qui compose l'état de ton système. C'est-à-dire la base de données, les pièces jointes, l'archive et les clés. Seule une base de données en dehors de SMITEY n'en fait pas partie.

Les clés sont la partie qu'on oublie facilement. Elles déchiffrent les identifiants enregistrés, par exemple ceux de ton compte de messagerie. Sans elles, une restauration reviendrait avec des identifiants morts.

Chaque nouvelle sauvegarde est un seul fichier chiffré se terminant par « .smbk ». Il contient un fichier par volume, une liste de son contenu et la base de données sous forme de fichier texte, si elle est incluse.

Le système continue de tourner pendant ce temps. Tes agents ne remarquent pas du tout une sauvegarde.

« Estimate size » t'indique à l'avance la taille de la base de données. Les volumes avec les pièces jointes s'y ajoutent. La sauvegarde n'est pas compressée.

Rien n'est jamais écrasé. Chaque sauvegarde est un fichier à part, et seul le nettoyage supprime les anciennes.

Seuls les administrateurs peuvent lire les sauvegardes. Il en va de même pour le fichier de configuration et pour le fichier avec la première connexion dans le dossier d'installation. Le programme d'installation et chaque mise à jour définissent eux-mêmes ces droits.

Si ta base de données tourne sur son propre serveur et non dans le conteneur SMITEY, l'application ne peut pas la sauvegarder. Sauvegarde-la alors avec tes propres outils. Dans ce cas, la sauvegarde ne contient que les pièces jointes, les archives et les clés, chiffrées comme d'habitude. Une mise à jour détecte elle-même une telle base de données et change le réglage de l'application. Jusque-là, la sauvegarde quotidienne échoue sur une telle installation, sauf si tu changes d'abord le réglage à la main. Sur la ligne de commande, tu peux aussi le faire à la main avec « config --database external ». Avec « config --database bundled », tu reviens au réglage précédent.

Plus à ce sujet dans la carte : Chiffrement et clé de récupération

L'onglet « Create Backup » avec les boutons « Estimate size » et « Create backup now ».
Le cadre rouge entoure les deux boutons. La phrase au-dessus énumère ce qui est inclus.Ouvrir l'image en taille réelle
Le message en bas avec le chemin complet du fichier créé.
Une fois faite, le nom du fichier apparaît en bas de la fenêtre. L'heure fait partie du nom.Ouvrir l'image en taille réelle
4

Chiffrement et clé de récupération

Avant de commencer : Conserve la clé de récupération en dehors du serveur. Sans elle, aucune sauvegarde ne peut être ouverte une fois le serveur perdu. Personne ne peut la récupérer pour toi.

Chaque nouvelle sauvegarde est chiffrée. Cela vaut pour les sauvegardes de l'horaire, celles faites à la main et celles avant une mise à jour. Tu n'as rien à activer.

Les sauvegardes sont chiffrées avec AES-256. L'installation crée la clé elle-même. Sur une installation existante, elle est créée lors de la première mise à jour vers une version avec chiffrement. Elle est stockée protégée sur le serveur. Seuls les administrateurs peuvent la lire.

Cela protège les copies en dehors du serveur. Celui qui trouve une sauvegarde sur un lecteur réseau, une clé USB ou un stockage en ligne ne peut pas la lire sans la clé. Celui qui contrôle le serveur lui-même a aussi la clé.

La clé de récupération est la même clé sous une forme que tu peux noter. Elle commence par « SMBK- ». Tu la trouves dans l'onglet « Encryption » et dans le fichier « SMITEY-credentials.txt » du dossier d'installation. Si tu as supprimé ce fichier, tu trouves quand même la clé dans l'onglet « Encryption ».

« Copy » place la clé dans le presse-papiers. « Save to file... » l'enregistre avec l'ID de clé et la date dans un fichier texte. Conserve-le par exemple dans un gestionnaire de mots de passe ou sur papier dans un coffre.

Tant que tu n'as pas confirmé que la clé est conservée, l'application affiche une barre jaune en haut. Pour confirmer, clique sur « I stored the key outside this server » et réponds à la question par « Yes ». La barre disparaît alors. L'onglet indique ensuite quand tu as confirmé.

L'ID de clé t'indique à quel serveur appartient une sauvegarde. Si une sauvegarde n'appartient pas à ce serveur, l'application nomme son ID de clé. Elle demande ensuite la clé de récupération correspondante.

Si l'application ne peut pas lire la clé, elle ne fait pas de sauvegarde. Elle n'en fait pas non plus de non chiffrée. Dans ce cas, l'onglet « Encryption » indique que la clé ne peut pas être lue. Si le fichier de clé manque complètement, la sauvegarde suivante crée une nouvelle clé. La barre jaune réapparaît alors, car la nouvelle clé doit aussi être conservée. Les anciennes sauvegardes ne peuvent toujours être ouvertes qu'avec l'ancienne clé de récupération.

Les anciennes sauvegardes au format ZIP ne sont pas chiffrées. Tu peux encore les restaurer. L'onglet indique combien il y en a. Le nettoyage les supprime selon les mêmes règles que n'importe quelle autre sauvegarde.

Sur un serveur sans bureau, « key --show » affiche la même chose sur la ligne de commande.

Plus à ce sujet dans la carte : Récupérer tout, Sur un serveur sans bureau

L'onglet « Encryption » avec la clé de récupération, l'ID de clé et trois boutons. La barre d'avertissement jaune est en haut.
Les cadres rouges entourent la barre d'avertissement, la clé et l'ID de clé, ainsi que « I stored the key outside this server ». La clé sur l'image provient d'un environnement de test.Ouvrir l'image en taille réelle
Le même onglet après la confirmation, sans la barre d'avertissement.
Le cadre du haut entoure l'heure de la confirmation. Celui du bas indique combien de sauvegardes ne sont pas encore chiffrées.Ouvrir l'image en taille réelle
5

Tout récupérer

Avant de commencer : Une restauration écrase l'état du jour. Tout ce qui a été créé depuis la sauvegarde choisie a disparu ensuite.

Dans l'onglet « Restore », tu choisis la sauvegarde que tu veux récupérer. Puis tu cliques sur « Restore ».

L'application demande d'abord. Elle dit ce qui va se passer : l'état du jour est écrasé, et l'application redémarre les conteneurs. Si des personnes sont anonymisées dans l'état du jour, une deuxième question suit. Elle indique leur nombre et demande s'il faut les anonymiser à nouveau après la restauration. « Yes » est présélectionné. Avec « No », la sauvegarde est restaurée sans cette étape. Si tu fermes la fenêtre à la place, rien n'est restauré.

La case « Wipe target volumes before restore » vide d'abord les volumes. Ainsi, aucun fichier ne subsiste qui n'existait pas au moment de la sauvegarde.

Les étapes apparaissent dans l'onglet « Log ». Tu y vois une par une ce que l'application a fait. Si tu as répondu « Yes » à la deuxième question, une ligne à la fin indique combien d'anonymisations le système de tickets applique de nouveau la nuit suivante. Si elles ne peuvent pas être reprises, le journal affiche à la place un avertissement. S'il y a eu des avertissements, la ligne d'état en bas de la fenêtre indique leur nombre.

Si la sauvegarde contient la base de données, l'état complet revient. Les tickets, les commentaires, l'historique, les pièces jointes, le temps saisi et la base de connaissances sont tous de nouveau là tels qu'ils étaient au moment de la sauvegarde.

Ensuite, le système est de nouveau utilisable. Sur une petite installation, cela prend moins d'une minute.

Si la sauvegarde contient la base de données, celle-ci revient entièrement ou pas du tout. Les volumes suivent ensuite. Si un volume échoue, la base de données est déjà revenue, mais des fichiers peuvent manquer ; l'onglet « Log » montre quelle étape a échoué. Dans tous les cas, l'application redémarre ensuite les conteneurs, même si la restauration a échoué.

Une sauvegarde d'une version plus ancienne peut être restaurée dans une version plus récente. À son prochain démarrage, le système met la base de données au niveau de sa propre version.

Les consentements et désabonnements pour l'enquête de satisfaction sont repris sans question. Cela vaut aussi si tu réponds « No » à la deuxième question. L'application les lit dans l'installation en cours avant la restauration. Ensuite, une ligne dans l'onglet « Log » indique le nombre, par exemple « 12 consent and unsubscribe record(s) were carried over. » Le système de tickets les reprend à son premier démarrage. Un consentement ou un désabonnement fait après la sauvegarde reste donc valable. Si le transfert échoue, le journal affiche un avertissement. La restauration compte quand même comme réussie.

L'application vérifie d'abord entièrement une sauvegarde chiffrée. Pendant ce temps, la ligne d'état indique « Checking the encrypted backup before anything is changed... ». Ce n'est qu'ensuite qu'elle arrête les conteneurs. Si le fichier est endommagé ou a été modifié, elle s'arrête et signale « The backup file is damaged. Nothing was changed. »

Si la sauvegarde vient d'un autre serveur, l'application demande la clé de récupération de ce serveur. Cela se passe après les questions. La fenêtre « Recovery key needed » nomme l'ID de clé de la sauvegarde. La même fenêtre apparaît si la clé de ce serveur manque.

Une faute de frappe est repérée avant que quoi que ce soit ne change. La ligne d'état signale alors « The recovery key has a typing error. Check each character. » Ensuite, la fenêtre redemande. Si la clé appartient à une autre sauvegarde, la ligne d'état signale « This recovery key does not belong to this backup. » Avec « Cancel », l'application s'arrête et signale « Restore cancelled. Nothing was changed. »

L'application n'adopte pas la clé que tu as saisie. Elle garde la sienne. Les nouvelles sauvegardes sont toujours faites avec la clé de ce serveur. Si tu restaures sur un nouveau serveur, conserve aussi la clé de récupération de ce serveur.

Une sauvegarde sans base de données ne restaure que les pièces jointes, les archives et les clés. Les clés existantes sont conservées. La base de données reste telle quelle. L'application le dit avant la restauration et demande. Avec « No », rien n'est modifié.

Si l'installation est configurée avec sa propre base de données, l'application ignore la partie base de données même quand la sauvegarde contient une base de données. C'est le cas par exemple d'une sauvegarde plus ancienne. L'application demande d'abord. Avec « No », rien n'est modifié.

Une sauvegarde sélectionnée dans la liste, avec la case et le bouton « Restore » en dessous.
Les cadres rouges entourent la case et « Restore ». Sans ligne sélectionnée, le bouton reste inactif.Ouvrir l'image en taille réelle
La confirmation avant la restauration avec les boutons « Yes » et « No ».
La question nomme les deux conséquences : l'état du jour est écrasé, et les conteneurs sont redémarrés.Ouvrir l'image en taille réelle
Le journal après la restauration, avec le message « Restore complete. » en bas.
Chaque étape y figure avec son heure. À la fin, l'application signale « Restore complete. »Ouvrir l'image en taille réelle
La deuxième question « 6 person(s) were anonymized in the current system. » avec les boutons « Yes » et « No ».
Les cadres rouges sont posés sur la question et sur « Yes ». « Yes » est présélectionné. Le nombre compte les personnes anonymisées dans l'état du jour.Ouvrir l'image en taille réelle
La ligne d'état après la restauration : « 1 warning(s) while carrying over anonymizations and survey consents. See the Log tab. »
Le cadre rouge est posé sur la ligne d'état. Elle n'indique que le nombre d'avertissements. Ce qui s'est passé exactement figure dans l'onglet « Log ».Ouvrir l'image en taille réelle
La demande de la clé de récupération avec l'ID de clé de la sauvegarde, un champ de saisie et les boutons « OK » et « Cancel ».
Les cadres rouges entourent la question avec l'ID de clé et le champ de saisie. Les tirets, les espaces et les majuscules ou minuscules n'ont pas d'importance quand tu saisis la clé. La clé sur l'image provient d'un environnement de test.Ouvrir l'image en taille réelle
6

Sur un serveur sans bureau

Un serveur n'a souvent pas de bureau. La même application fonctionne donc aussi comme commande.

Cinq commandes suffisent au quotidien : « backup » sauvegarde, « list » montre les sauvegardes dont tu disposes, « restore » en ramène une, « schedule » règle l'horaire et « config » montre les paramètres. Pour la clé, « key » et « decrypt » s'y ajoutent.

Derrière elles se trouve la même application que dans la fenêtre. Il n'y a pas de seconde voie qui ferait autre chose.

L'application se trouve dans « /opt/smitey/Backup ». Tu l'appelles avec « sudo » et tu ajoutes la commande. Les conteneurs tournent en « root », la sauvegarde a donc besoin de ces droits aussi.

Tu peux copier les six encadrés ci-dessous. Ils couvrent ce qui sert vraiment au quotidien.

Une restauration demande confirmation ici aussi. Elle ne s'exécute que si tu ajoutes « --yes ». Elle reprend alors aussi les anonymisations de l'état du jour, comme « Yes » dans la fenêtre. Avec « --no-reapply », elle s'exécute sans cette étape.

Il y a un fichier sur le serveur pour approfondir tout cela. Il s'appelle « BACKUP-RESTORE.txt » et se trouve dans « /opt/smitey ». Il reprend l'horaire, chaque commande et le chemin du retour, à ton rythme. Il existe en allemand et en anglais : si tu as choisi l'allemand pendant l'installation, tu reçois la version allemande, sinon la version anglaise. Les deux versions se trouvent aussi sous « /opt/smitey/docs ».

« key --show » affiche la clé de récupération, l'ID de clé et le nombre de sauvegardes non chiffrées. Une fois la clé conservée en dehors du serveur, tu le confirmes avec « key --confirm-stored ».

Tu restaures une sauvegarde d'un autre serveur avec « --key-file ». Le fichier que tu indiques contient la clé de récupération. Le fichier de « Save to file... » convient aussi. À la place du fichier, tu peux aussi utiliser la variable d'environnement « SMITEY_BACKUP_KEY ». Avec « sudo », tu la places directement devant le programme, c'est-à-dire « sudo SMITEY_BACKUP_KEY=<clé> /opt/smitey/Backup/TicketSystemBackup restore … ». La clé se retrouve alors dans l'historique du shell. Si la clé ne correspond pas, rien n'est modifié.

« decrypt » écrit le contenu d'une sauvegarde sous forme de fichiers non chiffrés dans un dossier vide. Ces fichiers ne sont pas chiffrés. Ils contiennent des mots de passe et des données personnelles. Supprime-les dès que tu as terminé.

Montrer les sauvegardes dont tu disposes

sudo /opt/smitey/Backup/TicketSystemBackup list

Chaque ligne porte l'heure, le motif, la taille et le nom du fichier. C'est la même liste que dans la fenêtre.

Montrer l'horaire

sudo /opt/smitey/Backup/TicketSystemBackup schedule --show

La première ligne nomme l'heure réglée avec son fuseau horaire. La dernière dit si la tâche existe vraiment dans le système d'exploitation. Si elle indique « NO », rien ne tourne tout seul.

Changer l'horaire

sudo /opt/smitey/Backup/TicketSystemBackup schedule --daily 23:00 --keep 14

L'heure s'applique dans le fuseau horaire du système de tickets. « --keep » dit combien de sauvegardes quotidiennes sont conservées. « schedule --off » désactive la sauvegarde quotidienne.

Créer une sauvegarde tout de suite

sudo /opt/smitey/Backup/TicketSystemBackup backup

Cette sauvegarde compte comme « Manual ». Les sauvegardes faites à la main ne sont jamais supprimées automatiquement.

Afficher la clé de récupération

sudo /opt/smitey/Backup/TicketSystemBackup key --show

La dernière ligne indique si tu as déjà confirmé que la clé est conservée. La commande ne crée pas de clé.

Restaurer une sauvegarde d'un autre serveur

sudo /opt/smitey/Backup/TicketSystemBackup restore <file>.smbk --yes --key-file /root/recovery-key.txt

Remplace <file> par le nom ou le chemin de la sauvegarde. Tu crées d'abord le fichier « /root/recovery-key.txt ». Il contient la clé de récupération. Le fichier de « Save to file... » convient aussi.

Une ligne de commande sur un serveur Linux avec la liste de « list » et, en dessous, la sortie de « key --show ».
En haut, « list » montre les sauvegardes. Les anciennes sauvegardes au format ZIP portent la mention « (Not encrypted) ». En dessous, « key --show » donne la clé de récupération, l'ID de clé et le nombre de sauvegardes non chiffrées. La clé sur l'image provient d'un environnement de test.Ouvrir l'image en taille réelle
7

Les sauvegardes se trouvent sur la même machine

Avant de commencer : Une sauvegarde posée à côté du système ne te protège pas d'une panne de disque. Copie les fichiers ailleurs régulièrement.

Les sauvegardes sont des fichiers dans le dossier que tu as réglé. Ce dossier est sur la même machine que le système de tickets.

Pour les cas courants, cela fonctionne bien. Des données supprimées par erreur, une mise à jour qui a mal tourné ou une erreur dans les données sont toutes couvertes.

Cela n'aide pas contre la panne du disque. Si le disque est perdu, les sauvegardes le sont avec lui.

Copie donc les fichiers ailleurs. Un lecteur réseau, un second serveur ou un stockage sur le réseau suffisent.

Un fichier copié peut être rechargé sur n'importe quel serveur. Sur un autre serveur, tu as besoin pour cela de la clé de récupération. Avec « Import backup file… », tu ramènes le fichier dans la liste.

Les copies sont chiffrées. Personne ne peut les lire sans la clé de récupération. Ne conserve donc pas la clé à côté des copies. Les anciennes sauvegardes se terminant par « .zip » ne sont pas chiffrées.

L'onglet « Settings » avec le champ « Backup directory ».
Le champ « Backup directory » dit où sont les fichiers. C'est le dossier que tu devrais copier ailleurs régulièrement.Ouvrir l'image en taille réelle
8

Avant chaque mise à jour, le système sauvegarde tout seul

Une mise à jour fait sa propre sauvegarde au préalable. Cela se produit indépendamment de ton horaire et sans que tu coches quoi que ce soit.

Elle sauvegarde la même chose que d'habitude : la base de données, les pièces jointes, les archives et les clés. Si la base de données tourne en dehors de SMITEY, la mise à jour ne sauvegarde que les pièces jointes, les archives et les clés.

Cette sauvegarde est faite par l'application « Ticket System Backup & Restore ». Elle est chiffrée comme toutes les autres et se trouve dans le même dossier. Dans la liste, son type est « Update ». Les trois plus récentes de ces sauvegardes sont conservées. L'application supprime les plus anciennes elle-même.

L'avis affiché avant la mise à jour te le dit. Tu n'as pas à penser à sauvegarder toi-même d'abord.

Si cette sauvegarde échoue, la mise à jour s'arrête avant que quoi que ce soit ne soit remplacé. Une base de données en dehors de SMITEY ne retarde pas la mise à jour. La mise à jour change alors le réglage de l'application pour que la sauvegarde quotidienne laisse aussi la base de données de côté. Sauvegarde cette base de données avec tes propres outils.

Plus à ce sujet dans la carte : Mise à jour en appuyant sur un bouton

La confirmation avant la mise à jour avec la remarque sur la sauvegarde.
La phrase « A full backup is taken automatically beforehand » fait partie de la question. La sauvegarde tourne avant que quoi que ce soit ne soit remplacé.Ouvrir l'image en taille réelle

Commandes importantes (Linux)

Prêtes à copier. Tout avec sudo : l'installateur et les conteneurs ont besoin de root.

Installer le prérequis

sudo apt install -y unzip

Sans unzip, l'installateur ne peut pas décompresser le paquet.

Installer le système de tickets

curl -fsSL https://files.smitey.eu/download/get-smitey.sh | sudo bash

Télécharge le paquet et te guide à travers les questions. Le relancer est sans risque : la configuration et les données sont conservées.

Vérifier le HTTPS

sudo /opt/smitey/smitey-install check-https

Pour chaque variante HTTPS. Avec un domaine public, la commande t'indique si le certificat est là. S'il manque, elle donne la raison tirée du journal. Le certificat peut encore arriver quelques minutes après l'installation. Sur ton propre réseau, elle vérifie la connexion avec le certificat racine correspondant.

Retrouver la première connexion

sudo cat /opt/smitey/SMITEY-credentials.txt

Après la première connexion, change le mot de passe et supprime le fichier.

Les conteneurs tournent-ils ?

sudo podman ps

Montre chaque partie du système avec son état.

Suivre le journal

sudo podman logs -f container-backend-1

Montre en direct ce que le backend signale. Arrête avec Ctrl+C.

Vérifier le superviseur

systemctl status smitey-supervisor

Ce service maintient le système en marche et applique les mises à jour que tu déclenches dans l'application.

Créer un ensemble d'assistance

sudo bash /opt/smitey/install.sh --support-bundle

Rassemble les journaux et l'état du système dans un seul fichier zip. Les mots de passe et les clés sont retirés.

Changer l'adresse publique

sudo bash /opt/smitey/install.sh --reconfigure

Définit un nouveau domaine et redémarre, pour que le certificat soit demandé pour le nouveau nom.

Modifier la manière dont SMITEY est joignable

sudo bash /opt/smitey/install.sh --change-access

Bascule entre les cinq variantes, par exemple de HTTP à HTTPS. Entrée seule garde la variante actuelle. Tes données restent.

Le désinstaller

sudo bash /opt/smitey/install.sh --uninstall

Pose la question des données et celle de Podman séparément ; rien n'est supprimé sans qu'on demande.

Les sauvegardes sont gérées par /opt/smitey/Backup/TicketSystemBackup (list, backup, restore) ; la sauvegarde quotidienne tourne toute seule. Les détails se trouvent dans /opt/smitey/docs/en/BACKUP-RESTORE.txt.

Retour au comparatif des fonctionsLes images proviennent de la version 1.3.1.