Communiceren met de gebruiker klinkt als het meest voor de hand liggende onderdeel van IT-support, en juist daar gaat het bij de meeste helpdesks mis. Een advocaat die om 09:15 een ticket indient over een niet-werkende dictafoonkoppeling, hoort om 11:00 nog niks. Er wordt hard gewerkt aan zijn probleem. Alleen weet hij dat niet. En in die informatie-leegte ontstaat het probleem dat later in evaluatiegesprekken terugkomt: niet de storing zelf, maar het gevoel dat niemand meekeek.
De klacht die wij het vaakst horen van kantoren die overstappen van een generieke IT-partij naar een gespecialiseerde, gaat zelden over techniek. Het gaat over stilte. "Ik heb dinsdag iets gemeld en pas donderdag hoorde ik dat het opgelost was" is de zin die in evaluatiegesprekken keer op keer terugkomt. Niet omdat de vorige leverancier niet werkte, maar omdat de klant twee dagen in het ongewisse zat.
Voor een advocaat of notaris is dat een groter probleem dan voor de gemiddelde kantoormedewerker. Als de citrix-sessie hapert vijf minuten voor een zitting, of als het aktedossier niet opent op de dag van passeren, is "we bellen je terug" geen antwoord. De gebruiker heeft geen bevestiging nodig dat het probleem is aangekomen — die heeft hij al. Hij heeft bevestiging nodig dat er iemand mee bezig is, en een inschatting van wanneer hij weer verder kan. Zonder die twee dingen groeit het probleem in zijn hoofd sneller dan de engineer het kan oplossen.
Waarom communiceren met de gebruiker geen extra stap is, maar de kern
Wat in de praktijk werkt is een simpele regel die we intern hard hanteren: je kunt niet overcommuniceren met de gebruiker. Elk uur zonder statusupdate is een uur waarin de gebruiker zelf een verhaal gaat invullen. Meestal is dat verhaal negatiever dan de werkelijkheid. Er wordt achter de schermen keihard gewerkt, maar dat helpt de advocaat niks als hij het niet weet.
De verschuiving die kantoren merken bij een gespecialiseerde partner zit niet in snellere oplostijden — die verschillen minder dan je denkt. Ze zit in het contactmoment. Een korte terugkoppeling van drie zinnen ("we zijn ermee bezig, oorzaak lijkt X, verwachte oplossing binnen 45 minuten") schept rust waar een half uur wachtstand irritatie oplevert. Denk aan hoe je zelf reageert als je privé een telecomprovider belt en 30 minuten muziek hoort. Dat is exact het gevoel dat een advocaat krijgt bij twee dagen radiostilte over een openstaand ticket.
Wat we in 17 jaar hebben geleerd over communiceren met de gebruiker in de advocatuur
De advocatuur vereist meer communicatie dan een gemiddelde doelgroep. Dat is geen mening, dat is een observatie na 17 jaar werken voor kantoren van vijf tot honderdvijftig medewerkers. Een advocaat werkt in blokken van declarabele tijd. Een half uur onduidelijkheid over de status van een IT-issue is niet alleen een half uur ergernis — het is ook een half uur waarin hij niet weet of hij een cliëntafspraak moet verzetten of niet. Die onzekerheid is duurder dan de storing zelf.
Wat het extra ingewikkeld maakt: een advocaat kan zijn werk zelden parkeren. Als een boekhouder een half uur niet in zijn systeem kan, pakt hij koffie en gaat door. Een advocaat die om 10:00 een pleidooi moet houden en om 09:40 zijn dossier niet open krijgt, heeft geen alternatief. Hij moet weten of hij op zijn eigen laptop terug kan vallen, of hij een collega moet bellen, of hij de rechtbank moet informeren. Alle drie die keuzes hangen af van één ding: hoe lang het nog duurt. En dat is precies de informatie die hij niet krijgt als de helpdesk stil is.
De drie momenten waarop stilte altijd fout is
Er zijn drie momenten in een supportcyclus waarop stilte je vertrouwen kost, ongeacht hoe goed je engineers zijn. Het eerste is direct na de melding: bevestig binnen minuten dat het ticket is opgepakt en door wie. Het tweede is bij overdracht: als een tweedelijns-engineer het overneemt, moet de gebruiker dat weten voordat hij een onbekende naam ziet in zijn mailbox. Het derde is bij vertraging: zodra de oorspronkelijke inschatting niet meer klopt, hoort de gebruiker dat te weten vóór het moment dat hij zelf gaat bellen. Wie op deze drie momenten proactief is, houdt vertrouwen ook als de storing langer duurt dan verwacht.
Het derde moment is verreweg het lastigst, en ook het belangrijkst. Engineers hebben de neiging om een vertraging pas te melden als ze zelf zeker weten wat de nieuwe oplostijd is. Dat is menselijk — niemand meldt graag slecht nieuws met een slag om de arm — maar het is precies verkeerd om. De gebruiker heeft liever een tussenupdate met "het duurt langer dan gedacht, ik weet nog niet hoe lang, ik meld me over een half uur opnieuw" dan één uur extra stilte gevolgd door een definitief antwoord. Wachten op zekerheid is de meest voorkomende reden dat goede engineers slechte communicatie leveren.
De rekensom achter overcommunicatie
Een korte statusupdate kost een engineer 90 seconden. Een boze terugbelvraag van een partner die zich vergeten voelt kost gemiddeld 15 tot 20 minuten aan gesprek, plus de kosten van een aangetast vertrouwen dat maanden nawerkt. Iedere minuut die je bespaart door niet te communiceren, betaal je tienvoudig terug in escalatie. Dat is de reden dat wij liever een engineer hebben die drie keer per uur een korte update tikt dan een engineer die stil doorwerkt en na twee uur triomfantelijk meldt dat het opgelost is. De gebruiker heeft in die twee uur al besloten dat hij ontevreden is.
En dan hebben we het nog niet over het domino-effect binnen een kantoor. Eén partner die zich vergeten voelt, deelt dat op de gang met twee anderen. Bij de volgende maandagse partnervergadering komt IT als agendapunt terug, niet omdat de infrastructuur slecht is, maar omdat het gevoel is ontstaan dat "we er alleen voor staan". Dat gevoel repareer je niet met een nieuwe SLA. Dat repareer je alleen door structureel het contactritme aan te passen — en dat begint bij de engineer die zichzelf aanleert om te tikken vóórdat hij denkt dat hij iets te melden heeft.
Een IT-partner beoordelen op oplostijd is achterhaald. De echte maatstaf is hoe vaak de gebruiker binnen een lopende issue van jou hoort, en of die berichten iets toevoegen aan wat hij al weet. Kantoren die overstappen naar Xinno noemen dat contactritme vaker als reden dan de techniek eronder. De Modern Workplace-varianten die wij leveren draaien in Nederlandse datacenters, maar wat het verschil maakt in de dagelijkse praktijk zit in wie er belt als er iets hapert — en hoe snel.
