Français
+ Tickets et support

Une demande qui ne disparaît pas dans une boîte commune.

Demandes clients et annonces internes avec un responsable, un état visible et l'historique sur le client. Un ticket peut aussi naître d'un formulaire ou d'une conversation.

01 · Le problème

Une boîte commune n'est pas un processus, c'est un espoir.

Les demandes arrivent à info@, à une adresse personnelle, par le formulaire de contact et par téléphone. Celui qui a le temps répond. Deux personnes traitent la même demande, une troisième reste en plan parce que chacun pensait que quelqu'un d'autre l'avait prise. Quand la même cliente rappelle trois semaines plus tard, la reconstitution recommence, car ce qui a été discuté la dernière fois se trouve dans la boîte d'une personne absente aujourd'hui.

02 · Sous le capot

Ce qui transforme une demande en cas traçable.

Répondre n'est pas difficile. Garder la vue sur tout ce qui est ouvert, si. Ces cinq points la donnent.

  • Responsable et statut, Chaque ticket a une personne responsable et un état visible. Pas de double traitement, pas d'abandon silencieux.
  • Historique par client, Demandes, factures et contrats antérieurs se trouvent à côté, au lieu d'être dans quatre systèmes.
  • Depuis formulaire et chat, Un ticket naît d'une annonce de formulaire ou d'une conversation, sans ressaisie.
  • Catégories et priorité, Trié par type et urgence, pour que l'important ne passe pas derrière le bruyant.
  • Analyse par fréquence, Savoir quelle demande revient sans cesse est la base pour la supprimer plutôt que d'y répondre.
03 · Ce que cela apporte

La troisième demande identique, vue comme un schéma et non comme un cas isolé.

Faites le calcul avec vos propres chiffres. À 40 demandes par semaine, l'expérience montre que cinq à dix pour cent passent en double ou pas du tout lorsque la responsabilité n'existe que dans une tête. Cela fait deux à quatre cas par semaine, chacun avec une cliente agacée ou une répétition inutile à l'autre bout. Le levier le plus fort est l'analyse : si la même question revient 30 fois par trimestre, la réponse n'est pas un ticket plus rapide, c'est un article dans le wiki ou une correction du produit. Sans comptage, on ne voit pas le schéma.

04 · Pour qui

Pour qui les tickets et le support sont conçus.

C'est conçu pour les entreprises suisses d'environ cinq à cinquante collaborateurs dont la clientèle continue d'être suivie après la vente : services techniques et éditeurs de logiciels, technique du bâtiment et service, construction de machines avec contrat d'entretien, gérance immobilière, fiduciaires, informatique interne. Typiquement deux à cinq personnes qui répondent aux demandes en plus de leur travail, et une clientèle qui revient d'année en année.

Le gain est le plus net pour qui suit une clientèle récurrente avec un contrat derrière : entretien, forfait de service, abonnement. C'est là que paie le fait d'avoir sur le même dossier ce qui a été annoncé, livré et facturé en dernier. Plus la relation dure, plus cette trace porte.

05 · Migration

Le passage commence par ce qui est ouvert aujourd'hui.

Vous commencez par les cas en cours, pas par l'archive. Ce qui se trouve actuellement dans la boîte, vous le saisissez une fois comme ticket, avec le client, la catégorie et la personne responsable. Vous faites pointer le formulaire de contact de votre site vers un formulaire de la plateforme, pour que les nouvelles demandes naissent comme tickets dès le départ. Les catégories et les priorités, vous les reprenez comme modèle ou vous les nommez selon les cas qui se présentent réellement chez vous. Une responsabilité par défaut par catégorie suffit pour commencer.

Ce qui suit est volontairement léger : pas de semaine de formation, pas de matrice de rôles à concevoir d'abord. La première semaine, l'ancienne boîte continue de tourner, et celui qui en reprend une demande la crée comme ticket en une seule étape. Vous ne devez emporter que les cas ouverts. La correspondance close reste où elle est, et personne ne fait entrer trois ans d'e-mails dans un nouveau masque.

06 · La plateforme

