Comment mon ESN a doublé sa satisfaction client [spoiler : avec un vrai support client]

Alors qu’une majorité de développeurs accepte maintenant l’utilisation d’un tracker, alors que beaucoup de clients y sont habitués, j’ai décidé pour un de mes clients de considérer mon équipe de développement comme un “service client” à part entière. Avec tous les outils et la méthodologie que cela implique. J’ai déployé Freshdesk. Verdict : mes clients sont ravis, j’ai diminué par 2 le temps de traitement des incidents et les développeurs ont accepté ce changement qui augmente leur productivité et réduit les échanges inutiles.

Je dirige avec joie NumeriCube, une ESN tout ce qu’il y a de plus respectable, depuis 10 ans. Avant cela, j’ai été COO d’une autre ESN spécialisée dans l’Open-Source, Ingeniweb (devenue AlterWay, rachetée par Econocom). Comme beaucoup de chefs de projets, j’ai passé une bonne partie de ma vie professionnelle à faire l’interface entre mes clients et mes développeurs. C’est pas que les uns et les autres ne sont pas gentils ou refusent de collaborer, mais le cœur de leur métier n’est PAS de collaborer entre eux. Et ils parlent souvent un langage trèèèèès différent. Voici un florilège de quelques échanges (en mode “webagencyfail” :))

