NevaBridge non è nato come prodotto. È nato da un problema che vivevamo in prima persona: migliaia di bug report vaghi su una piattaforma che gestiamo noi stessi. Così abbiamo costruito il livello che pone le domande giuste prima che un ticket arrivi a uno sviluppatore.
Il team dietro NevaBridge gestisce anche Calendall, un popolare sistema di gestione clienti e prenotazione appuntamenti per saloni. Ogni settimana arrivavano richieste dei clienti via e-mail, chat e ticket di supporto: domande, idee per nuove feature e bug report. Ognuna doveva essere letta, compresa e instradata al posto giusto. E quando si trattava di un bug report? I nostri sviluppatori dovevano quasi sempre tornare indietro a chiedere. Quale browser? Quale schermo? Cosa hai cliccato esattamente prima che smettesse di funzionare?
Le segnalazioni non erano sbagliate. Erano semplicemente incomplete. E ogni domanda di chiarimento costava tempo, contesto e nervi su entrambi i lati. L'abbiamo misurato: il 44% di tutti i bug report richiedeva almeno un giro di chiarimenti prima che uno sviluppatore potesse anche solo iniziare. Alcuni ne richiedevano tre o quattro.
Abbiamo cercato uno strumento che risolvesse questo problema alla radice. Un workflow che ponesse le domande giuste prima che il ticket arrivasse allo sviluppatore. Non ne abbiamo trovato nessuno.
Così l'abbiamo costruito noi. Quello che era nato come strumento interno per il nostro team di supporto è diventato NevaBridge.
dei bug report richiedeva almeno un chiarimento prima che uno sviluppatore potesse iniziare
di tempo in più fino alla prima risoluzione con segnalazioni incomplete
Non abbiamo provato a costruire un prodotto. Abbiamo provato a risolvere il nostro pain point. NevaBridge esiste perché nessun altro ha risolto questo problema per team come il nostro.
Il nostro team fondatore ha costruito e gestito la piattaforma su cui abbiamo incontrato questo problema per la prima volta. Abbiamo gestito migliaia di interazioni di supporto, classificato centinaia di bug report e sperimentato direttamente le conseguenze dei ticket vaghi. Non abbiamo scoperto questo problema in un report di mercato. L'abbiamo vissuto settimana dopo settimana, per anni.
Quando abbiamo iniziato a sviluppare NevaBridge, abbiamo coinvolto un CTO che conosceva lo stesso pattern dall'altro lato. Come Senior Software Engineer in AWS, aveva passato anni dal lato di chi riceve bug report incompleti, anche in un'azienda con alcuni dei processi di engineering più maturi del settore. Il problema non era solo nostro. Era strutturale.
Questa combinazione plasma NevaBridge. Un lato del team sa cosa significhi gestire un prodotto, parlare con i clienti e proteggere il supporto dal rumore. L'altro lato sa di cosa ha davvero bisogno uno sviluppatore per iniziare a lavorare su un'issue, e quanto costa quando quell'informazione manca. Non perché chiedere richieda molto tempo, ma perché ogni domanda di chiarimento viene rimandata indietro, aspetta una risposta per ore o giorni, e nel frattempo lo sviluppatore sta già lavorando da tempo su qualcos'altro. NevaBridge nasce all'incrocio di entrambe le prospettive.
di gestione di una piattaforma SaaS con utenti reali e volume di supporto reale
di sviluppo di software enterprise, dalle startup al settore pubblico fino al ruolo di Senior Engineer in AWS.
Non costruiamo a partire dalla teoria. Costruiamo a partire da migliaia di conversazioni reali, ticket reali e frustrazione reale su entrambi i lati del passaggio di consegne.
NevaBridge è agli inizi. Stiamo costruendo il primo modulo: il bug reporting interno. Un membro del team descrive un problema in linguaggio naturale. NevaBridge analizza ciò che c'è, riconosce ciò che manca, pone domande di chiarimento mirate e crea un ticket strutturato e pronto per gli sviluppatori nel vostro issue tracker.
Non è un chatbot generico montato su un form. NevaBridge lavora su tre livelli. Già di default sa cosa serve tipicamente a uno sviluppatore in un bug report, costruito sulla nostra esperienza nello sviluppo di prodotti, sul lavoro con i clienti pilota e sull'analisi di issue tracker open source. Oltre a questo, potete alimentarlo con la vostra documentazione di prodotto e con le conversazioni passate sui bug, in modo che impari la vostra terminologia, le vostre feature e le issue note. E potete creare i vostri template di report accanto al nostro template di partenza già rodato. NevaBridge sceglie quello giusto per ogni conversazione.
È questa combinazione che trasforma una frase vaga in un ticket su cui uno sviluppatore può iniziare a lavorare subito, senza un solo chiarimento.
Partiamo dal problema più urgente. Nei bug report il divario tra ciò che le persone dicono e ciò di cui gli sviluppatori hanno bisogno è particolarmente ampio. Risolvere bene questo primo problema è la base di tutto ciò che seguirà.
Lo usiamo noi stessi, ogni giorno. E stiamo cercando team che conoscano lo stesso problema.
modulo in produzione, tenuto volutamente stretto
chiarimenti necessari quando è NevaBridge a scrivere il ticket
Preferiamo rilasciare ora un modulo che risolve un problema reale, piuttosto che far aspettare i team finché tutti e tre non sono pronti.