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.
Les messages traités passent dans le « Processed folder » ; 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, le seul endroit où le système répond de lui-même. Avec cet interrupteur désactivé, ton client ne reçoit jamais de réponse automatique, quelle que soit la qualité du reste de la configuration.
« 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] ».
La référence n'est pas ajoutée toute seule. Elle n'apparaît que là où tu places {ticketTag} ou {ticketId}, et c'est exactement à cela que le système reconnaît plus tard la réponse de ton client. Sans elle dans l'objet, chaque relance ouvre un nouveau ticket au lieu de devenir un commentaire sur l'ancien.
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.
