Les développeurs seraient-ils les meilleurs Customer Success ?

Contexte du projet

Depuis 1 an et demi, je travaille en tant que Product Owner sur une plateforme web qui permet à des entreprises de souscrire en 7 jours, un prêt bancaire 100% en ligne.

Notre équipe de 5 personnes (3 développeurs, 1 lead tech, 1 Product) est en charge de continuer à améliorer la plateforme avec de nouvelles fonctionnalités, et d'en assurer le support technique.

Après avoir réussi à stabiliser à un faible niveau les demandes de support (voir mon précédent article), nous avons créé un système pour prendre en compte les retours utilisateurs venant du support technique

1/ Analyser les demandes de supports a permis à toute l'équipe d'être acteur de l'amélioration de notre produit

Le support de la plateforme est organisé en 3 niveaux :

• Le premier accompagne l'utilisateur dans sa demande de prêt
• Le second répond aux questions métiers spécifiques
• Le troisième, notre équipe est en charge du support technique

Durant 6 mois, chaque jour, un développeur répondait aux demandes de support technique. Cela nous a permis 3 choses :

• Comprendre directement les points durs des utilisateurs. Améliorations produits : Dans un premier temps le support niveau 1 et 2 nous renvoyait des demandes suite à une incompréhension d'un utilisateur. Par exemple : "L'utilisateur ne comprends pas pourquoi son IBAN n'est pas reconnu" Problème : Il est écrit IBAN alors qu'on veut l'IBAN de l'entreprise. Solution simple : Nous avons changé le wording pour mettre IBAN de l'entreprise.
• Comprendre et résoudre les bugs utilisateurs : Le fait de récupérer directement la demande utilisateur permettait au développeur d'investiguer le problème, et de le qualifier afin de comprendre s'il s'agit ou non d'un bug. Par exemple : Un utilisateur nous indique ne pas avoir de nouvelles de son dossier. En effet, les documents que l'on envoie via API à notre partenaire pour vérification n'étaient pas arrivés correctement. Nous avons donc échangé avec notre partenaire afin de s'assurer que les documents arrivent toujours correctement.
• Avoir une équipe de missionnaire : Dans le livre inspired, Marty Cagan nous dit : "we need teams of missionaries, not teams of mercenaries". Ce que nous dit Marty Cagan est qu'il est important que l'équipe de développement soit portée par la vision produit et de l'équipe. Or le fait que l'équipe réponde aux utilisateurs l'a rendu sensible aux besoins de ces derniers. Ils ont donc identifié ce que l'on pourrait modifier rapidement qui améliorerait significativement l'expérience utilisateur. Par exemple : Les développeurs ont proposé d'ajouter un tooltip pour rediriger un utilisateur qui essaye de recréer un compte avec une adresse mail qu'il a déjà utilisée.

2/ L'analyse des pièces nous a permis de comprendre les points durs des utilisateurs

Chez Theodo, nous nous inspirons du Lean, et plus précisément nous utilisons la démarche Kaizen pour mettre en place de l'amélioration continue.

C'est ce que nous avons fait pour recenser les demandes de support : Nous avons qualifié les retours utilisateurs en établissant un langage commun à toute l'équipe, très visuel, et facilement lisible par quelqu'un d'extérieur.

Pour cela étant donné que nous étions plusieurs à travailler sur le support, nous avons mis en place un template avec le flux utilisateur. Nous le remplissons rapidement à chaque demande de support et il suffit donc de :

• Déplacer la croix pour indiquer ou se trouve le problème dans notre flux
• Ecrire le numéro de la demande pour pouvoir la retrouver
• Décrire simplement le problème
• Ecrire la cause racine identifiée

3/ Nous avons construit une matrice pour identifier des solutions à nos problèmes récurrents et les prioriser

Au bout de 3 semaines nous avons récupéré plus de 300 pièces.

Dans un premier temps nous avons recensé chaque semaine les rootcauses les plus récurrentes (une API qui était souvent down, une BDD qui n'était pas fiable, des documents qui ne s'envoyaient pas ...) et le nombre d'occurrences.

Dans un deuxième temps Othmane El Beghiti architecte développeur a alors eu l'idée de créer une matrice qui nous permettrait de prioriser les features à mettre en place afin :

• D'améliorer l'expérience utilsateur
• De faire gagner du temps à l'équipe de développement

Pour faire cela, il a pris en compte 3 paramètres :

• Le temps passé pour résoudre le type de problème analysé (Perte de temps de l'équipe de développement)
• L'occurence du problème (Point dur pour l'utilisateur)
• Le temps de résolution approximatif si l'on fait un développement qui empêcherait ce problème.

Grâce à cette matrice, nous avons été capables de classer les améliorations proposées par leur ROI. Nous avons ensuite mis en regard ce ROI, et l'impact utilisateur afin de prioriser dans notre roadmap les features les plus intéressantes.

Par exemple: 8.3% des demandes n'étaient pas traitées à cause d'un format de documents. Cela ne correspondait pas au plus grand nombre de demandes, mais pour le solutionner nous avons une solution qui prend 0.5 JH donc nous l'embarquons rapidement pour résoudre le problème.

Conclusion

Votre équipe passe trop de temps à débloquer les petits problèmes techniques de vos utilisateurs ? N'hésitez pas à les impliquer pour rationaliser le temps perdu, et trouver les développements qui permettront de réduire ce temps à 0.