Wat is een klantenportaal?

Een klantenportaal is een afgeschermd deel van je software waar klanten inloggen en hun eigen gegevens zien: orders, facturen, dossiers, contracten, meldingen. Eén plek, met een eigen account, waar iemand vindt wat hij anders per mail zou moeten opvragen.

Dat is de hele definitie. De rest van dit artikel gaat over wat er onder die ene zin zit, want daar zit het werk — en daar lopen portalen in de praktijk op vast.

Een website informeert iedereen hetzelfde. Een klantenportaal doet het omgekeerde: het laat aan elke gebruiker precies zien wat bij hém hoort, en aan niemand anders iets meer.

Dat klinkt als een detail en het is de kern. Zodra er twee klanten in hetzelfde portaal zitten, is elke pagina een vraag over rechten: mag deze gebruiker dit dossier zien, deze factuur, dit prijsafspraakveld? Een inlogscherm plaatsen is een middag werk. Bepalen wie wat mag zien, en dat blijven kloppen als er een medewerker bij een klant vertrekt, is het echte onderwerp.

Vrijwel elk portaal begint bij hetzelfde ongemak. Klanten stellen dezelfde vragen, en iemand bij jou zoekt elke keer hetzelfde antwoord op.

Waar staat mijn order. Kun je die factuur nog een keer sturen. Wat hebben we vorig jaar afgesproken. Kan ik een kopie van dat certificaat krijgen. Elk van die vragen kost een paar minuten, en die paar minuten zijn onzichtbaar tot je ze bij elkaar optelt.

De informatie bestaat al. Ze staat in je ERP, je CRM, je boekhouding of je planning. De klant mag het weten. Hij kan er alleen niet bij, dus loopt het via een mens. Een portaal haalt die mens uit de route — niet omdat mensen het slecht doen, maar omdat het werk is dat niets toevoegt.

De schermen verschillen per organisatie. Het fundament is opvallend constant.

Rollen en rechten. Wie mag wat zien, per klant en per gebruiker binnen die klant. Dit hoort er vanaf het begin in; achteraf toevoegen betekent bijna altijd elke pagina opnieuw langs.

Inloggen zoals je klanten gewend zijn. Eigen accounts met tweefactorauthenticatie, of single sign-on met het account dat ze al hebben. Bij zakelijke gebruikers is dat tweede vaak de reden dat een portaal daadwerkelijk gebruikt wordt.

Koppelingen in plaats van een tweede administratie. Het portaal toont wat er in je bronsysteem staat. Zet je er een eigen database naast, dan heb je twee waarheden en binnen een jaar een probleem.

Een spoor van wat er gebeurd is. Wie heeft wat bekeken, gewijzigd of geüpload. Prettig bij discussies, noodzakelijk bij audits.

Mobiel. Portalen worden onderweg geopend. Een portaal dat alleen op een laptop werkt, wordt de helft van de tijd niet gebruikt.

De namen verschillen vooral in wie er inlogt. Een B2B-portaal bedient zakelijke afnemers, meestal met meerdere gebruikers per bedrijf en met eigen prijsafspraken. Een leveranciersportaal draait de richting om. Een medewerkersportaal of intranet richt zich naar binnen. Een developer portal ontsluit technische documentatie en tooling voor ontwikkelaars.

Onder de motorkap is het steeds hetzelfde bouwwerk: identiteit, rechten, gekoppelde data, en een schil die daar iets bruikbaars van maakt. Dat is ook waarom ervaring met de ene soort overdraagbaar is naar de andere.

Wij hebben er zelf één gebouwd en houden hem in de lucht: de Developer Portal van ZEN Software, gebouwd op het open platform Backstage.

Achter één inlog staan een catalogus van alle services, de API-documentatie, Lighthouse-metingen, een Tech Radar en een geïntegreerde Agile Analytics-rapportage. Informatie die anders verspreid over vijf tools ligt, met vijf keer inloggen. Toegang loopt via Identity-Aware Proxy van Google Cloud: die legt een centrale autorisatielaag vóór de applicatie, zodat rechten per gebruiker op applicatieniveau gelden in plaats van via een firewall op netwerkniveau — en er geen VPN nodig is.

Dat is een portaal voor ontwikkelaars, niet voor klanten, en dat verschil is echt. De gebruikers zijn collega’s, niet afnemers. Maar de drie dingen die een klantenportaal moeilijk maken zijn precies dezelfde: toegangscontrole per gebruiker, data die uit andere systemen moet komen, en één plek waar er eerst vijf waren.

Vier dingen, in volgorde van hoe vaak we ze tegenkomen.

Het portaal wordt een tweede administratie. Gegevens worden overgenomen in plaats van opgehaald. Vanaf dat moment is er geen bron van waarheid meer, en elke afwijking wordt een discussie.

Rechten zijn achteraf bedacht. Er was één klant tijdens de bouw, dus alles was zichtbaar. Bij de derde klant blijkt dat elke query een filter mist.

Niemand logt in. Een portaal dat niet ontsluit wat mensen daadwerkelijk zoeken, wordt na twee keer proberen weer een mailtje. De vraag "welke vijf vragen krijgen we het vaakst" is meer waard dan een functielijst van vijftig.

Het bronsysteem heeft geen API. Dat is zelden een blokkade, maar wel een kostenpost die je liever vóór het project kent dan erna.

Een portaal verdient zichzelf terug op herhaling, niet op omvang. Als dezelfde vraag elke week terugkomt, als de informatie al bestaat maar vastzit, of als er een maandelijkse export bestaat die iemand met de hand bewerkt en mailt — dan is er al een portaal, alleen met handkracht.

En omgekeerd: heb je vijf klanten die je elk persoonlijk spreekt, dan lost een portaal een probleem op dat je niet hebt.

Wil je weten wat het in jouw situatie zou wegnemen, of wat een klantportaal laten maken in jouw geval betekent? We denken graag een uur mee voordat er iets gebouwd wordt.