'Even vijf minuten' bestaat niet

"Het is toch maar een mailtje beantwoorden." "Even vijf minuten de klant bellen, dat kan Tom er wel bij nemen." Zo klinkt het meestal wanneer een technische klantvraag bij je ontwikkelaars terechtkomt. Mensen zien het als een kleinigheid, iets dat er tussendoor bij past.

Dat lijkt misschien zo. Hij kent het antwoord uit zijn hoofd. Het typen is in drie minuten gebeurd.

Die vijf minuten zijn geen vijf minuten

Chris Parnin onderzocht hoe programmeurs met onderbrekingen omgaan. Parnin analyseerde tienduizend programmeersessies van 86 ontwikkelaars, en telkens kwam hetzelfde beeld terug. Na een onderbreking duurt het tien tot vijftien minuten voor iemand weer code begint te schrijven. Dat komt niet omdat hij traag is. Het komt door de context. Hij had de details in zijn hoofd: welke functie openstond, en waar hij precies zat. Na de onderbreking is die context weg, en moet hij ze opnieuw opbouwen. In amper één op de tien gevallen pikte iemand de draad binnen de minuut weer op.

Dat mailtje kost hem dus geen drie minuten, maar twintig. Gebeurt dat een paar keer per dag, dan houdt hij op een volledige dag nog één blok van twee uur zonder onderbreking over. Ook dat cijfer komt van Parnin.

Dat onderzoek verscheen in de Software Quality Journal. Een heldere samenvatting schreef Parnin zelf in Programmer Interrupted.

Een routinevraag laten beantwoorden door een developer is niet duur omdat het antwoord moeilijk is. Het is duur omdat je hem weghaalt van het werk dat alleen hij kan doen.

Waarom die vraag toch bij je developer belandt

Het antwoord op een technische klantvraag zit zelden op een plek waar de klant of een collega het vindt. Het zit in de code, in een pull request van vorige maand, of in het hoofd van degene die de feature bouwde.

Een chatbot op je site lost dat niet op. Op een technisch product is zo'n bot zelfs riskant. Hij merkt niet altijd dat hij het antwoord niet kent, en dus verzint hij er een dat plausibel klinkt en fout is. Je klant volgt dat antwoord op, het werkt niet, en de vraag komt alsnog bij je developer terecht. Die moet nu ook het foute antwoord rechtzetten.

Een wiki of FAQ heeft een ander probleem. Die klopt op dag één. Vanaf dag twee veroudert ze. Een half jaar later beantwoordt ze vragen over een versie van je product die niet meer bestaat, en niemand op het team vertrouwt ze nog. Waarom documentatie veroudert en wat daar wél tegen helpt, schreven we uit in Hoe houd ik mijn kennisbank automatisch actueel?.

Eén betrouwbare weg blijft over: je vraagt het aan de persoon die het gebouwd heeft. En die weg werkt. De klant krijgt een correct antwoord, meestal snel. Daarom doet bijna elk softwarebedrijf het zo. Alleen is het de duurste manier om een vraag te beantwoorden. Parnins cijfers laten zien waarom.

Wat de beste manier wél is

De beste manier om technische klantvragen te automatiseren volgt één regel: een mens beantwoordt elke vraag maar één keer.

Een klant vraagt iets dat nergens staat. Je collega antwoordt zoals altijd. Maar dit keer verdwijnt dat antwoord niet. Het systeem legt het vast. De volgende klant met dezelfde vraag krijgt datzelfde antwoord meteen, in de woorden van je eigen mensen en niet met een gok. Twijfelt het systeem, dan raadt het niet. Dan escaleert het.

Die laatste stap maakt het verschil. Alleen een vraag die echt een developer nodig heeft, komt bij een developer terecht. En dan bij de júiste developer, met de context erbij, niet in een gedeelde inbox waar ze een halve dag blijft liggen. Zo verandert het werk van je ontwikkelaars. Ze beantwoorden geen vragen meer. Ze beantwoorden één vraag, de eerste keer, de moeilijke. De routinevragen bereiken hen niet meer.

Hoe dat bij Sarrai werkt

Sarrai antwoordt op basis van je eigen documentatie en toont de bron. Ze houdt ook bij hoe zeker ze van elk antwoord is. Kan ze een vraag niet beantwoorden, dan stelt ze je medewerker één vraag op het moment dat hij zijn antwoord verstuurt: mag hier een conceptartikel van komen? Hij klikt één keer, en de volgende klant met dezelfde vraag is geholpen. Niemand hoeft het antwoord nog te typen.

Alle voorstellen komen samen in één goedkeuringsinbox. Je ziet waar elk voorstel vandaan komt, welk gesprek de aanleiding was en wat er precies zou veranderen. Het opzoekwerk is gebeurd. De beslissing blijft bij jou. En een vraag die Sarrai niet aankan, stuurt ze naar de persoon die het wél weet, niet naar een algemene mailbox.

Hoe dat er voor een softwarebedrijf concreet uitziet, lees je op Sarrai voor softwarebedrijven.

Doe dit eerst

Je hebt Sarrai niet nodig om te beginnen meten. Vraag je ontwikkelaars deze week welke klantvragen bij hen terechtkomen. Zet bij elke vraag één ding: had dit écht een developer nodig, of kende iemand anders het antwoord ook? Alles in de tweede groep is werk dat je vandaag al kan wegnemen. Meestal is dat het grootste deel.

Een technische klantvraag automatiseren begint niet bij een tool. Het begint wanneer je één ding erkent: "even vijf minuten" van je developer is het duurste antwoord in huis.