Tickets & support est un module — voici le reste.

07 · Questions fréquentes

Ce que les directions et les responsables du service demandent en premier.

Nos demandes arrivent par cinq canaux. Devons-nous changer les habitudes de notre clientèle ?

Non. Qui téléphone aujourd'hui continue de téléphoner, qui écrit à l'adresse générale continue d'y écrire. Ce qui change, c'est le premier geste ensuite : la demande devient en une étape un ticket avec le client, la catégorie et la personne responsable. Pour le site web, un formulaire en vaut la peine, car il fait arriver dès le départ les indications qu'il faudrait sinon demander.

Qui décide qui est responsable ?

Vous fixez par catégorie une responsabilité par défaut, pour qu'un nouveau ticket ne reste pas sans maître dans l'entrée. Il peut être réattribué à tout moment, aussi à une deuxième personne pour l'escalade, et la modification figure dans la chaîne d'audit avec la personne et l'horodatage. Si quelqu'un part en vacances, vous redistribuez ses tickets ouverts depuis la vue d'ensemble, au lieu de les chercher un à un.

Pouvons-nous l'utiliser aussi pour des annonces internes et pas seulement pour les demandes clients ?

Oui, et c'est souvent le premier cas d'usage : appareils défectueux, accès manquants, défauts constatés dans l'exploitation, demandes à l'administration. L'annonce vient d'un formulaire interne ou d'un entretien, reçoit une catégorie et une personne responsable, et apparaît dans la même vue d'ensemble que les demandes clients. Les deux mondes se distinguent par la catégorie et la visibilité.

Nos contrats d'entretien mentionnent des délais de réaction. Cela peut-il être représenté ?

L'urgence se règle par la priorité et la catégorie, et chaque ticket indique depuis combien de temps il est ouvert. La vue d'ensemble se trie là-dessus, et la question de tout ce qui traîne plus longtemps que convenu, vous la posez directement à l'assistant. Quel délai vaut pour quel client, vous le notez sur le dossier client, où se trouve aussi le contrat.

Où se trouvent les données des tickets, et qu'en est-il de la nLPD ?

Vos données sont hébergées en Suisse. Avant que quoi que ce soit ne soit envoyé à un modèle d'IA externe, notre Sensitive Data Guard masque ou bloque les contenus personnels, contractuels et financiers ; seule la part libérée et non identifiante est transmise, sous contrats sans entraînement. Les demandes d'accès et d'effacement selon la nLPD se documentent par la chaîne d'audit, avec la personne et l'horodatage.

Tous les collaborateurs voient-ils tous les tickets ?

Pas nécessairement. La visibilité se règle par rôle : l'équipe de service voit ses catégories, la direction voit tout, certaines catégories peuvent être restreintes davantage. Un ticket montre l'historique client nécessaire au traitement, et pas automatiquement chaque pièce qui existe pour ce client. Chaque modification figure dans la chaîne d'audit, traçable avec la personne et l'horodatage.

Nos techniciennes sont en déplacement. Cela fonctionne-t-il sur le téléphone ?

Oui. La liste des tickets, l'état et l'historique se présentent sur le téléphone comme au bureau. Un retour après l'intervention tient en une phrase, dictée ou saisie, et il se rattache au bon ticket. Ainsi, le soir, ce qui a été fait figure déjà là, au lieu d'être ressaisi de mémoire le lendemain matin.

Chez nous, un cas de support devient souvent un mandat payant. Et ensuite ?

Alors le cas reste où il est, et le travail dessus devient visible : la charge est consignée sur le ticket et se rattache donc au même client. Il en naît une offre ou un poste sur la prochaine facture, avec les mêmes indications. Les cas plus importants, vous les poursuivez comme projet, avec budget et tâches. Les données de base ne sont pas ressaisies.

Suivez une demande de l'arrivée au schéma, en 30 minutes.

Nous vous montrons un ticket issu d'un formulaire, l'attribution, l'historique client avec les factures à côté, et la question de ce qui est revenu le plus souvent ce mois-ci. Sans contrat, sans préparation.