Klantenportalen: de volledige gids

Het woord klantenportaal wordt gebruikt voor alles van een inlogpagina met facturen tot een compleet self-serviceplatform. De kern is steeds hetzelfde: een klant logt in en ziet zijn eigen gegevens, zonder dat iemand bij u die hoeft op te zoeken.

Een klantenportaal beantwoordt de vraag 'hoe staat het met ...' voordat de klant hem stelt.

Dat klinkt eenvoudig, maar het bepaalt het hele ontwerp. Een portaal is geen tweede website met een inlog; een website vertelt wat u doet, een portaal toont wat u voor déze klant heeft gedaan. Het is ook geen app om nieuwe dingen te verkopen. Klanten die inloggen, komen voor iets dat al loopt: een order, een dossier, een contract, een factuur die ze kwijt zijn.

De toepassingen lopen uiteen. Een groothandel geeft zijn afnemers orderhistorie, prijsafspraken en pakbonnen. Een adviesbureau deelt dossiers en concepten die de klant moet goedkeuren. Een installateur laat zien welke apparaten bij de klant staan, wanneer de volgende onderhoudsbeurt is en welke storingen open staan. Een gemeente toont de status van een aanvraag. Het patroon is hetzelfde; wat erin staat, verschilt per bedrijf.

Wat een portaal niet is: een plek waar de klant iets vindt dat u zelf nog niet weet. Als de orderstatus bij u in een spreadsheet staat die eens per week wordt bijgewerkt, toont het portaal een status van een week oud. Het portaal maakt uw administratie zichtbaar, inclusief de gaten erin.

De snelste manier om te bepalen wat in het portaal hoort, is niet een workshop maar een export. Haal een maand aan inkomende vragen uit uw mailbox of ticketsysteem en tel per onderwerp. De top tien is de eerste versie van het portaal.

Status

waar is mijn order, mijn aanvraag, mijn reparatie

Documenten

de factuur, het contract, de offerte, het certificaat

Gegevens

adres, contactpersoon, afleveradres, betaalwijze wijzigen

Melden

een storing, een klacht, een retour, een vraag

Die vier groepen dekken bij de meeste bedrijven meer dan de helft van het inkomende verkeer. Statusvragen zijn de grootste groep en de makkelijkste om te vervangen, omdat het antwoord al in een systeem staat. Documenten zijn de tweede: een klant die een factuur van drie maanden geleden zoekt, wil hem downloaden, niet aanvragen.

Gegevens wijzigen is lastiger dan het lijkt. Een adreswijziging moet in het CRM, in de boekhouding en soms in het ordersysteem terechtkomen, en die drie hebben elk hun eigen regels over wie wat mag aanpassen. Bouw dit pas als de koppelingen er zijn; een wijziging die alleen in het portaal landt, is erger dan geen wijziging.

Melden is de vierde groep en de enige waar de klant iets nieuws inbrengt. Een storing melden met een foto, een retour aanvragen, een vraag stellen bij een specifieke order: dat is waar een portaal meer wordt dan een kijkdoos. Het vraagt wel dat de melding bij iemand terechtkomt die hem oppakt, en dat de klant de status daarvan weer in het portaal ziet.

Alles wat in een portaal staat, is per definitie gevoelig: het gaat over één klant en het is van die klant. De vraag wie binnenkomt en wat hij dan ziet, bepaalt of het portaal een dienst is of een datalek.

De AVG raakt een portaal op twee manieren. Ten eerste dataminimalisatie: toon alleen wat de klant nodig heeft, niet alles wat u over hem heeft. Interne notities, marges en kredietscores horen niet in een klantscherm. Ten tweede het inzagerecht: een portaal waarin de klant zijn eigen gegevens ziet, beantwoordt een deel van de inzageverzoeken vanzelf, maar alleen als hij ook kan zien wat u bewaart en hoe lang.

Voor overheden en zorginstellingen geldt een extra laag. Inloggen met DigiD vraagt een aansluiting bij Logius met een eigen beveiligingsassessment; dat is een traject naast de bouw van het portaal. Wie daar niet aan toe is, begint met een portaal voor zakelijke klanten en zet burgers op de tweede versie.

