Modèles de ticket

Créez des modèles pour les tickets récurrents (ex. : déploiement, intégration client, support standard) : titre, description, type, checklist d'éléments. Ouvrir un ticket à partir d'un modèle remplit tout en une fois.

Quelles checklists naissent prêtes quand une demande est ouverte. Un modèle est une liste d'étapes liée à un type de demande — le moyen de garantir que personne n'oublie l'étape dont seul le plus expérimenté se souvient.

Installation, ticket de support et projet de déploiement exigent des étapes différentes. Liez chaque modèle au type de demande correspondant : ainsi, la personne qui ouvre n'a aucune checklist à choisir — elle arrive déjà correcte.

La liste repose sur le moteur standard de la plateforme : elle exporte l'ensemble complet en Excel, PDF et CSV, conserve des vues enregistrées par utilisateur, permet de choisir les colonnes visibles par écran et garde la corbeille — ajoutez ?excluidas=1 à l'URL pour voir et récupérer les modèles supprimés. La recherche par ?q=texte et le filtre par ?fd_=valeur fonctionnent aussi directement dans l'URL, ce qui permet de partager par lien un extrait comme « les modèles actifs de type bug ».

Le titre par défaut et la description par défaut sont le texte avec lequel la demande est créée lorsque quelqu'un l'ouvre à partir de ce modèle — le créateur peut l'ajuster, mais part d'un texte qui demande déjà les bonnes informations. Utilisez la description par défaut comme un petit formulaire : « Environnement : / Étapes pour reproduire : / Résultat attendu : » évite la deuxième série de questions que provoque toute demande mal ouverte. Le nom du modèle est interne, pour qui le choisit dans la liste ; le titre par défaut est ce que voit le demandeur.

Outre le texte, le modèle définit la classification avec laquelle la demande est créée : le type de demande, la priorité et la gravité. Cela compte plus qu'il n'y paraît — ce sont exactement les trois valeurs qui choisissent la règle de SLA de la demande, donc un modèle avec une mauvaise priorité crée en série de mauvais engagements de délai. Modélisez la classification pour le cas typique de ce travail et laissez l'exceptionnel être ajusté manuellement par celui qui ouvre la demande.

Les éléments du modèle sont copiés dans la demande au moment de sa création. Modifier le modèle ensuite ne change PAS les demandes déjà ouvertes — elles gardent la checklist reçue, ce qui préserve l'historique de qui a accompli quoi.

Quand vous enregistrez une vue avec le bouton Vues, elle garde quatre choses : le texte de recherche, les filtres appliqués, les colonnes affichées (et leur ordre) et la colonne de tri de la liste. Appliquer la vue restaure tout d'un coup — y compris en réinitialisant le tri et la page où vous étiez, pour que le résultat soit exactement ce que la vue décrit. Les vues enregistrées avant cette version restent valables : ce qu'elles ne gardaient pas ne change tout simplement pas à l'application.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Le modèle peut contenir des éléments — des étapes ordonnées qui deviennent le scénario/la checklist de la demande créée à partir de lui : « collecter les logs », « reproduire en recette », « valider avec le client ». C'est la différence entre un modèle qui fait seulement gagner de la saisie et un modèle qui standardise le TRAVAIL : avec les éléments, toute demande de ce type naît en connaissant le chemin. N'oubliez pas que le modèle est appliqué à l'ouverture et devient une copie : modifier les éléments ici vaut pour les prochaines demandes, cela n'altère pas celles déjà créées.

Dans le panneau d'activité de l'enregistrement, chaque note propose « Transformer en demande ». Le clic crée un ticket avec le texte de la note, son auteur et le lien vers cet enregistrement — rien n'est ressaisi. Utilisez-le quand la note est une demande d'action (« quelqu'un doit revoir ceci ») ; la note reste où elle était. Le bouton n'apparaît qu'une fois l'enregistrement sauvegardé ; une session en lecture seule (démonstration) n'en crée pas.

Ouvrez l'enregistrement et regardez la Chronologie, à droite : elle montre chaque modification sous la forme « d'une valeur à une autre », avec la personne et la date. Quand il y a beaucoup de modifications, utilisez les deux filtres en haut de la chronologie — l'un par champ, l'autre par personne. La recherche se fait dans la base, donc une modification ancienne apparaît de la même façon. Vous pouvez aussi demander à Tenkai : « qui a modifié le contrat 482 ? ».

C'est l'écran qui répond à cette question. Vous arrivez aussi ici par Ctrl+K en cherchant : ticket, support, demande, incident, help desk, assistance.