Le suivi de bug comme outil pour le service clients

Dans Starting over with customer service, Seth Godin annonce qu’il a trouvé un outil idéal pour le service client. Il est parfois difficile de suivre ses écrits un peu éparpillés (probablement parce qu’il doit écrire sur son blackberry, entre deux séminaires…) mais après un développement labyrinthique, il propose, pour résoudre le problème des informations asynchrones (entre la demande du client et la résolution de sa réclamation), l’utilisation du bugtracking (Mantis, FlySrpay, Fogbug ou GitHub Issue Tracker) pour le service client.

Son article date de 2007, alors comme c’est un gourou on s’attendrait à  retrouver l’outil dans tous les services clients. Sauf que ce n’est pas le cas.

Pourquoi ?

  • Parce que c’est un logiciel d’informaticiens pour les informaticiens. Mais comme souvent leurs outils peuvent servir à autre chose ;
  • Parce que comme le wiki et les faq, c’est un outil plutôt austère, avec un faible usability ;
  • Parce que c’est une vision anglo-saxonne, là bas on responsabilise plus, même pour des postes moins gratifiants que celui de directeur marketing.

Comment ça marche ?

Le bugtracking utilise un système de ticket pour ouvrir une demande qui doit être qualifiée (fonctionnalité / bug / problème de paiement / ergonomie etc…).

Après une demande client, la problèmatique est analysée par le conseiller qui vérifie la pertinence de sa demande. Il peut y joindre des copies d’écran si besoin est. Il y donc en plus une notion de testing.

Le ticket est ensuite envoyé à un expert (un développeur par exemple). Le conseiller et le développeur peuvent se faire des échanges d’information via le ticket qui conserve tout l’historique.

Ainsi tous les deux doivent résoudre le problème ensemble. C’est un projet commun, qui est tracké en terme de temps et en terme de responsables (propriétaire du ticket, en anglais owner).

Sur certaines applications, on peut lier des tickets ensemble si les dysfonctionnements sont les mêmes mais avec des clients différents.

Le ticket reste ouvert jusqu’à la fin de la résolution.

En plus les tickets sont affectés d’un indicateur du degré d’urgence de résolution (critique – urgent – normal).

Comme je le précisais plus haut, on l’utilise souvent dans les compagnies qui développent des logiciels ou des services web. Pourtant il y a des avantages à l’utiliser pour traiter les réclamations.

En terme d’efficacité c’est un outil assez redoutable car il fait un pont direct entre le service client et la technique. L’échange d’information est instantanée, il n’y a pas de frein du à des protocoles trop lourd. Il faut juste mettre au point quelque règles pour éviter tout débordement (trop de tickets ouverts sur le même problème avec le même client, ou des tickets ouverts sans même vérifier la véracité de la réclamation, ou des tickets jamais fermés).

Il est donc utile pour les améliorations du site, pour la résolution des dysfonctionnements.

Les bugtracking sont généralement des logiciels libres et mis à jour régulièrement et suivis par forte communauté.

Par contre ils ne fonctionnent bien que dans les entreprises à systèmes ouverts, décidés à faire transiter rapidement l’info sans encombre pour améliorer l’expérience de ses clients et les fidéliser.

A propos de l’auteur

MonServiceClient constate tous les jours que la vie des clients pourraient être meilleure avec les entreprises et les institutions. C'est avec esprit positif que nous apportons notre expertise aux sociétés qui ont le désir de mieux servir le client.