Comment créer un système de tickets pour service d'assistance : tickets, statuts, affectation et e-mail

Un système de tickets d'assistance transforme des demandes éparpillées — e-mails, messages, « petites questions » lancées dans le couloir — en tickets : un enregistrement par problème, avec un responsable, un statut, une priorité et l'intégralité de la conversation. Pour en créer un, il vous faut un moyen de créer des tickets, une file partagée avec des filtres, une affectation, un fil qui sépare les réponses publiques des notes internes, et des notifications pour que personne ne reste sans réponse. Un créateur d'applications IA peut construire une première version solide pour un bureau informatique, RH ou services généraux interne en une après-midi. L'assistance client avec gestion des fils de discussion par e-mail, délais de réponse et rapports demande plus de soin — c'est là que les produits d'assistance établis justifient leur prix.

Ce dont le système a besoin

Données

Enregistrez les horodatages de première réponse et de résolution dès le départ. Ce sont eux qui servent de base à tous les rapports, et vous ne pourrez pas les reconstituer plus tard.

Pages

• Demandeur : un formulaire « soumettre une demande » avec catégorie et pièces jointes, une liste « mes demandes », et le fil de chaque ticket.
• Agent : la file (mes tickets, non affectés, tous les ouverts), filtres et recherche, la vue du ticket avec les commandes de réponse, de note, de statut, de priorité et de responsable.
• Administrateur : catégories, équipes, agents, réponses types, et un rapport simple.

Droits d'accès

Les demandeurs ne voient que leurs propres tickets et seulement les réponses publiques. Les agents voient les tickets de leur équipe et les notes internes. Les responsables et les administrateurs voient tout et gèrent les paramètres. Une note interne qui fuite vers un client est le désastre classique des services d'assistance : appliquez cette règle sur le serveur, pas seulement en masquant un onglet. Voir le contrôle d'accès par rôle.

Décisions et compromis

Formulaire, e-mail ou les deux

Un formulaire web est le plus simple et donne des données propres : catégorie, priorité et champs obligatoires. La réception par e-mail — les personnes écrivent à support@ et un ticket apparaît — est ce qu'attendent les clients, mais elle nécessite un prestataire d'e-mails capable de recevoir les messages et de les transmettre à votre application, ainsi qu'une gestion des fils pour que les réponses se rattachent au bon ticket (en général un numéro de ticket dans l'objet ou une adresse de réponse unique). Commencez par le formulaire ; ajoutez l'e-mail une fois le fonctionnement validé. Envoyer des e-mails depuis votre application couvre la partie sortante.

Affectation

Les options : les agents choisissent dans la file des non-affectés ; attribution en rotation au sein d'une équipe ; ou affectation par catégorie. Choisir dans la file convient aux petites équipes. L'affectation automatique aide lorsque des tickets restent sans responsable.

Priorités et délais de réponse

Définissez deux ou trois priorités avec un délai pour la première réponse (« urgent : 1 heure, normal : 1 jour ouvré »). Afficher le temps restant sur chaque ticket est plus utile qu'un rapport mensuel que personne ne lit. Les heures ouvrées compliquent les calculs — décidez tôt si les délais tiennent compte des nuits et des week-ends.

Fusion et doublons

Le même problème signalé trois fois est fréquent. Une action « fusionner dans le ticket n° » évite aux agents de répondre plusieurs fois à la même chose ; elle vaut la peine d'être construite tôt.

Un premier prompt qui fonctionne

Crée un service d'assistance informatique interne pour une entreprise de 60 personnes. Les salariés soumettent des demandes avec un formulaire : objet, catégorie (matériel, logiciel, accès, réseau, autre), priorité (faible, normale, urgente), description et pièces jointes. Chaque ticket reçoit un numéro et les statuts nouveau, ouvert, en attente du demandeur, résolu, fermé. Les agents informatiques voient une file avec des onglets pour non affectés, mes tickets et tous les ouverts, des filtres par catégorie, priorité et statut, et une recherche. La page du ticket affiche le fil avec les réponses publiques et les notes internes clairement séparées ; les salariés ne voient jamais les notes internes. Les agents peuvent affecter, changer le statut et la priorité, utiliser des réponses types et fusionner les doublons. Suivre les délais de première réponse et de résolution, et afficher sur chaque ticket le temps écoulé depuis la dernière mise à jour. Les salariés ont une page « mes demandes ». Rôles : salarié, agent, administrateur. Stocke tout dans une base de données. Interface sobre, dense et rapide — la vitesse avant la décoration.

