Depuis 6 mois, 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 PO) est en charge du :
- Build : développer de nouvelles fonctionnalités pour améliorer l'expérience client et réduire le risque financier
- Run : résoudre les bugs qui impactent des utilisateurs
- Support technique : répondre aux clients qui rencontrent un problème technique
Nous avons développé la plateforme en 3 semaines seulement, à la demande du client. Nous avons relevé ce défi, mais notre MVP présente des bugs bloquants pour certains utilisateurs.
Au bout de 3 mois, nous sommes débordés par le support technique : 329 demandes sans réponses, 50 dossiers bloqués pour des raisons techniques inconnues, 10 mails par jour pour des dossiers urgents. La priorité de notre client est de réduire ce nombre de demandes, c'est pourquoi nous décidons de prioriser le support et le run.
Je vous partage dans cet article 3 idées clés qui nous ont permis de concilier build, run et support :
- Guider l'équipe vers un objectif clair
- Traiter les demandes entrantes via un seul canal de communication
- Avoir une démarche d'amélioration continue pour diminuer le nombre de bugs et donc de demandes entrantes.
#1 Guider l'équipe vers un objectif clair : 0 demandes de support en attente
L'équipe se fixe un objectif : 0 demandes de support en attente de réponse. Pour l'atteindre, nous avons distingué 3 phases :
Phase 1 :
Pour réduire le nombre de demandes en attente, nous avons mis en place 3 actions :
- Appel à 3 personnes extérieures à l'équipe qui nous ont aidées à répondre aux demandes,
- Mise en place d'un planning qui définit un référent support pour chaque demi-journée,
- Définition d'un objectif quotidien pour diminuer le nombre de demandes sans réponses. Nous avions pour objectif de traiter 25 demandes par jour mais grâce à cette organisation, nous avons dépassé nos objectifs.
Graphe correspondant au nombre d'utilisateurs ayant fait une demande de support en attente de réponse, en rouge notre objectif de stock à la fin de la journée.
.png?width=1160&name=Untitled%20(1).png)
Phase 2 :
- Nous avons conservé un planning de support mais nous avons alloué 50% du temps de l'équipe à des développements qui permettent de diminuer le nombre de demandes entrantes (run).
- Nous avons réduit l'aide externe à l'équipe à 1 personne à temps plein sur le support.
- Nous avons débloqué de façon proactive les dossiers qui rencontraient un problème technique même si le support n'a pas été sollicité.
Phase 3 :
- Une personne à temps plein se charge de façon quasi autonome du support technique et un développeur l'accompagne à raison d'une heure par jour.
- Nous débloquons en continu les dossiers rencontrant un problème technique.
- Nous allouons 20% de notre temps au support, 15% au run et les 65% restants au build.
#2 Imposer un unique canal de communication pour les demandes entrantes
Lorsque les entrepreneurs sont bloqués, ils envoient une demande au support métier. Puis, si le support métier ne sait pas débloquer le dossier, il nous transfère la demande. Ces demandes nous étaient transférées par mail, par slack, par téléphone, par whatsapp, par notre outil de gestion du support, par pigeon voyageur. Nous leur avons expliqué pourquoi il était indispensable de passer par un unique canal :
- Garder un objectif clair en ligne de mire (le stock de demandes)
- Etre sur de n'oublier aucune demande
- S'organiser en équipe pour se répartir les demandes.
L'utilisation de plusieurs canaux, était aussi un moyen pour eux de nous signifier qu'une demande était urgente. Nous avons donc qualifié ensemble ce qu'était une demande urgente, et avons trouvé un moyen de les prioriser directement dans notre outil de gestion de support.
#3 : Avoir une démarche d'amélioration continue pour diminuer notre run.
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.
Nous avions identifié notre principal élément de blocage pour les utilisateurs : certains documents que nous envoyons via API à un partenaire externe étaient bloqués, et le dossier ne pouvait pas être analysé.
Nous avons mis en place un Kaizen afin d'endiguer le problème. Nous nous sommes fixés trois objectifs :
- Diminuer le nombre d'incidents à cette étape.
- Traiter les dossiers bloqués en moins d'un jour.
- Avoir moins d'un dossier bloqué à cette étape par semaine.
Bonne nouvelle
Nous avons atteint notre objectif en 6 semaines grâce à trois éléments :
- Nous avons fait un pareto de causes (tacler en priorité les 20% des causes qui ont 80% des effets les plus impactants) : nous sommes donc partis des problèmes clients les plus récurrents.
- Nous avons pris le temps d'échanger en direct avec le partenaire pour creuser la cause des problèmes.
- Grâce à cette analyse de causes nous avons pu embarquer des tickets pour débugger les plus importantes. Cela a permis de diminuer le nombre d'incidents entrants.
Ce Kaizen représentait nos premiers apprentissages du "Run for Build".
Je vous présenterai dans un prochain article comment nous avons réussi à aller encore plus loin en apprenant à catégoriser les retours du support, et à prioriser les fonctionnalités à mettre en place.
Conclusion
Votre équipe est dépassée par le support client, et les utilisateurs de votre produit doivent être débloqués en urgence ? Commencez par concentrer votre énergie au déblocage de vos utilisateurs et à la résolution des bugs les plus importants, avant de vous consacrer aux bugs secondaires et au build.
Pour en savoir plus, n'hésitez pas à me contacter, je serais ravie d'échanger avec vous !
Mail : noemien@theodo.fr - Linkedin
