Support client SaaS : niveaux, bugs, délais de réponse

Un client SaaS n'achète pas une fois pour s'en aller. Le lundi il se connecte, le mardi il bloque, et le jour du renouvellement il décide si le produit en valait la peine. Le support client SaaS, c'est le travail qui se fait entre ces moments, et il diffère de celui d'une boutique en ligne : les questions portent sur le comportement d'un logiciel, la même personne écrit plusieurs fois, et une partie de ce qui est signalé est un vrai défaut que seule l'ingénierie peut corriger.

Ce guide explique comment structurer l'aide que vous proposez, comment distinguer un signalement de bug d'une question d'usage, comment passer un problème aux développeurs et ce qu'il faut promettre sur chaque offre.

Trois niveaux d'aide

La plupart des équipes SaaS finissent avec trois couches, qu'elles l'aient prévu ou non. Le prévoir, c'est donner un rôle précis à chacune.

Niveau	Convient pour	Qui répond	Attente habituelle
Libre-service (documentation, aides dans le produit)	Étapes de configuration, « où se trouve ce réglage »	Le client lui-même	Aucune
Chat en direct	Question rapide pendant que la personne est dans le produit	Agents du support	Quelques minutes
Tickets	Tout ce qui demande une enquête ou plusieurs jours	Le support, puis d'autres	Quelques heures à quelques jours

Règle pratique : une question qui n'a qu'une bonne réponse va dans la documentation, une question qui demande un coup d'œil humain rapide va dans le chat, et une question qui oblige à regarder le compte ou les journaux va dans un ticket. Hodhod n'inclut pas de base de connaissances ; la documentation reste là où vous la publiez et vous la liez depuis vos réponses prédéfinies. Pour la rédiger, voir base de connaissances et centre d'aide.

Chat et tickets peuvent partager une même boîte. Un chat qui demande finalement une heure de recherche devient un ticket avec tout son historique. Voir tickets et chat en direct.

Les questions d'onboarding forment une catégorie à part

Pendant les deux premières semaines, les gens posent d'autres questions que les utilisateurs de longue date. Ils signalent rarement des bugs. Ils veulent savoir par où commencer.

Rassemblez les questions des vingt ou trente premiers nouveaux comptes et regroupez-les. Ce sont presque toujours les cinq ou six mêmes : connecter les données, inviter des collègues, importer un fichier, bases de la facturation, un réglage déroutant. Ensuite :

Rédigez une réponse prédéfinie pour chacune, avec un lien vers le document ou une réponse en deux lignes.
Placez un court menu de chatbot ou une question préalable devant le chat pour que ces demandes trouvent leur réponse tout de suite.
Ajoutez l'étiquette « onboarding » pour les compter chaque mois.

Si la même question d'onboarding revient sans cesse, c'est probablement le produit ou le premier écran qui manque de clarté. C'est un constat à transmettre à l'équipe produit, pas une raison d'embaucher un agent de plus. Voir réponses prédéfinies et modèles.

Bug ou question d'usage ?

La première tâche sur tout message est de trancher. La réponse et le responsable diffèrent.

Indice	Question d'usage	Bug
Le client dit	« Comment exporter ceci ? »	« L'export renvoie une erreur »
Ça marche chez vous ?	Oui, avec les mêmes étapes	Non, vous voyez la même erreur
Solution	Une réponse, peut-être un document	Une modification du code
Responsable	Support	Ingénierie

Si c'est flou, essayez de reproduire avec la même offre et le même rôle que le client. Si vous n'y arrivez pas, demandez les détails en un seul message plutôt qu'en cinq. Un modèle à copier :

Merci pour votre signalement. Pour vérifier de notre côté, pouvez-vous nous envoyer : 1. La page ou l'écran concerné, et ce que vous attendiez 2. Ce que vous avez vu à la place (une capture d'écran aide) 3. L'heure à laquelle cela s'est produit, avec votre fuseau horaire 4. La version de votre navigateur ou de l'application 5. Si cela arrive à chaque fois ou seulement parfois

La priorité est une décision distincte du type. Un bug qui bloque tous les utilisateurs d'un compte est urgent, et la question d'usage d'un utilisateur en essai à un jour de la fin de son essai peut l'être aussi. Voir tri et priorité des tickets.

Passer un bug à l'ingénierie

C'est là que le support trébuche le plus souvent, non pas parce que les développeurs sont injoignables, mais parce que le signalement arrive sans les informations nécessaires, ou arrive onze fois.

Une note de passation devrait contenir, que vous l'envoyiez dans votre outil de suivi ou à la main :

