NevaBridge nezačal jako produkt. Začal jako naše vlastní bolest – tisíce vágních hlášení chyb na platformě, kterou sami provozujeme. Tak jsme postavili vrstvu, která klade správné otázky dřív, než tiket vůbec dorazí k vývojáři.
Tým za NevaBridge zároveň provozuje Calendall, oblíbený systém pro správu zákazníků a rezervaci termínů pro salony. Každý týden přicházely dotazy zákazníků e-mailem, chatem a v support tiketech: otázky, nápady na funkce a hlášení chyb. Každý bylo potřeba přečíst, pochopit a předat na správné místo. A když šlo o hlášení chyby? Naši vývojáři se skoro vždy museli doptávat. Jaký prohlížeč? Jaká obrazovka? Na co přesně jsi klikl, než to přestalo fungovat?
Hlášení nebyla špatná. Byla jen neúplná. A každé doptávání stálo čas, kontext a nervy na obou stranách. Změřili jsme to: 44 % všech hlášení chyb potřebovalo aspoň jedno kolo upřesnění, než vývojář vůbec mohl začít. Některá potřebovala tři nebo čtyři kola.
Hledali jsme nástroj, který tento problém řeší přímo u zdroje. Workflow, který položí správné otázky dřív, než tiket dorazí k vývojáři. Žádný jsme nenašli.
Tak jsme ho postavili sami. To, co začalo jako interní nástroj pro náš vlastní support tým, se stalo NevaBridge.
všech hlášení chyb potřebovalo aspoň jedno doptání, než mohl vývojář začít
delší doba do prvního vyřešení u neúplných hlášení
Nesnažili jsme se postavit produkt. Snažili jsme se vyřešit vlastní bolavé místo. NevaBridge existuje, protože tento problém pro týmy, jako jsme my, nikdo jiný nevyřešil.
Náš zakladatelský tým postavil a provozoval platformu, na které jsme tento problém poprvé zažili. Vyřídili jsme tisíce support interakcí, sami roztřídili stovky hlášení chyb a bolest vágních tiketů zažili na vlastní kůži. Tohle bolavé místo jsme nečetli v tržní zprávě. Žili jsme ho týdny, roky.
Když jsme začali vyvíjet NevaBridge, přivedli jsme do týmu CTO, který stejný vzorec znal z druhé strany. Jako Senior Software Engineer v AWS roky stál na přijímající straně neúplných hlášení chyb, a to i ve firmě s jedněmi z nejvyspělejších vývojových procesů v oboru. Ten problém nebyl jen náš. Byl strukturální.
Tahle kombinace utváří NevaBridge. Jedna strana týmu ví, co znamená provozovat produkt, mluvit se zákazníky a chránit support před šumem. Druhá strana ví, co vývojář opravdu potřebuje, aby mohl začít s issue – a jak drahé je, když tyto informace chybí. Ne proto, že by doptávání trvalo dlouho, ale protože každá doplňující otázka se pošle zpět, čeká hodiny nebo dny na odpověď, a vývojář mezitím dávno dělá něco jiného. NevaBridge vzniká na rozhraní obou perspektiv.
provozu SaaS platformy se skutečnými uživateli a skutečným objemem supportu
vývoje enterprise softwaru, od startupů přes veřejný sektor až po roli Senior Engineera v AWS.
Nestavíme z teorie. Stavíme z tisíců skutečných konverzací, skutečných tiketů a skutečné frustrace na obou stranách předávky.
NevaBridge je v rané fázi. Stavíme první modul: interní hlášení chyb. Člen týmu popíše problém přirozeným jazykem. NevaBridge analyzuje, co je k dispozici, rozpozná, co chybí, klade cílené doplňující otázky a vytvoří strukturovaný tiket připravený pro vývojáře ve vašem issue trackeru.
Není to generický chatbot nasazený na formulář. NevaBridge funguje na třech úrovních. Hned od začátku ví, co vývojáři v hlášení chyby obvykle potřebují – postaveno na naší vlastní zkušenosti s vývojem produktů, prací s pilotními zákazníky a analýzou open-source issue trackerů. Navíc ho můžete krmit vlastní produktovou dokumentací a minulými konverzacemi o chybách, aby se naučil vaši terminologii, vaše funkce a vaše známé issues. A můžete vytvářet vlastní šablony hlášení vedle naší osvědčené výchozí šablony. NevaBridge pro každou konverzaci vybere tu vhodnou.
Právě tahle kombinace promění vágní větu v tiket, na kterém může vývojář okamžitě pracovat – bez jediné doplňující otázky.
Začínáme tam, kde je bolest největší. Hlášení chyb jsou místem, kde je mezera mezi tím, co lidé říkají, a tím, co vývojáři potřebují, největší. Udělat tuhle jednu věc správně je základem pro všechno, co bude následovat.
Používáme to sami, každý den. A hledáme týmy, které znají stejnou bolest.
modul v produkci, záměrně úzce vymezený
doplňujících otázek, když tiket píše NevaBridge
Raději teď dodáme jeden modul, který řeší skutečný problém, než abychom týmy nechali čekat, až budou hotové všechny tři.