Traitez les demandes d'assistance avec attributions, notifications et historique complet. Gérez votre propre service d'assistance dans le CRM pour qu'aucune demande ne reste sans réponse.
Gérez votre propre support client avec affectations, notifications et historique complet.
Le module de tickets est un service d'assistance interne pour vos propres clients, logé à côté de leur fiche prospect. Un ticket a un sujet, un contact lié, un responsable, une priorité (basse, normale, haute, urgente) et un statut (ouvert, en attente, résolu, fermé), avec horodatage de la résolution et de la fermeture. En dessous court un fil de conversation où réponses et notes internes se côtoient, et une réponse peut changer le statut dans la même action. L'affectation déclenche une notification dans l'application et, si activé, un e-mail. Ce n'est délibérément pas un portail client : votre équipe enregistre la demande, le client continue de vous parler sur WhatsApp ou au téléphone. Disponible à partir de la formule Growth.
Dès qu'une entreprise dépasse une poignée de clients, « quelqu'un a appelé pour un problème » commence à passer entre les mailles. Cela part dans un groupe WhatsApp, sur un post-it, dans un e-mail à la personne qui semblait responsable, et trois jours plus tard le client rappelle, plus fâché, et tombe sur quelqu'un qui n'en a jamais entendu parler.
Les produits d'assistance dédiés résolvent cela pour les services support. La plupart des petites entreprises pilotées par la vente n'ont pas de service support ; les mêmes cinq personnes vendent, livrent et réparent. Pour elles, un outil séparé est un identifiant de plus que personne n'ouvre et — pire — un endroit où l'historique du client est coupé de la fiche que le commercial utilise réellement.
Le ticket vit donc sur le contact. Quand le commercial ouvre le prospect pour une vente additionnelle, le ticket ouvert est là ; quand le collègue du support ouvre le ticket, le montant de l'affaire et son responsable sont là. Les deux conversations qui tournent le plus souvent mal — « vous me demandez d'acheter plus alors que ma dernière commande est encore en panne » — cessent d'être une surprise.
| Statut | Signifie | Qui agit ensuite | Horodatage |
|---|---|---|---|
| Ouvert | Enregistré, pas encore traité ou en cours | Votre équipe | création |
| En attente | Dépend du client, d'un fournisseur ou d'une pièce | Quelqu'un d'autre | — |
| Résolu | Vous pensez que c'est corrigé ; en attente de confirmation ou de délai de sécurité | Le client, implicitement | résolution, première fois seulement |
| Fermé | Terminé ; plus aucune action attendue | Personne | fermeture, première fois seulement |
La distinction entre ouvert et en attente est celle que les équipes sautent le plus souvent et regrettent le plus souvent. Une file de quarante tickets « ouverts » dont vingt-cinq attendent en réalité un fournisseur ressemble à une crise et cache les quinze qui sont vraiment à vous. Passez-les en attente et la file dit la vérité.
Résolu et fermé sont séparés à dessein. Le délai de résolution — de la création à la résolution — mesure votre équipe. La fermeture est administrative et peut intervenir des jours plus tard ; elle ne doit pas fausser la métrique.
Chaque ticket a un fil de conversation. Deux types d'entrées y vivent :
Le formulaire de réponse porte un sélecteur de statut : « envoyer et passer en attente », « envoyer et passer en résolu ». Une interaction de support change presque toujours l'état du ticket, et demander cela comme un second clic est la façon dont les tickets finissent ouverts à jamais. Une action, deux effets, une entrée de journal.
À droite du fil se trouve la carte de gestion : statut, priorité, responsable et contact lié, chacun modifiable sur place, plus une chronologie créé / résolu / fermé avec les personnes impliquées.
La liste des tickets est faite pour être lue en deux secondes par quelqu'un qui a quarante autres choses à faire.
Un nouveau ticket est une fenêtre sur la même page — sujet, description, contact, responsable, priorité — de sorte qu'enregistrer un appel prend le temps de l'appel, pas celui d'un chargement de page.
Les tickets sont une entité à part entière dans le modèle de droits. Un rôle peut recevoir voir, créer, modifier et supprimer sur les tickets indépendamment de tout le reste : un technicien peut traiter la file sans voir le pipeline des affaires, et un commercial peut enregistrer un ticket sans pouvoir en fermer un.
Le périmètre par département s'applique comme partout dans le système : un responsable voit les tickets de son département, un membre les siens et les non affectés, un administrateur tout. Créer ou réaffecter un ticket envoie au nouveau responsable une notification dans l'application, et un e-mail si l'événement ticket affecté est activé dans les réglages mail.
Il vaut la peine d'être précis, car le mot « tickets » porte des attentes.
Ce n'est pas un portail orienté client. Les clients ne se connectent pas, ne voient pas de numéro de ticket et ne reçoivent pas d'e-mails automatiques du ticket. Il n'y a pas d'ingestion e-mail-vers-ticket, pas d'horloge SLA avec escalade, pas de base de connaissances publique. Les demandes arrivent comme elles arrivent déjà — WhatsApp, téléphone, en personne — et votre équipe les enregistre.
Ce que c'est : un registre partagé, soumis aux droits et historisé de chaque problème client, attaché au client. Pour une équipe de cinq à cinquante personnes, c'est la pièce qui manquait ; le portail et le moteur SLA sont en général les pièces qui n'auraient jamais servi.
À part, SaleInline a son propre service d'assistance pour vous en tant que client — dans le panneau sous Aide → Support, avec pièces jointes et catégories. C'est un système distinct du module de tickets décrit ici.
| Symptôme | Cause la plus probable | Correctif |
|---|---|---|
| Tout est « ouvert » | L'équipe n'utilise jamais « en attente » | Fixer la règle : dépend de quelqu'un d'autre = en attente ; utiliser « envoyer et passer en attente » |
| Le délai de résolution paraît catastrophique | Les tickets sont fermés directement, sans passer par résolu, des jours après la correction | Passer en résolu dès la correction ; fermer plus tard. Seul le premier horodatage de résolution compte |
| Personne n'a été notifié d'une affectation | Événement e-mail désactivé, ou la personne s'est affecté le ticket à elle-même | Activer l'événement ; l'auteur est ignoré par conception |
| Un collègue ne voit pas le ticket | Pas de droit « voir » sur les tickets, ou hors de son périmètre de département | Ajuster le rôle ou réaffecter dans le périmètre |
| Le ticket manque dans l'historique du client | Créé sans contact lié | Renseigner le contact sur la carte de gestion ; modifiable après création |
| Une note interne a été lue au client | Erreur humaine — les notes sont en ambre et étiquetées | Formation ; le système n'envoie jamais les notes nulle part |
| Formule | Module de tickets clients | Rôles par entité pour les tickets | Périmètre par département |
|---|---|---|---|
| Starter | — | — | — |
| Growth | Inclus | Inclus | Inclus |
| Business | Inclus | Inclus | Inclus |
| Enterprise | Inclus | Inclus | Inclus |
Le module de tickets, les rôles complets par entité et le périmètre par département arrivent ensemble avec la formule Growth. Les espaces Starter peuvent consigner les problèmes clients comme des tâches sur le contact, palliatif raisonnable pour une très petite équipe. Voir la page tarifs pour le comparatif complet et rôles et droits pour la manière dont la visibilité des tickets est contrôlée.
Créez votre espace en moins d'une minute — gratuit pendant 14 jours.
Créer votre espace