Au quotidien, nous utilisons le module tickets de Dolibarr pour gérer l’ensemble de nos demandes clients et internes.
Celui-ci présente toutefois de nombreuses lacunes sur lesquelles j’aimerais travailler (seul ou non), et je souhaiterais que nous en discutions ici auparavant pour partir directement dans le bon sens, et savoir ce qui pourrait être intégré et ce qui doit rester du spécifique.
Les principaux défauts et manques actuellement sont surtout :
Le modèle de mail envoyé qui ne donne aucune indication sur le ticket si ce n’est son ID. Pourquoi ne pas passer par le sujet du ticket ?
La possibilité d’ajouter des contacts supplémentaires au ticket depuis l’interface publique → contacts du même tiers que celui qui gère le ticket.
La possibilité de fusionner deux tickets (lorsqu’un client en ouvre un nouveau plutôt que de répondre)
Lier le ticket directement à une tâche et pouvoir effectuer une saisie de temps depuis celui-ci.
Ce ne sont là que mes principales idées, et les plus urgentes selon mes propres besoins.
Lien public non dispo si ouverture depuis le BO (souvent les clients appellent, expliquent leur SAV, on ouvre le ticket et j’aimerai qu’il puissent répondre en ligne
Intégration iframe : proposer un code iframe pour intégrer le formulaire d’ouverture de ticket sur une page « SAV » sur un WP ou Prestashop par exemple
Il faudrait aussi pouvoir imprimer les tickets, et permettre l’impression odf des interventions. C’est très gênant dans mon cas car le module ne permet pas de donner le ticket au réparateur.
Normalement, moyennant une configuration adaptée du serveur web qui sert ton interface publique, tu dois pouvoir l’intégrer à un site sans difficulté, même si tu n’as pas d’iframe communiquée directement depuis Dolibarr.
Bien entendu, là j’ai pris un code existant. Pour le style de ton iframe, ce sera à adapter
Pour ce qui est de l’ouverture depuis le BO, tu as une case à cocher qui te permet de notifier le tiers à la création du ticket. Normalement, ça lui envoie directement un mail avec un lien pour aller sur l’interface publique de son ticket.
Donc si je clique sur « Envoyer Email », ça fait le boulot pour répondre au client…
Le message privé ne doit pas répondre au client, normalement, et ne lui est pas visible depuis l’interface publique…
Il est temps pour moi de remonter un peu ce sujet. Je me suis rendu compte après coup et à cause de ma mémoire de poisson que l’ajout de contacts supplémentaires depuis l’interface publique avait déjà été intégré :
J’ai également fait une PR qui reste en attente concernant le sujet des mails de tickets qui ne permettent pas de connaître le sujet :
Je continue petit à petit ma liste, mais si vous avez d’autres idées à soumettre, n’hésitez pas
Je viens également de me rendre compte que pas mal de choses ont évolué sur develop, et c’est génial !
Par contre que pensez-vous de supprimer la visibilité des adresses destinataires sur l’interface publique ?
Lorsqu’un client répond à un ticket depuis l’interface publique, dans le message notifiant de la réussite ou de l’échec de l’envoi sont indiquées les adresses mail des destinataires. Le client se retrouve donc à connaître l’adresse mail associée au compte de l’utilisateur assigné. Ce qui ne me paraît ni pertinent ni logique.
Le modèle de mail envoyé qui ne donne aucune indication sur le ticket si ce n’est son ID. Pourquoi ne pas passer par le sujet du ticket ?
La possibilité d’ajouter des contacts supplémentaires au ticket depuis l’interface publique → contacts du même tiers que celui qui gère le ticket.
Je travaille actuellement sur la possibilité de lier le ticket à une tâche directement, ce qui inclue l’onglet correspondant depuis la page de la tâche.
N’hésitez pas à continuer à faire vos suggestions ici, pour qu’on puisse avancer sur tout ça
Salut @altairis-benjamin
Un truc qui m’était utile c’est l’affichage du numéro de téléphone des contacts. Quand l’équipe support doit rappeler un simple clic2call et c’est parti.
Pour les curieux j’utilise la téléphonie ovh et le module ovh de @eldy
Bonjour, j’utilise le module ticket et je n’étais pas satisfait de l’interface publique de base.
J’ai trouvé sur le Dolistore le module « Ticket Plus » que je suis depuis le début, le développeur est à l’écoute et prends en compte les demandes des utilisateurs.
Son module propose une interface publique que je trouve bien aboutit, avec une base de connaissance et une interface pour les tickets qui n’utilise pas le module de base de Dolibarr.
Sa base de connaissance se base sur celle de Dolibarr, avec la possibilité de protéger des catégories par mot de passe, et de rechercher les infos grace à l’IA.
Je ne vais pas tarder à le mettre en production pour mes clients.
mais oui via ta technique ça fonctionne !