• [Client vs Dev] : “Ça marche pas.” (oui, oui, juste “ça marche pas”, hors de tout contexte)
• [Dev vs Client] : “Je comprends pas, ça marche sur mon poste”
• [Client] : “C’EST URGENT” (pour un ticket concernant le remplacement d’un logo en bas de la page des mentions légales pour cause d’un léger écart dans une des couleurs)
• [Client] : “URGENT !!!!!!!!!!!!!” (pour mise en ligne d’une carte de vœux de l’année n, ticket rédigé en novembre de l’année n-1“
• [Dev vs Client] : “Vous pouvez tenter de reproduire en utilisant la version pré-release d’un navigateur sécurisé sous une version compilée d’une branche d’Ubuntu ?”

Je prenais cela avec philosophie et résignation, et j’avais fini par mettre ce message sur le bug tracker de la boîte pour faire sourire les développeurs :

Mon message de bienvenue sur Redmine

J’avais aussi mis un petit message à l’attention de mes clients :

N’hésitez pas à illustrer avec vos tickets une copie d’écran au format image (surtout pas dans Word ou PowerPoint !).
Ne retaillez pas vos copies d’écran : souvent, l’information essentielle dont nous avons besoin est dans la barre d’adresse du navigateur, par exemple.
N’écrivez pas “Urgent” dans le titre des tickets, utilisez les niveaux de priorité pour cela.

Le principe du message d’avertissement, c’est que personne ne le lit. Si tout le monde lisait les messages d’avertissement, on n’aurait d’ailleurs pas le bonheur de profiter des Darwin Awards.

Bref, j’en avais marre de faire le rabat-joie des deux côtés ou d’expliquer à chaque nouveau client les règles intransigeantes avec lesquelles il fallait vivre pour accepter de bosser avec moi. Pire, j’avais besoin d’expliquer ce qu’était un bug tracker. À mes clients. Qui ont un métier et autre chose à foutre que de lire le manuel d’utilisation de Jira 143 pages (ne cliquez pas si vous êtes pressés).

Pour les curieux, j’utilisais Redmine et SVN (ouais, je suis vieux, Git c’était pour les bébés).

Moi à chaque fois qu’un client et un dev essayaient de communiquer en direct

Client != Développeur

Un jour, je tombe sur Freshdesk. Je ne suis pas un pro du helpdesk, j’ai l’habitude d’éviter ça dans les sites que je visite, mais j’ai dû admettre que c’était pas mal. Juste pour rigoler, je l’ai mis chez un client, discrètement. Concrètement, ça se présente sous la forme d’un encart sur la gauche du site intitulé “Besoin d’aide” et disponible sur chaque page. Quand un utilisateur clique dessus, il obtient la page suivante :

Le widget de Freshdesk

En gros c’est un formulaire de contact. OUI MAIS. D’une part, c’est juste une ligne de Javascript à intégrer dans mon site, donc facile à intégrer. D’autre part, je peux configurer les données dont j’ai besoin. Et enfin et surtout, chaque fois qu’un ticket part vers Freshdesk, il lui est associé un certain nombre de méta-données assez précieuses :

• la date et l’heure
• le navigateur, l’OS, tout le tralalala (le genre de truc qui évite d’entendre “j’comprends pas ça marche sur mon poste”)
• L’utilisateur peut joindre une copie d’écran (prise en charge par le navigateur). Vous voyez le petit appareil photo, en bas de la zone de texte ? Ben c’est là que ça se passe. Fastoche. Et la copie d’écran n’est jamais tronquée ni copiée/colée dans un document Word ou Powerpoint (ou pire : OpenOffice)

Et vous savez quoi ? Ce formulaire, c’est juste le point d’entrée vers mon bug tracker, qui est maintenant dans Freshdesk. Côté client, ça présente de nombreux avantages :

• Plus d’URL / login / mot de passe d’un énième site à retenir (vu que c’est intégré sur chaque page de son site)
• Pas besoin d’un manuel utilisateur de 143 pages pour soumettre un bug
• Pas besoin d’outil externe ou de compétence autre (outil de capture d’écran collée dans Paint — allez, avouez, ça vous rappelle des souvenirs ?)
• Et petit avantage supplémentaire : l’outil de tracking est ouvert à tous les utilisateurs du site. Parce qu’au final, les vrais “clients”, de votre travail, ce sont eux : ceux qui utilisent tous les jours vos sites.

Bien sûr, le client dispose d’une interface pour consulter son listing de bugs, voir les retours, recevoir des notifications, etc. Mais l’essentiel est là : le dépôt de ticket est maintenant ultra simple, intuitif et non-intrusif.

Ah oui, et j’oubliais : plus de demande d’ouverture de compte à Redmine (ou Jira) non-plus, puisque tout le monde a accès à l’outil. Côté client, cela a permis d’alléger considérablement la tâche de la personne chargée de collecter les demandes : plus de mails interne, ça passe directement par l’outil. “Passe par ‘besoin d’aide'” est devenu une blague récurrente — une blague qui fait gagner beaucoup de temps à beaucoup de monde. Voici un cas concret avant / après.

• Antoine constate une anomalie [instantané]
• Il fait une copie d’écran (tronquée) et envoie un mail à Claire, la personne chargée de la maîtrise d’ouvrage côté client. [2 minutes de charge]
• Claire reçoit le mail mais n’a pas nécessairement le temps de le traiter maintenant [de 10 minutes à 2h voire plus de délai]
• Claire étudie le mail et le retranscrit dans un ticket RM [2 minutes de charge]
• Le CP redirige le ticket vers le dev, qui traite et répond
• Le dev se rend compte qu’il lui manque des infos sur le ticket ? Allez hop, un aller-retour gratuit.
• Claire lit la réponse et vérifie auprès d’Antoine si la correction lui convient [10 minutes de charge]
• Ouf, ticket clos.

En fait, Freshdesk permet de nous affranchir de Claire dans ce cas. Et éviter que son rôle ne se résume à copier un mail dans un ticket Redmine et copier un ticket Redmine dans un mail. Parce que, vous en conviendrez, on a tous autre chose à faire que des photocopies.

Dans le circuit ci-dessus, ça nous fait 15 minutes de charge et (au moins) 2 heures de délai de gagnées. Sur un projet où 100 tickets sont remontés par an, ça nous fait donc 15*100/60 = 25 heures de gagnées soit près d’une semaine de travail. C’est une fourchette basse.

Allez voir votre client et expliquez-lui que vous allez permettre à tous ses utilisateurs de remonter des bugs en lui épargnant 25 heures de travail, a priori l’accueil ne devrait pas être trop froid.

Vous me direz… “Oui mais les utilisateurs vont déposer n’importe quoi comme ticket”. Eh bien bizarrement, non. Pourquoi ? Parce que je crois que le fait de saisir soi-même le ticket responsabilise (plutôt que d’envoyer un mail à Claire en se disant in petto “chacun sa merde”). Mais il suffit de mettre en place un pilote pour le vérifier.

Développeur != Client

Le développeur, son boulot, c’est d’abattre du ticket. Alors Freshdesk, c’est pas trop son truc. Déjà que Redmine… Oui mais voilà : Freshdesk s’intègre parfaitement bien avec Github. Et le plugin permet d’associer à un ticket Freshdeck un ticket Github qui vont mutuellement se mettre à jour. Le ticket est créé depuis Freshdesk avec la possibilité de saisir :

• Le dépôt
• Un autre titre (si besoin)
• Une milestone

Et le ticket Github reprend les méta (navigateur, timestamp, …) du ticket Freshdeck. Cas général : un clic et le ticket est créé. Pas de recopie à faire !

Côté developpeur, le principal “frein” que j’ai rencontré à l’adoption, c’est “oui mais on ne veut pas que le client voit nos remarques internes”. C’est un réflexe technique fréquent, qui explique certainement aussi pourquoi LA place dans l’open-space qui n’a pas l’écran qui donne sur la porte d’entrée est la plus convoitée

La petite option magique “Visible pour le client” !

Eh bien c’est-fait-pour. Les remarques de Github sont remontées (ou pas, ça se configure) en privé sur le ticket Freshdesk. L’état de cloture du ticket aussi (pratique pour le suivi). Et on a une indépendance si on le souhaite entre le besoin du client (Freshdesk) et celui du dev. Et rien n’empêche non-plus le lead dev d’être directement sur Freshdesk.

La magie du helpdesk

Partant de là, votre équipe de développement devient… un helpdesk. Avec tout ce que ça implique :

• Suivi de SLA par équipe, par criticité, par niveau de ticket…
• Statistiques détaillées
• Tableau de bord (siiiiimple) partagé avec le client
• Et cerise sur le gateau, le tout avec une configuration minimale

Oh, et j’oubliais, la possibilité de brancher TeamViewer à Freshdesk pour prendre la main sur un poste client si besoin.

Oh, et j’allais oublier aussi, la configuration avancée de Freshdesk qui permet de faire passer les tickets à travers des workflows plus ou moins avancés (si type = xxx, alors assigner à telle ou telle équipe).

Bref, un régal, et un gain de productivité incroyable côté client. Le gain est moins flagrant côté développeur, mais d’une part il existe et d’autre part il n’y a pas de friction avec les outils habituels des devs.

Ajoutons à cela de vrais retours utilisateurs qui, sans cette interface conviviale, auraient été perdus dans les process. Nous avons eu comme ça des retours sur des points d’ergonomie de la part des utilisateurs. Ou des points d’amélioration mineurs (qui ne nécessitaient pas de dev de notre côté) que le client aurait sans doute reporté mais que nous avons pu traiter au fil de l’eau. Satisfaction client au top.

Enfin, dernière petite anecdote : depuis que nous avons mis le widget Freshdesk sur les sites de certains de nos clients, nous n’avons plus de ticket qui remonte avec un titre “URGENT”, tout du moins cela arrive nettement moins qu’avant. Je ne me l’explique pas encore, mais c’est fort agréable !

Et vous ? Comment faites-vous pour gérer l’interface entre vos clients et vos développeurs ?