Portaal voor klanten én medewerkers: één inlog, meerdere doelgroepen

Een portaal voor klanten en medewerkers combineert twee doelgroepen in één systeem, maar dan wel met verschillende rechten en schermen. Veel organisaties werken nu nog met twee losse omgevingen: een systeem voor medewerkers en losse e-mails of een los formulier voor klanten. Dat kan slimmer, mits je de rollen goed inricht.

Waarom één portaal met meerdere rollen

Je ziet het bij veel MKB-bedrijven: een medewerker beheert een dossier in het ene systeem, en de klant krijgt de status per e-mail of telefoon door. Dat kost tijd en zorgt voor fouten, want niemand kijkt naar exact dezelfde informatie.

Een portaal met meerdere rollen lost dat op door iedereen in te laten loggen op dezelfde achterliggende data, maar met een andere weergave. Een medewerker ziet alle dossiers en kan ze bewerken. Een klant ziet alleen het eigen dossier en kan bijvoorbeeld documenten uploaden of een status bekijken.

Rollen en rechten als basis

Technisch draait dit om rollen en rechten, vastgelegd in de applicatie zelf. Elke gebruiker krijgt een rol, bijvoorbeeld beheerder, medewerker of klant. Per rol bepaal je wat iemand mag zien en doen. Dat voorkomt dat een klant per ongeluk bij gegevens van een andere klant komt, en dat een medewerker toegang heeft tot functies die niet voor die rol bedoeld zijn.

Bij een maatwerkportaal op Laravel wordt dit vaak ingericht met een los rollenmodel. Dat betekent dat je later eenvoudig een nieuwe rol kunt toevoegen, bijvoorbeeld een externe partner, zonder dat je het hele systeem opnieuw moet bouwen.

Wat betekent dit voor jouw organisatie

Voor een organisatie met 5 tot 25 medewerkers is dit vaak relevant zodra klanten of partners om inzicht vragen in een proces dat nu nog via e-mail of telefoon loopt. Denk aan een aanvraagstatus, een planning of documenten die heen en weer gaan.

Het voordeel is dat je maar één systeem beheert in plaats van twee. Dat scheelt onderhoud en voorkomt dat gegevens in twee systemen uit elkaar gaan lopen. Het nadeel is dat je vooraf goed moet nadenken over wie wat mag zien. Dat kost tijd in de ontwerpfase, maar voorkomt problemen later.

Een goed voorbeeld uit de praktijk is het maatwerkportaal van EPA Advies Noord, waar makelaars energielabelaanvragen kunnen indienen en volgen. Daar is duidelijk onderscheid tussen wat een makelaar ziet en wat de organisatie zelf intern afhandelt.

Wanneer is dit wél de juiste stap

• Je hebt klanten of partners die nu via e-mail of telefoon om een status vragen die je eigenlijk al digitaal bijhoudt.
• Medewerkers werken al in een digitaal systeem en het is een kleine stap om een deel daarvan ook aan klanten te tonen.
• Je verwacht dat het aantal gebruikers of rollen de komende jaren groeit, bijvoorbeeld met partners of franchisenemers.

Wanneer is dit niet nodig

• Je hebt maar een paar klanten die je prima persoonlijk te woord kunt staan zonder dat dit tot fouten leidt.
• Het proces verandert nog vaak. Dan is het slimmer om eerst het proces zelf te stabiliseren, voordat je het in een portaal vastlegt.
• Een bestaand systeem heeft al een klantportaalfunctie die voldoende is voor wat je nodig hebt.

Hoe zo’n traject eruitziet

Een traject voor een portaal met meerdere rollen begint meestal met een overzicht van de verschillende gebruikers: wie moet wat kunnen zien en doen. Daarna wordt bepaald welke gegevens iedere rol nodig heeft en hoe de koppeling tussen rollen en rechten technisch wordt opgebouwd.

Pas daarna volgt de bouw zelf, vaak in stappen. Je begint met de belangrijkste functies voor de belangrijkste rol, en breidt daarna uit. Zo kun je het portaal al gebruiken voordat alles af is, en stuur je bij op basis van wat medewerkers en klanten er in de praktijk mee doen.

Bij sommige van dit soort trajecten komt ook een API kijken, bijvoorbeeld als het portaal gegevens moet uitwisselen met een ander systeem. Dat is een aparte afweging die los staat van het rollenmodel zelf, maar vaak wel samen wordt ontworpen.

Conclusie

Een portaal voor klanten en medewerkers samen is een logische stap als je nu twee aparte manieren van werken hebt die eigenlijk op dezelfde data draaien. De techniek zit vooral in een goed doordacht rollenmodel: wie ziet wat, en wie mag wat aanpassen. Twijfel je of dit bij jouw organisatie past, of wil je weten hoe zo’n traject er in jouw situatie uitziet? Neem gerust contact op, of bekijk meer voorbeelden op de projectenpagina.