Configurer le workflow des tickets : priorité, affectation, réponses et clôture

Le module de tickets permet de centraliser les demandes clients et d'organiser leur traitement jusqu'à leur résolution.
Pour conserver une liste de demandes exploitable, il est recommandé de définir un fonctionnement commun : comment utiliser les priorités, qui devient responsable d'un ticket, comment gérer les échanges et à quel moment considérer une demande comme terminée.

Organiser le cycle de vie d'un ticket

Le statut indique l'avancement du traitement de la demande.
Les statuts sont regroupés entre tickets ouverts et tickets clôturés :

Nouveau, En cours et Attente de réponse correspondent à des tickets encore ouverts ;
Résolu, Fermé et Rejeté correspondent à des tickets clôturés.

Ces statuts permettent ensuite de filtrer les tickets et de distinguer les demandes restant à traiter de celles qui ne nécessitent plus d'action.
Une convention interne peut par exemple être définie ainsi :

Nouveau : demande reçue, mais pas encore prise en charge ;
En cours : demande actuellement traitée ;
Attente de réponse : traitement suspendu dans l'attente d'une information ou d'une action ;
Résolu : une solution a été apportée ;
Fermé : traitement définitivement terminé ;
Rejeté : demande ne devant pas être traitée.

Il s'agit d'un exemple d'organisation. L'essentiel est surtout d'utiliser les statuts de manière cohérente au sein de l'équipe.

Utiliser la priorité pour identifier les demandes à traiter en premier

La priorité permet de différencier les demandes courantes des demandes nécessitant une prise en charge plus rapide.
Les niveaux proposés par Organilog sont natifs. Ils ne définissent pas automatiquement une règle métier ou un délai de prise en charge : leur signification peut être adaptée à l'organisation de l'entreprise.
Il peut par exemple être décidé qu'une priorité élevée correspond uniquement à une demande bloquant totalement l'activité du client, tandis qu'une demande pouvant attendre quelques jours conserve une priorité normale.
Définir cette convention en interne évite que chaque collaborateur interprète différemment le niveau d'urgence d'un ticket.
À savoir : un ticket créé automatiquement depuis un email est initialement créé avec le statut Nouveau et la priorité Normal. Ces informations peuvent ensuite être modifiées lors de sa prise en charge.

Permettre ou non au client de choisir la priorité

Lorsqu'un ticket peut être créé depuis le portail client, il n'est pas obligatoire de laisser le client choisir lui-même sa priorité.
Le réglage se trouve dans :
Paramètres > Paramètres généraux > Portail client > Tickets (formulaire d'ajout d'un ticket)
Le paramètre Afficher la priorité permet de choisir si ce champ doit être présenté au client.
Masquer la priorité peut être pertinent lorsque l'entreprise souhaite appliquer elle-même ses propres règles de qualification après réception de chaque demande.

Affecter chaque ticket à un responsable

L'affectation permet d'identifier le collaborateur principalement chargé du traitement de la demande.
Un ticket peut être affecté à un collaborateur puis réaffecté lorsqu'il doit être transmis à une autre personne.
Cette méthode permet notamment d'organiser un véritable passage de relais : plutôt que d'utiliser les réponses du ticket pour demander à un collègue de reprendre le dossier, le responsable peut être modifié.
Dans : Paramètres > Paramètres généraux > Tickets > Page du tableau de bord
le paramètre Afficher un bouton d'assignation permet de faciliter la prise en charge des tickets qui ne possèdent pas encore de responsable.

Affecter automatiquement les tickets provenant du portail client

Il est également possible d'associer un collaborateur à une fiche client, puis d'utiliser cette association lors de la création d'un ticket depuis le portail client.
Le paramètre suivant est disponible dans :
Paramètres > Paramètres généraux > Portail client > Tickets (formulaire d'ajout d'un ticket)
Relier les tickets créés au collaborateur relié à la fiche client
Une fois activé, ce fonctionnement peut être utile lorsque chaque client possède un interlocuteur ou un responsable attitré dans l'entreprise.

Différencier le responsable et les collaborateurs à notifier

