Helpdesk- en servicedesk-apps: de volledige gids

Vrijwel elke organisatie met klanten of interne gebruikers heeft een plek waar vragen, storingen en verzoeken binnenkomen. In het begin is dat een gedeelde mailbox, een telefoonnummer en een collega die toevallig weet hoe het zit. Dat werkt tot het aantal meldingen groeit. Dan blijkt niemand meer te weten welke vraag al beantwoord is, wie eraan werkt, welke melding het langst ligt en welke storing vandaag al drie keer is gemeld. Een mailbox laat berichten zien, maar geen werkvoorraad, en zeker geen afspraken over wat wanneer af moet zijn.

Een helpdesk- of servicedesk-app maakt van die stroom berichten een geordend proces. Elke melding wordt een ticket met een eigenaar, een status, een prioriteit en een leesbare geschiedenis. Meldingen uit mail, telefoon, een klantportaal en chat komen in dezelfde wachtrij terecht, zodat het niet uitmaakt via welk kanaal iemand aanklopt. Rond die wachtrij liggen afspraken: welke melding gaat voor, wanneer iemand uiterlijk iets hoort, wanneer een melding naar een ander team gaat en wie dan aan zet is. De app dwingt die afspraken af en laat zien wanneer ze niet gehaald worden.

Het verschil tussen een helpdesk en een servicedesk is gradueel. Een helpdesk beantwoordt vragen en verhelpt storingen. Een servicedesk is daarnaast het enige aanspreekpunt voor een hele dienstverlening en behandelt ook aanvragen, wijzigingen en terugkerende problemen. Dezelfde app kan beide bedienen, mits u vooraf kiest welk werk erin thuishoort en welk werk elders blijft. In deze gids ziet u de app als het organiserende geheugen van uw ondersteuning: hij bewaakt het proces en de historie, terwijl de inhoudelijke oplossing van uw mensen komt.

Een servicedesk verzamelt bijna per definitie persoons­gegevens: naam en contactgegevens van de melder, wat hij vroeg, wat u antwoordde en soms bijlagen met veel meer dan dat. Daarmee geldt de AVG onverkort. U hebt een grondslag nodig, u legt alleen vast wat u voor de afhandeling nodig hebt en u spreekt bewaartermijnen af. De Autoriteit Persoons­gegevens zet uiteen dat verwerken alleen mag op een van de zes grondslagen uit de AVG. Let bij een servicedesk vooral op de vrije tekstvelden: daar belandt in de praktijk het meeste dat er niet had hoeven staan.

Neemt u telefo­ongesp­rekken op, dan komt er een informatie­plicht bij. De Europese privacytoezicht­houders schrijven in hun gids voor kleine ondernemingen dat u bellers bij aanvang moet vertellen waarvoor u opneemt, wie de opnames ontvangt, en dat zij bezwaar kunnen maken en de opname kunnen inzien. Lekken meldingen of opnames toch uit, dan geldt de meldplicht datalekken: een datalek met risico voor betrokkenen meldt u binnen 72 uur bij de Autoriteit Persoons­gegevens. Uw servicedesk is bovendien vaak het loket waar zo'n lek als eerste binnenkomt, dus dat pad hoort in de app te zitten.

Voor de inrichting van het proces zelf bestaat een internationale norm. NEN-ISO/IEC 20000-1 beschrijft de eisen aan een service­management­systeem: hoe u diensten ontwerpt, levert, bewaakt en verbetert. Certificering is mogelijk, maar ook zonder certificaat is de norm bruikbaar als checklist voor wat u geregeld moet hebben. Daarnaast is ITIL een veelgebruikt raamwerk dat dezelfde begrippen hanteert, zoals incident, probleem en wijziging. Kies één vocabulaire en houd het vol. Het grootste verwarrings­risico in een servicedesk is dat drie teams hetzelfde woord anders gebruiken.

Welke functies u nodig hebt, hangt af van het volume, het aantal kanalen en de afspraken die u met klanten of collega's hebt. De zes onderdelen hieronder vormen samen het hart van een volwaardige servicedesk. Begin niet met alles tegelijk, maar met het onderdeel dat vandaag het meeste zoekwerk kost. Dat is bijna nooit het rapportagedeel en bijna altijd de wachtrij.

Een melding doorloopt in vrijwel elke organisatie dezelfde route. Het loont die route hardop uit te spreken voordat u laat bouwen, omdat elke stap eigen schermen, rechten en randgevallen meebrengt. Wie de route overslaat, krijgt een app die alleen het makkelijke deel van het werk ondersteunt. Loop hem eerst met uw eigen team langs, met een paar recente meldingen in de hand, en let op de overgangen: van kanaal naar wachtrij, van eerste lijn naar specialist, en van opgelost naar afgesloten. Daar gaat de meeste tijd verloren.

