Jacob Bank s’y connaît en e-mail. Ancien chef de produit chez Gmail, il a vu ce qui se passe quand on conçoit des outils d’e-mail pour 2,5 milliards de personnes. Mais pour organiser le support de sa startup d’IA, Relay.app, il lui fallait quelque chose que Gmail n’avait pas : des fonctionnalités d’équipe poussées et spécialisées, pour une équipe de neuf personnes qui traite des centaines de demandes de support.
Le défi : les limites des groupes Gmail face à la croissance
Comme beaucoup de petites équipes, Relay.app a commencé simplement. L’équipe utilisait un groupe Google, support@relay.app, et chaque membre recevait tous les e-mails de support dans sa boîte de réception personnelle. Certains appliquaient des filtres, d’autres non. C’était du système D, mais ça fonctionnait… jusqu’au jour où ça n’a plus fonctionné.
Les problèmes se sont accumulés plus vite qu’il n’en faut pour cliquer sur « Répondre à tous » :
- Le problème des collisions : Avec une équipe motivée qui tenait vraiment à aider les utilisateurs, il arrivait souvent que trois personnes répondent au même e-mail en même temps. « Ça faisait un peu bête, de façon presque attendrissante, du genre « regardez comme ils sont attentionnés », mais c’était surtout des efforts gaspillés, et ça nous donnait l’air bête. »
- Le problème du contexte : Les e-mails de support étaient noyés parmi les e-mails professionnels habituels, et il était difficile de se mettre dans le bon état d’esprit pour aider les clients.
- Le problème de la collaboration : Quand l’équipe devait discuter en interne d’un cas de support délicat avant de répondre, elle essayait de transférer les e-mails dans Slack ou de créer des fils parallèles dans Gmail. « Ces deux approches étaient très laborieuses et ne fonctionnaient pas vraiment. »
Pourquoi l’e-mail (et pas le chat en direct)
Bien qu’issue du monde de la tech, l’équipe de Jacob tenait absolument à garder l’e-mail pour le support. Ses raisons étaient d’un pragmatisme rafraîchissant :
- Accessible à tous : « L’e-mail était, et reste, un moyen de communication très largement répandu auquel tout le monde peut participer. Certains auraient préféré Slack. D’autres auraient préféré WhatsApp. Mais l’e-mail fonctionne pour tout le monde. »
- Des conversations naturelles : Contrairement aux formulaires de support qui donnent l’impression de… eh bien, remplir un formulaire, l’e-mail donne l’impression de parler à une vraie personne.
- Asynchrone par défaut : « Nous sommes une équipe de neuf personnes qui accompagne une base d’utilisateurs assez importante. Nous essayons de répondre à tout le monde sous 24 heures, mais nous ne pouvions pas mobiliser du personnel pour des conversations en direct. »
Ils avaient d’ailleurs essayé ces widgets de chat en direct au début. « Ça ne fonctionnait tout simplement pas pour nous. Nous n’avions pas les ressources pour assurer le support de cette façon. »
À la recherche d’un outil
Après avoir décidé qu’il leur fallait un outil dédié, Jacob a réduit la liste à deux candidats : le plus gros acteur du marché des boîtes de réception partagées, et Missive. Les deux offraient une expérience produit solide, mais Missive l’a emporté pour deux raisons essentielles :
- Les recommandations de la communauté : « Nos utilisateurs nous l’ont davantage recommandé, en nous disant qu’ils l’appréciaient vraiment. »
- Une philosophie commune : « Nous avions le sentiment que Missive était plus en phase avec notre façon de gérer l’entreprise. C’était une autre petite équipe, avec un produit qui se diffuse par le bouche-à-oreille, un support client de très grande qualité, et la conviction que l’e-mail est un vrai canal. »
La mise en place : une touche personnelle à grande échelle
La configuration de Missive chez Relay.app reflète sa conviction que le support doit rester humain :
- Un alias personnel pour chacun : Au lieu que tout parte de « support@relay.app », chaque membre de l’équipe a son propre alias. Quand Jacob répond, l’expéditeur affiché est « Jacob Bank », avec support@relay.app comme adresse e-mail. « Comme ça, on sait qu’il y a un vrai humain qui a envoyé ce message et qui échange avec nous. »
- Une responsabilité partagée : En tant que fondateur et PDG, Jacob traite sans doute plus de tickets de support que quiconque, mais chaque ingénieur, chaque membre de l’équipe produit et chaque designer fait aussi du support. « Nous confions le ticket à quelqu’un qui a l’expertise adéquate, mais nous voulons aussi que ça ressemble à une vraie conversation avec une vraie personne. »
- Une couverture par roulement : Quatre personnes assurent le support de première ligne à tour de rôle chaque jour, ce qui garantit des réponses rapides sans épuiser l’équipe.
L’ingrédient secret : le suivi automatisé des bugs et des demandes de fonctionnalités
C’est là que ça devient vraiment intéressant. Relay.app a créé des flux de travail sophistiqués qui transforment automatiquement les conversations de support en améliorations du produit.
Quand un membre de l’équipe repère un bug pendant une conversation de support, il lui suffit de taper « file a bug », suivi d’une description, dans le chat interne. Cela déclenche toute une série d’automatisations :
- Création automatique des bugs : Le flux de travail récupère tout le contexte de l’e-mail, utilise l’IA pour rédiger un résumé du problème en bonne et due forme, consulte un tableur des personnes d’astreinte pour l’assignation, puis crée un ticket dans Linear.
- Un lien dans les deux sens : Le bug Linear contient un lien vers la conversation Missive, et Missive reçoit un commentaire avec le lien vers le bug Linear. « C’est vraiment important pour nous de conserver ce lien dans les deux sens. »
- Un suivi automatique : Quand l’ingénieur corrige le bug et le marque comme terminé, le fil Missive revient automatiquement dans la boîte d’équipe, avec une note pour boucler la boucle avec le client.
Le même processus fonctionne pour les demandes de fonctionnalités avec la commande « FR », suivie d’une description. Voici une vidéo qui montre ce flux de travail IA.
Les résultats : le support comme moteur d’amélioration du produit
L’approche à contre-courant de Jacob, qui voit chaque ticket comme une occasion d’améliorer le produit plutôt que comme un coût à réduire, a porté ses fruits de façon spectaculaire.
« Le nombre absolu de tickets de support que nous recevons chaque semaine n’a pas changé depuis un an, alors que notre base d’utilisateurs a beaucoup augmenté sur la même période. Le nombre de tickets par utilisateur a donc fortement baissé. »
Le secret ? « Si vous voyez chaque ticket de support comme une occasion d’améliorer le produit, votre produit deviendra bien meilleur et les tickets de support diminueront même en proportion du nombre d’utilisateurs. »
Les fonctionnalités qui font la différence
- Les fils internes : « C’est la fonctionnalité que j’adore : on peut discuter en interne avant de répondre. Je peux écrire « @Ty, tu en penses quoi avant que je réponde ? ». Et on a plein de conversations en aparté comme ça. »
- La fusion de fils : « La fusion de fils est super pratique. Les gens écrivent souvent quatre e-mails d’affilée pour dire la même chose parce qu’ils sont frustrés… et on peut tous les fusionner en un seul fil dans l’interface de Missive pour avoir tout le contexte au même endroit. C’était impossible à faire dans Gmail. »
- Règles et automatisations : Leurs règles personnalisées détectent les commandes « file a bug » et « FR » pour déclencher des webhooks qui créent automatiquement des tickets Linear.
- Assignation et mise en attente : Quand quelqu’un doit parler précisément à Jacob, le ticket lui est assigné. Un week-end prolongé ? Tout est mis en attente jusqu’au mardi suivant.
En résumé
Pour une équipe de neuf personnes qui accompagne une base d’utilisateurs en pleine croissance, Missive est devenu l’arme secrète qui permet à Relay.app d’offrir un support digne d’une grande entreprise, sans les effectifs qui vont avec.
« Nous ne voulions pas d’une de ces interfaces où l’on reçoit des tonnes de texte standardisé… On n’a pas l’impression de discuter avec une personne. On a l’impression de discuter avec une machine. »