Le responsable du ticket et les collaborateurs à notifier ne jouent pas le même rôle.
Le responsable correspond à la personne principalement chargée du traitement de la demande.
Les collaborateurs à notifier permettent plutôt d'identifier d'autres personnes concernées par le dossier. Ce champ ne doit pas être considéré comme une seconde affectation.
En particulier, ajouter un collaborateur à notifier ne provoque pas systématiquement l'envoi d'un email lors de chaque évolution du ticket. Ces collaborateurs peuvent recevoir des notifications dans le navigateur lorsqu'ils sont connectés à Organilog, mais cela ne remplace pas l'affectation au responsable.
Sur l'application mobile, un collaborateur doit également être réellement affecté au ticket pour retrouver les demandes dont il est responsable. Le simple fait d'être ajouté parmi les collaborateurs à notifier ne constitue pas une affectation.
Conseil : lorsqu'un dossier doit réellement passer d'un collaborateur à un autre, modifier le responsable du ticket plutôt que d'ajouter uniquement la personne dans les collaborateurs à notifier.

Gérer les notifications liées à l'affectation

Les notifications générales peuvent être consultées depuis : Paramètres > Centre des notifications
Certaines notifications sont cependant gérées automatiquement par Organilog.
C'est notamment le cas de la notification Ticket assigné, envoyée lorsqu'un ticket est attribué à un collaborateur. Cet email est généré automatiquement et son contenu n'est actuellement pas personnalisable.
L'adresse utilisée pour les notifications d'un collaborateur correspond à l'adresse email renseignée sur sa fiche utilisateur.

Organiser les réponses et les échanges

Les réponses permettent de conserver l'historique des échanges directement dans le ticket.
Selon le fonctionnement choisi, elles peuvent servir :

aux échanges avec le demandeur ;
aux échanges avec le client ;
au suivi interne du dossier.

Lorsqu'une réponse ne doit pas être visible à l'extérieur, il est possible de privilégier les réponses privées.
Dans : Paramètres > Paramètres généraux > Tickets > Page d'édition
le paramètre Rendre les nouvelles réponses privées par défaut permet de définir le comportement proposé lors de l'ajout d'une nouvelle réponse.
Ce réglage est particulièrement utile lorsqu'une grande partie des échanges enregistrés dans les tickets correspond à des commentaires internes.

Permettre au client de répondre au ticket

Organilog peut également mettre le ticket à disposition du client.
Dans : Paramètres > Paramètres généraux > Tickets > Page publique
plusieurs réglages sont disponibles, notamment :

Activer la page publique des tickets ;
Activer le formulaire de réponse.

Des réglages similaires permettent d'afficher les réponses et un formulaire de réponse depuis le portail client ou le portail contact.
Il est ainsi possible de choisir entre un workflow principalement interne et un fonctionnement dans lequel le client participe directement aux échanges depuis son accès Organilog.

Transformer une demande en intervention

Un ticket peut être utilisé comme point d'entrée d'une demande avant sa prise en charge sur le terrain.
Les réglages correspondants se trouvent dans : Paramètres > Paramètres généraux > Tickets > Interventions
Plusieurs comportements peuvent être configurés :

Associer une intervention à un ticket

Permet de conserver le lien entre la demande initiale et l'intervention réalisée pour la traiter.

Créer automatiquement une intervention à la création d'un nouveau ticket

Permet d'enchaîner automatiquement la création de la demande et celle de l'intervention lorsque chaque ticket doit systématiquement donner lieu à un passage.

Fermer un ticket lorsque l'intervention associée est terminée

Permet d'automatiser la clôture du ticket lorsque le traitement de la demande correspond directement à la réalisation de l'intervention associée.
Cette dernière option doit correspondre au fonctionnement de l'entreprise. Si certaines demandes nécessitent plusieurs actions ou plusieurs passages avant d'être réellement terminées, il peut être préférable de conserver une clôture manuelle.

Exemple de workflow

Un fonctionnement simple peut être organisé de la manière suivante :

Une nouvelle demande arrive avec le statut Nouveau.
Sa priorité est contrôlée et éventuellement modifiée.
Un responsable est affecté au ticket.
Le ticket passe En cours pendant son traitement.
Si une information manque, il passe en Attente de réponse.
Les échanges et actions réalisées sont conservés dans les réponses du ticket.
Une intervention est créée ou associée lorsque la demande nécessite un passage sur le terrain.
Une fois la demande traitée, le ticket passe en Résolu ou Fermé selon la convention retenue.

L'objectif n'est pas de multiplier les changements de statut, mais de permettre à n'importe quel collaborateur consultant la liste des tickets de comprendre immédiatement ce qui reste à traiter et qui en est responsable.

Articles associés

Mis à jour le : 12/09/2026

Cet article a-t-il répondu à vos questions ?

Merci !