Étapes de création

1. Modèle de ticket et formulaire. Soumettre, lister, ouvrir un ticket, répondre.
2. File et filtres. Non affectés, mes tickets, tous les ouverts ; filtrer et chercher ; trier par priorité et ancienneté.
3. Rôles et connexion. Demandeur, agent, administrateur — avec des notes masquées aux demandeurs côté serveur.
4. Commandes d'affectation, de statut et de priorité, avec un journal d'activité de chaque modification.
5. Notifications. Envoyer un e-mail au demandeur pour les réponses publiques et à l'agent pour les nouvelles affectations, via votre propre prestataire d'e-mails.
6. Réponses types et fusion.
7. Délais de réponse et rapport de base : tickets ouverts par ancienneté, délai de première réponse, tickets par catégorie.
8. Réception par e-mail, une fois le reste en place, avec une gestion des fils testée à fond.
9. Test pilote avec une équipe pendant deux semaines avant de passer tout le monde.

Erreurs courantes

• Des notes internes visibles des demandeurs parce qu'elles n'étaient masquées que dans l'interface.
• Trop de statuts et de catégories. Les agents choisissent le premier qui ressemble à la situation. Limitez-vous à cinq de chaque au maximum au départ.
• Aucun horodatage pour la première réponse et la résolution. Vous voudrez ces chiffres le jour où quelqu'un demandera « allons-nous plus vite ? »
• Les réponses par e-mail qui créent de nouveaux tickets au lieu de se rattacher aux existants. Testez une réponse depuis une application de messagerie sur téléphone, qui modifie souvent l'objet.
• Tout le monde affecté, personne responsable. Un seul responsable par ticket ; utilisez des observateurs pour les autres.
• Des pièces jointes avec des URL publiques. Les captures d'écran de messages d'erreur contiennent souvent des données privées. Gardez les fichiers privés et ne les servez qu'aux personnes autorisées à voir le ticket.

Quand un produit clé en main est le meilleur choix

Pour l'assistance client par e-mail, chat et réseaux sociaux — avec suivi des délais de réponse, enquêtes de satisfaction, macros, rapports et intégrations — un produit d'assistance dédié est presque toujours le meilleur investissement. Ces produits ont passé des années sur la gestion des fils d'e-mails, le spam, le routage et les rapports, et ce ne sont pas eux qui vous distinguent de vos concurrents. Notre guide des alternatives à Zendesk compare les options.

Une création sur mesure convient aux bureaux internes (demandes informatiques, RH, services généraux, finance), aux workflows de niche où un ticket est en réalité un travail avec des étapes précises, et aux équipes qui veulent relier les demandes à d'autres données qu'elles conservent déjà. Elle évite aussi la tarification par agent lorsque beaucoup de personnes traitent occasionnellement des tickets. Le guide des outils internes couvre cette catégorie plus largement.

Créer le système avec Mythex

Sur Mythex, vous décrivez le service d'assistance dans le chat, vous le vérifiez dans un aperçu en direct, et vous le publiez pour votre équipe. Les tickets sont stockés dans une base de données Postgres que l'agent ajoute lorsque les données doivent être enregistrées, et les pièces jointes vont dans le stockage de fichiers du projet. Les connexions des demandeurs et des agents, ainsi que tous les e-mails entrants et sortants, passent par vos propres prestataires — Mythex n'a pas de produit intégré de connexion utilisateur final ni d'e-mail ; la recette d'envoi d'e-mails montre la démarche. Les membres de l'équipe peuvent participer à la création via un espace de travail partagé, sans frais par siège sur Mythex lui-même.

Pour partir d'un prompt existant, essayez les modèles file de demandes internes ou suivi de bugs, et associez le service d'assistance à une base de connaissances pour que les questions courantes trouvent leur réponse seules.

Questions