Het begint bij de aanmelding. Iemand mailt, belt, vult een formulier in of stelt een vraag in de chat. De app maakt daar één ticket van, koppelt het aan de juiste klant of medewerker en haalt op wat al bekend is, zodat de melder zijn gegevens niet opnieuw hoeft te geven. Daarna volgt de triage: klopt de categorie, hoe urgent is het, gaat het om een storing, een vraag of een aanvraag, en hoort dit bij de eerste lijn of meteen bij een specialist. Bij die triage valt de meeste tijd te winnen en te verliezen.

Vervolgens draait het om de behandeling. Eén eigenaar werkt aan het ticket, legt vast wat hij heeft geprobeerd en houdt de melder op de hoogte. Loopt de klok richting de afgesproken norm of ontbreekt de kennis, dan volgt escalatie: het ticket gaat naar een andere groep of een hoger niveau, met de geschiedenis erbij. Wacht u op de melder zelf, dan hoort de klok stil te staan, anders meet u de wachttijd van uw klant als uw eigen doorlooptijd. Bij de afsluiting koppelt u terug wat de oorzaak was en wat de oplossing is.

De laatste stap wordt het vaakst overgeslagen: terugkijken. Drie meldingen over dezelfde haperende printer zijn drie incidenten, maar samen één probleem. Een servicedesk die alleen tickets afvinkt, blijft dezelfde tickets krijgen. Door herhaa­lmeldingen te groeperen, oorzaken vast te leggen en de antwoorden die u vaak typt naar de kennisbank te verplaatsen, daalt de instroom. Dat is meestal de grootste winst van zo'n app: niet sneller antwoorden op dezelfde vraag, maar die vraag minder vaak krijgen.

Een servicedesk staat zelden op zichzelf. Wat hem bruikbaar maakt, is dat uw mensen niet van scherm hoeven te wisselen om te weten wie er belt, wat die klant afneemt en wat er vorige maand is afgesproken. Bepaal daarom vooraf welke koppelingen u nodig hebt, want ze bepalen de architectuur mede en ze zijn achteraf lastig in te voegen. Een bruikbare toets is welke schermen een behandelaar vandaag naast elkaar open heeft staan. Die schermen vormen samen uw koppel­ingenlijst, en meestal is die korter dan gevreesd.

De belangrijkste is meestal de koppeling met uw CRM of ERP. Daar staan klanten, contactpersonen, contracten, abonnementen, installaties en soms de geleverde artikelen. Een ticket dat aan die gegevens hangt, laat direct zien of iemand recht heeft op ondersteuning en met welke servicenorm. Vaak is het verstandig één systeem leidend te maken voor klantgegevens en de servicedesk te laten meelezen, in plaats van dat bestand op twee plekken te onderhouden. Welke kant op wordt gesync­hroniseerd, en wat er gebeurt als de koppeling wegvalt, beantwoordt u beter vooraf dan tijdens de eerste storing.

Daarnaast spelen de kanalen zelf. Mail vraagt om het betrouwbaar herkennen van antwoorden op bestaande tickets, zodat een reactie niet als nieuwe melding binnenkomt. Telefonie koppelt u zo dat het nummer van de beller het juiste dossier opent en, als u opneemt, de opname aan het ticket hangt. Een portaal vraagt om inloggen, bij voorkeur met de accounts die uw klanten of medewerkers al hebben. Chat is prettig voor korte vragen, maar levert alleen iets op als het gesprek in hetzelfde ticket landt.

Technisch zijn de meeste onderdelen van een servicedesk bewezen bouwstenen: inloggen, rollen en rechten, zoeken, bijlagen, notificaties en rapportage. Daar vindt u het wiel niet opnieuw uit. Het maatwerk reserveert u voor de logica die uw situatie eigen maakt: uw categorieën, uw escalatieregels, uw servicenormen en de koppeling met uw eigen systemen. Denk ook aan gebruik onderweg, want monteurs, beheerders en buitendienst­medewerkers werken vaak op een telefoon en soms met slecht bereik.

De grootste valkuil is dat een servicedesk-app het bestaande gedoe digitaliseert in plaats van oplost. Een rommelig proces met een mooi ticketscherm blijft een rommelig proces, alleen duurder. Een paar keuzes bepalen of de app werkt, en of maatwerk überhaupt de juiste route is. Loop ze langs voordat u een leverancier vraagt iets te bouwen. De zes punten hieronder komen bij vrijwel elk servic­edeskp­roject terug, en ze gaan zelden over techniek maar over keuzes die u zelf moet maken.

