NevaBridge n'a pas commencé comme un produit. Il est né de notre propre problème : des milliers de rapports de bug vagues sur une plateforme que nous exploitons nous-mêmes. Nous avons donc construit la couche qui pose les bonnes questions avant qu'un ticket ne parvienne à un développeur.
L'équipe derrière NevaBridge exploite également Calendall, un système populaire de gestion clients et de prise de rendez-vous pour les salons. Chaque semaine, les demandes des clients arrivaient par e-mail, chat et tickets de support : questions, idées de fonctionnalités et rapports de bugs. Chacune devait être lue, comprise et acheminée vers la bonne personne. Et lorsqu'il s'agissait d'un rapport de bug ? Nos développeurs devaient presque toujours revenir poser des questions. Quel navigateur ? Quel écran ? Qu'avez-vous cliqué exactement avant que cela ne fonctionne plus ?
Les signalements n'étaient pas mauvais. Ils étaient simplement incomplets. Et chaque question de suivi coûtait du temps, du contexte et des nerfs des deux côtés. Nous l'avons mesuré : 44 % de tous les rapports de bugs nécessitaient au moins un échange de clarification avant qu'un développeur ne puisse seulement commencer. Certains en demandaient trois ou quatre.
Nous avons cherché un outil qui résout ce problème à la source. Un workflow qui pose les bonnes questions avant que le ticket n'arrive chez le développeur. Nous n'en avons trouvé aucun.
Alors nous l'avons construit nous-mêmes. Ce qui a commencé comme un outil interne pour notre propre équipe de support est devenu NevaBridge.
des rapports de bugs nécessitaient au moins un échange avant qu'un développeur ne puisse commencer
de temps en plus jusqu'à la première résolution pour les signalements incomplets
Nous n'avons pas essayé de construire un produit. Nous avons essayé de résoudre notre propre problème concret. NevaBridge existe parce que personne d'autre ne l'avait résolu pour des équipes comme la nôtre.
Notre équipe fondatrice a construit et exploité la plateforme sur laquelle nous avons rencontré ce problème pour la première fois. Nous avons géré des milliers d'interactions de support, trié nous-mêmes des centaines de rapports de bug et subi les conséquences de tickets vagues. Nous n'avons pas découvert ce problème dans une étude de marché. Nous l'avons vécu semaine après semaine, pendant plusieurs années.
Lorsque nous avons commencé à développer NevaBridge, nous avons intégré un CTO qui connaissait le même schéma de l'autre côté. En tant qu'ingénieur logiciel senior chez AWS, il a passé des années à recevoir des rapports de bugs incomplets, même dans une entreprise dotée de certains des processus d'ingénierie les plus aboutis du secteur. Le problème ne nous était pas propre. Il était structurel.
Cette combinaison façonne NevaBridge. Un côté de l'équipe sait ce que signifie exploiter un produit, parler aux clients et protéger le support du bruit. L'autre côté sait ce dont un développeur a réellement besoin pour commencer à traiter un problème, et combien cela coûte cher lorsque cette information manque. Pas parce que poser une question prend longtemps, mais parce que chaque question de suivi est renvoyée, attend une réponse pendant des heures ou des jours, et entre-temps le développeur travaille depuis longtemps sur autre chose. NevaBridge naît à l'intersection de ces deux perspectives.
d'exploitation d'une plateforme SaaS avec de vrais utilisateurs et un vrai volume de support
de développement de logiciels d'entreprise, des startups au secteur public jusqu'à un poste d'ingénieur senior chez AWS.
Nous ne construisons pas à partir de la théorie. Nous construisons à partir de milliers de conversations réelles, de tickets réels et de frustration réelle des deux côtés du transfert.
NevaBridge est à ses débuts. Nous construisons le premier module : le signalement interne de bugs. Un membre de l'équipe décrit un problème en langage naturel. NevaBridge analyse les informations présentes, identifie ce qui manque, pose des questions de suivi ciblées et crée un ticket structuré, prêt pour le développement, dans votre outil de suivi.
Ce n'est pas un chatbot générique posé sur un formulaire. NevaBridge fonctionne à trois niveaux. Dès le départ, il sait déjà ce dont les développeurs ont généralement besoin dans un rapport de bug, un savoir bâti sur notre propre expérience de développement de produits, le travail avec nos clients pilotes et l'analyse d'outils de suivi open source. Au-delà, vous pouvez l'alimenter avec votre propre documentation produit et vos conversations passées sur les bugs, afin qu'il apprenne votre terminologie, vos fonctionnalités et vos problèmes connus. Et vous pouvez créer vos propres modèles de rapport aux côtés de notre modèle de départ éprouvé. NevaBridge choisit le bon pour chaque conversation.
C'est cette combinaison qui transforme une phrase vague en un ticket sur lequel un développeur peut commencer à travailler immédiatement, sans aucune question de suivi.
Nous commençons là où la douleur est la plus grande. Les rapports de bugs sont l'endroit où l'écart entre ce que disent les gens et ce dont les développeurs ont besoin est le plus large. Réussir cette première brique est la fondation de tout ce qui suivra.
Nous l'utilisons nous-mêmes, chaque jour. Et nous cherchons des équipes qui connaissent la même douleur.
module en production, délibérément resserré
question de suivi nécessaire lorsque NevaBridge rédige le ticket
Nous préférons livrer dès maintenant un module qui résout un vrai problème plutôt que faire attendre les équipes que les trois soient prêts.