Résumé du problème en une phrase
Étapes de reproduction et ce que vous avez observé
Compte, offre et heure du premier signalement
Nombre de clients qui l'ont signalé jusqu'ici
Contournement s'il existe, et ce que vous avez dit au client

Dans Hodhod, vous pouvez rattacher conversations et tickets à une issue : une fiche pour un problème, de sorte que l'ingénierie voie un seul élément avec un compteur plutôt qu'un tas de messages. L'issue garde aussi les occurrences quand le problème revient et peut être envoyée à Jira comme ticket d'ingénierie. Voir suivi des issues. Dites au client ce qui va se passer (« nous l'avons transmis aux développeurs et je vous écrirai dès que c'est corrigé ») et fixez une échéance sur le ticket pour penser à écrire.

Quand un problème touche plusieurs comptes en même temps, c'est un incident, pas un ticket. Qui prévenir et quand figure dans le modèle de politique d'escalade.

Le support dans l'application

Le client pose sa question au moment où il est perdu, donc dans votre produit. Un bouton d'aide qui ouvre le chat avec l'utilisateur déjà identifié évite le « quel est votre e-mail ? » et donne du contexte à l'agent. Sur mobile, le SDK Android amène chat et tickets dans l'application native ; voir le tutoriel du SDK Android. Sur le web, c'est le widget du site qui remplit ce rôle.

Délais de réponse selon l'offre

Toutes les offres n'ont pas à recevoir la même rapidité, mais chacune doit recevoir une promesse que vous pouvez tenir. Une structure simple, avec des chiffres d'exemple en heures ouvrées :

Offre	Canaux	Première réponse	Objectif de résolution d'un bug bloquant
Gratuite	Documentation, tickets	2 jours ouvrés	Aucun engagement
Standard	Documentation, chat, tickets	8 heures ouvrées	3 jours ouvrés
Business	Tous, plus un interlocuteur désigné	1 heure ouvrée	1 jour ouvré

Ce sont des valeurs de départ. Partez de ce que votre équipe tient aujourd'hui et vérifiez le calcul : si trois agents traitent chacun environ 30 tickets par jour et que l'offre Business compte 40 comptes qui envoient chacun un ticket par semaine, la file Business est très loin de la limite. Si l'offre gratuite compte 4 000 utilisateurs, ce n'est peut-être pas le cas. Faites votre propre calcul avant d'afficher des chiffres sur une page de tarifs.

Pour l'appliquer dans Hodhod, étiquetez la conversation avec l'offre (par exemple « offre-business ») et créez une règle d'automatisation qui ajoute la politique de SLA correspondante aux conversations portant cette étiquette. Détails dans SLA dans le service client.

Liste de contrôle hebdomadaire

Compter les nouveaux tickets par étiquette : usage, bug, facturation, onboarding
Lire les cinq plus anciens tickets ouverts
Lister les bugs signalés plus d'une fois et demander leur état à l'ingénierie
Repérer les questions d'usage revenues trois fois ou plus, et écrire ou corriger un document
Comparer les échéances manquées aux promesses de chaque offre

Si vous voulez voir cela dans une boîte partagée avec vos propres offres et étiquettes, demandez une démo gratuite.

Questions fréquentes

Les utilisateurs gratuits doivent-ils avoir du support ?

C'est à vous de décider, mais offrez quelque chose : une documentation et un formulaire de ticket avec une promesse plus lente, ou un forum. Le silence se transforme en départ avant le premier paiement.

Qui est responsable des signalements de bug, le support ou l'ingénierie ?

Le support suit la conversation avec le client jusqu'au bout et l'ingénierie s'occupe de la correction. Le client ne devrait pas avoir à raconter son histoire une seconde fois à l'ingénierie ; c'est le rôle de la note de passation.

Comment éviter que la même question d'usage revienne ?

Comptez-la. Quand une question arrive trois fois en un mois, écrivez la réponse dans un document et dans une réponse prédéfinie. Si elle revient quand même, examinez l'écran d'où elle vient.

Le chat en direct est-il indispensable pour un produit SaaS ?

Non. Beaucoup d'équipes fonctionnent avec la documentation et les tickets. Le chat aide quand quelqu'un bloque au milieu d'une tâche ou hésite avant d'acheter, et il demande quelqu'un pour le tenir pendant des horaires annoncés.

D'où vient l'information sur l'offre du client ?

De vous. Hodhod ne lit pas votre système de facturation ; l'offre doit être ajoutée comme étiquette à la main ou par une règle d'automatisation fondée sur d'autres conditions.