Een portaal dat een verkeerde status toont, is schadelijker dan geen portaal. De klant ziet 'verzonden' terwijl de order in het magazijn ligt, belt boos, en gebruikt het portaal daarna niet meer. Drie patronen komen steeds terug.

Het tweede patroon is het gevaarlijkst. Als de klant belt over iets dat hij in het portaal zag, en de medewerker kan dat scherm niet zien, ontstaat een gesprek over twee verschillende werkelijkheden. Geef de klantenservice dezelfde weergave als de klant, met daarnaast de interne informatie. Dat is technisch eenvoudig en het voorkomt de helft van de irritatie.

Het derde patroon is het portaal dat te vroeg te veel wil. Een eerste versie met status en documenten, die klopt, wint het van een complete versie met een self-service die halverwege blijft steken. Klanten vergeven een portaal dat weinig doet; ze vergeven geen portaal dat iets fout doet.

Een portaal is een venster op systemen die u al heeft. Hoe minder het zelf bewaart, hoe minder er uit elkaar kan lopen. Welke koppelingen nodig zijn, hangt af van wat de klant moet zien.

De volgorde waarin u koppelt, is een keuze. Boekhouding eerst is verleidelijk omdat facturen een duidelijke vraag zijn, maar de status van orders of dossiers levert meestal meer telefoontjes op. Begin bij de bron van de meeste vragen, ook als die koppeling technisch lastiger is.

Terugschrijven is een aparte stap. Lezen uit een systeem is bijna altijd mogelijk; een klant laten wijzigen wat in dat systeem staat, vraagt dat het systeem die wijziging accepteert en dat iemand bij u hem ziet. Bouw de eerste versie leesbaar en laat wijzigingen als verzoek binnenkomen bij een medewerker. Pas als dat loopt, wordt het verzoek een directe wijziging.

Honderd of tienduizend klanten maakt voor de bouw weinig uit. Wat de prijs drijft, is hoeveel systemen het portaal moet raken en hoeveel het mag veranderen.

Koppelingen

elke bron is een eigen stuk werk, met eigen regels en eigen storingen

Rollen

één persoon per klant is eenvoudig; drie rollen per organisatie is een rechtenmodel

Schrijven

alleen lezen is een venster; wijzigen is een proces met controle

Inloggen

een link per mail is simpel; DigiD of eHerkenning is een aansluittraject

Wat meestal meevalt: de schermen zelf. Een overzicht van orders, een lijst facturen, een documentenmap: dat zijn bekende onderdelen. Wat tegenvalt, is de kwaliteit van de gegevens erachter. Een portaal legt bloot dat klantnamen in drie systemen anders zijn gespeld en dat een deel van de orders geen status heeft. Dat opruimen is werk voor u, en het moet vóór de lancering gebeuren.

Reken ook de doorlopende kant mee. Een koppeling die vandaag werkt, breekt als de leverancier van uw boekhoudpakket zijn koppelvlak wijzigt. Iemand moet dat zien en herstellen. Een portaal zonder beheer wordt binnen een jaar een portaal dat verkeerde dingen toont.

De volgorde hieronder begint niet bij een ontwerp maar bij uw inkomende mail. Daar staat wat het portaal moet doen.

1. Tel een maand aan vragenPer onderwerp: status, documenten, gegevens, meldingen. De top tien is de eerste versie.
2. Kies drie schermenNiet meer. De schermen die de meeste vragen vervangen, en waarvan de bron nu al klopt.
3. Regel het inloggenWie zijn de klanten, hoeveel personen per klant, en hoe komen ze binnen zonder te bellen.
4. Koppel de eerste bronLeesbaar, rechtstreeks, zonder tussenkopie. Test met echte klanten en echte orders.
5. Laat de klantenservice meekijkenZij zien wat de klant ziet en noteren wat er mist of niet klopt.
6. Meet het verschilHet aantal vragen per onderwerp, vóór en na. Dat cijfer bepaalt wat de tweede versie krijgt.