Een klantenportaal laten maken: functies, rollen en koppelingen

Dan moet het portaal wel iets makkelijker maken. Alleen een login toevoegen en wat bestanden achter een wachtwoord zetten is daarvoor niet altijd genoeg. Je wilt weten welke taak een klant zelfstandig kan afronden en wat je team daarvoor moet regelen.

Begin dus bij de vragen en handelingen die nu via mail, telefoon of losse bestanden lopen. Daaruit volgt welke omgeving je moet laten maken.

Kies de eerste taak die je wilt oplossen

Een portaal kan heel veel functies krijgen: documenten, facturen, aanvragen, berichten, afspraken en betalingen. Zo'n lijst groeit snel. Maak daarom eerst één taak concreet.

Neem bijvoorbeeld een klant die een document moet beoordelen. Diegene moet weten dat er iets klaarstaat, de juiste versie kunnen openen en feedback of akkoord kunnen geven. Je team moet vervolgens zien wat de reactie is en wat de volgende stap wordt.

Daar heb je meer aan dan de losse wens 'documenten delen'. Je ziet meteen welke informatie, meldingen en acties nodig zijn. Ook zie je wat voorlopig buiten de scope kan blijven, zoals een uitgebreide chatfunctie als opmerkingen bij het document voldoende zijn.

Een klantaccount kan meerdere gebruikers hebben

Bij zakelijke klanten is één login per bedrijf niet altijd handig. De ene medewerker mag aanvragen indienen, de andere mag ze goedkeuren en iemand van finance wil alleen facturen zien. Dat zijn verschillende rollen, ook als ze bij dezelfde organisatie horen.

Werk per rol uit welke gegevens iemand mag bekijken en welke acties mogelijk zijn. Denk ook aan het uitnodigen van collega's, het intrekken van toegang en een medewerker die van werkgever wisselt. Dit zijn gewone situaties die onderdeel moeten zijn van het ontwerp.

Een verborgen knop is daarbij geen toegangscontrole. Het systeem moet ook bij het opvragen of wijzigen van gegevens controleren of die gebruiker dat mag. Dat sluit aan op de autorisatierichtlijnen van OWASP: geef toegang op basis van wat nodig is en controleer de toestemming bij iedere aanvraag aan het systeem.

Bepaal welk systeem de gegevens beheert

Waarschijnlijk staan klantgegevens, orders of projecten al ergens. Je wilt voorkomen dat je portaal er een tweede administratie naast wordt waarin iedereen weer iets moet bijhouden.

Spreek daarom per gegeven af welk systeem leidend is. Komt de orderstatus uit je ERP? Staat de contactpersoon in het CRM? En mag de klant een adres aanpassen in het portaal, of moet die wijziging eerst worden gecontroleerd?

Een koppeling moet dat gedrag ondersteunen. Het is niet genoeg dat twee systemen gegevens kunnen uitwisselen. Je moet ook afspreken wat er gebeurt bij vertraging, ontbrekende informatie of een mislukte wijziging. Laat een klant bijvoorbeeld geen definitieve bevestiging zien als het verzoek nog niet goed is verwerkt.

Maak de overstap naar het portaal begrijpelijk

Klanten gebruiken een nieuwe omgeving pas als duidelijk is wat die oplevert. Laat daarom meteen zien wat ze er kunnen regelen. Een startscherm met één openstaande actie kan nuttiger zijn dan een uitgebreide welkomstpagina.

Denk ook aan de momenten buiten het portaal. Een duidelijke mail kan iemand vertellen dat er een document klaarstaat, met een link naar de juiste plek. Daarna moet inloggen geen zoektocht worden. Werk de eerste uitnodiging, het herstellen van toegang en de mobiele ervaring mee uit.

En houd ruimte voor contact. Sommige vragen passen niet in een vooraf bedacht proces. Maak zichtbaar waar iemand terechtkan als de aangeboden opties niet helpen.

Bestaande portalsoftware of maatwerk?

Als je vooral standaarddocumenten en facturen wilt delen, kan een bestaande klantomgeving voldoende zijn. Onderzoek eerst welke functies jullie huidige software al biedt en of die aansluiten op de gebruikersrollen.

Maatwerk wordt interessanter wanneer het portaal een specifiek onderdeel van jullie dienstverlening vormt. Bijvoorbeeld met eigen aanvraagstappen, goedkeuringen of informatie uit meerdere systemen. Ook de merkbeleving kan een reden zijn om de omgeving zelf te ontwerpen, zodat klanten één samenhangende ervaring krijgen.

Die vrijheid vraagt wel om keuzes over beheer. Wie helpt bij toegangsproblemen? Wie controleert mislukte koppelingen? En wie beslist welke functies erbij komen? Leg dat vast naast de bouwopdracht.

Wil je weten wat die keuzes voor de investering betekenen? In onze uitleg over de kosten van een webapp lees je hoe scope, gebruikersrollen en koppelingen de hoeveelheid werk bepalen.

Neem één klantproces mee naar het eerste gesprek

Je hoeft geen complete functionele beschrijving klaar te hebben. Een uitgewerkt voorbeeld is een goed begin: wat probeert de klant te doen, welke stappen doorloopt je team nu en waar loopt het vast?

Voeg daar de gebruikte systemen en een paar veelvoorkomende uitzonderingen aan toe. Daarmee kunnen we samen bepalen welke eerste versie nuttig is en hoe je die met klanten test.

Wil je een klantenportaal laten uitwerken? Begin bij die ene taak die steeds een mailtje of telefoontje vraagt. Als we die goed begrijpen, wordt vanzelf duidelijk welke functies het portaal nodig heeft.