• Toets eerst of een standaardpakket volstaat. Voor gangbare ondersteuning met gangbare kanalen doet een bestaand helpdeskpakket het werk prima. Maatwerk loont pas als uw proces, uw koppelingen of uw servicenormen structureel afwijken van wat zo'n pakket aankan.
• Houd uw categorieën kort. Een lijst met tientallen soorten meldingen wordt niet gebruikt en levert onbruikbare rapportage op. Begin met een handvol categorieën die het werk echt onderscheiden en breid pas uit wanneer de cijfers daarom vragen.
• Leg per rol vast wat iemand mag zien. Een melder, een behandelaar, een teamleider en een externe leverancier hebben elk een ander beeld nodig. Bijlagen en vrije tekstvelden bevatten vaker gevoelige gegevens dan mensen denken, dus beperk de inzage.
• Bepaal wanneer de klok stilstaat. Reactietijd en oplostijd zijn pas stuurbaar als iedereen dezelfde definitie hanteert. Leg vast wat wachten op de klant betekent, wie een norm mag pauzeren en wat er buiten kantoortijden gebeurt.
• Geef de kennisbank een eigenaar. Zelfservice werkt alleen met actuele antwoorden. Spreek af wie artikelen schrijft, wie ze herziet en hoe een opgelost ticket een kennisartikel wordt, anders veroudert de kennisbank binnen een half jaar.
• Test met uw uitzonderingen. De melding die twee afdelingen raakt, de klant zonder contract, de mail zonder onderwerp: juist die gevallen laten zien of het ontwerp klopt. Neem ze op in de acceptatietest en niet pas in productie.

Wat een maatwerk servicedesk kost, hangt vooral af van hoeveel proces u erin legt, hoeveel kanalen u samenbrengt en met hoeveel systemen de app moet praten. Het loont dat te begrijpen, omdat het u helpt scherp te kiezen wat in de eerste versie hoort en wat later kan. Bijna elk onderdeel hieronder is uitstelbaar, en een servicedesk die met beperkte functies in gebruik is, levert meer op dan een complete versie die nog gebouwd wordt.

De grootste kostenbepaler is het aantal kanalen. Alleen een portaal en mail is aanzienlijk eenvoudiger dan een app die daarnaast telefonie, chat en een koppeling met een leverancier bedient. Elk kanaal brengt eigen randgevallen, eigen foutafhandeling en eigen tests mee. Daarna wegen de koppelingen: een verbinding met een CRM of ERP vraagt afstemming met dat systeem, afspraken over welke kant leidend is en zorgvuldig testen. Ook de fijnmazigheid van uw regels telt, want prioriteiten per klantgroep, normen per contract en uitzonderingen op uitzonderingen zijn stuk voor stuk logica die gebouwd en getest moet worden.

Verder bepalen de eisen aan rapportage en aan beveiliging een deel van het werk. Vrij samen te stellen overzichten zijn iets anders dan een vaste maandrapportage, en toegang per rol, logging en bewaartermijnen vragen extra aandacht zodra er gevoelige gegevens of gespreksopnames in de app staan. Tot slot speelt de migratie: bestaande tickets, klantgegevens en kennisartikelen overzetten is een structureel onderschat onderdeel. Wij noemen op deze pagina geen tarieven. In een gesprek bepalen we samen welke eerste versie voor uw situatie logisch is en wat daarvoor een realistisch budget is.

Een helpdesk-app laten bouwen verloopt het soepelst als u klein begint en het proces eerst op papier klopt. Dit stappenplan brengt u van een overvolle gedeelde mailbox naar een servicedesk die uw team daadwerkelijk gebruikt, zonder dat u vooraf alles hoeft te bedenken. De eerste drie stappen kosten geen regel code en bepalen toch het meeste, omdat ze vastleggen wat de app moet afdwingen.

1. Meet uw huidige instroomTel een aantal weken lang hoeveel meldingen binnenkomen, via welk kanaal, waarover ze gaan en hoeveel ervan herhalingen zijn. Zonder dat beeld kiest u functies op gevoel en bouwt u het verkeerde eerst.
2. Beschrijf het proces zonder softwareLeg vast wie een melding aanneemt, wie hem oplost, wanneer hij escaleert en wanneer hij dicht mag. Los eerst de afspraken op die vandaag ontbreken en teken pas daarna de schermen.
3. Spreek prioriteiten en servicenormen afBepaal welke soorten meldingen voorgaan, wat u belooft over reactie en oplossing, en wanneer de klok stilstaat. Toets die belofte aan de bezetting die u werkelijk hebt, niet aan de bezetting die u wenst.
4. Kies de kanalen en koppelingen voor versie éénBegin met het kanaal waar het meeste binnenkomt en met de koppeling die het meeste zoekwerk bespaart, meestal die met uw CRM of ERP. Parkeer de rest zichtbaar op een lijst voor later.
5. Vul de kennisbank voor de startVerzamel de antwoorden die u het vaakst typt en zet ze om in artikelen die melders zelf kunnen vinden. Een kennisbank die leeg blijft bij de start, wordt zelden alsnog gevuld.
6. Introduceer, meet en bouw uitGa live met een beperkte groep, kijk na een aantal weken naar doorlooptijd, werkvoorraad en herhaa­lmeldingen, en breid uit op grond van wat die cijfers laten zien in plaats van wat iedereen wenst.

• Gids: meldingen-app
• Gids: urenregistratie-app
• App of website?
• Alle app-gidsen