Een klantenportaal laten maken dat je klanten ook echt gebruiken
Je klanten bellen en mailen voor dingen die ze prima zelf zouden kunnen opzoeken. De status van hun order, een factuur van vorig kwartaal, een adreswijziging. Een klantenportaal haalt dat werk weg bij je team. Riotbyte bouwt omgevingen die koppelen met de systemen die je al gebruikt, zodat de data klopt zonder dat iemand hem overtikt.
Waarom een klantportaal laten ontwikkelen zo vaak blijft liggen
Je team is het doorgeefluik tussen klant en systeem
Elke statusvraag, elke factuur die opnieuw gestuurd moet worden, elke wijziging in gegevens komt binnen bij een mens. Die zoekt het op in een systeem waar de klant zelf niet bij kan, en tikt het antwoord over in een mail. Het werkt, maar het schaalt niet: meer klanten betekent lineair meer van dit werk, en het is precies het type werk dat niemand leuk vindt.
De data staat in vier systemen die niets van elkaar weten
Orders in het ene systeem, facturen in het boekhoudpakket, verzendinformatie bij de vervoerder, klantgegevens in een CRM. Die vier bronnen moeten bij elkaar komen op n plek, zonder dat er een vijfde systeem ontstaat dat weer apart bijgehouden moet worden. Dat koppelvraagstuk is meestal het echte werk, niet de schermen.
Standaardsoftware dwingt je proces in een vorm die niet past
Er zijn kant-en-klare pakketten. Die werken, tot je merkt dat jouw klanten net iets anders nodig hebben dan het pakket biedt. Dan begint het opstapelen: custom velden, workarounds, een handmatige stap ernaast. Op enig moment onderhoud je meer uitzonderingen dan het pakket je bespaart.
Hoe wij een klantenportaal op maat bouwen
We bouwen niet wat je klanten misschien willen, maar wat ze nu vragen
Wat is een discovery traject?Een portaal is pas waardevol als klanten het gebruiken, en dat gebeurt alleen als het de vragen beantwoordt die ze daadwerkelijk stellen. We beginnen met een discovery van maximaal twee weken: welke vragen komen het vaakst binnen, welke systemen bevatten de antwoorden, en wat is de kleinste versie die dat al oplost. Wat daarbuiten valt bouwen we later, of niet.
Geen vijfde systeem erbij, maar een venster op wat je al hebt
De omgeving wordt geen nieuwe bron van waarheid. We bouwen koppelingen met onder andere Exact, Shopify, WooCommerce, PostNL, DPD, ReturnGo en Wasp, plus interne applicaties. Als een systeem een API heeft, is er vrijwel altijd een koppeling mogelijk. Zo blijft de data op n plek staan en klopt wat de klant ziet met wat jij ziet.
Klantdata betekent dat toegangsbeheer geen bijzaak is
Zodra klanten inloggen en hun eigen gegevens zien, wordt security een ontwerpvraag in plaats van een sluitpost. Standaard werken we met tweefactorauthenticatie, rolgebaseerde toegangsrechten en versleuteling van data at rest. Voor authenticatie gebruiken we OAuth, aangevuld met DPoP: een token dat gestolen wordt is dan onbruikbaar op een ander apparaat. Alle handelingen worden vastgelegd in audit trails, en elke rol krijgt alleen toegang tot wat strikt nodig is.
De kennis zit in de koppelingen, dus die dragen we niet over
Bij een portaal zit de complexiteit zelden in de schermen. Die zit in de afspraken tussen systemen: welk veld leidend is, wat er gebeurt als een order halverwege wijzigt, hoe je omgaat met een vervoerder die tijdelijk niet reageert. Die kennis ontstaat tijdens de discovery en zit bij de mensen die het bouwen. Bij ons zijn dat dezelfde mensen, van eerste gesprek tot livegang en daarna.
Zo verloopt een portaaltraject bij Riotbyte
Discovery (maximaal twee weken)
We brengen in kaart welke vragen nu bij je team binnenkomen, waar de antwoorden staan en welke koppelingen daarvoor nodig zijn. Resultaat: een concreet plan met scope, aanpak en inschatting.
Eerste versie live
We bouwen de versie die het grootste deel van de inkomende vragen wegneemt. Je klanten kunnen ermee werken voordat het hele traject af is.
Uitbreiden per milestone
Wat klanten in de omgeving doen en welke vragen alsnog binnenkomen bepaalt wat er volgt. Elke milestone heeft een eigen scope en doorlooptijd die we vooraf bepalen.
Beheer en doorontwikkeling
Alles blijft veilig en onderhoudbaar. Je bent eigenaar van de code en kunt op elk moment met een ander team verder.
Veelgestelde vragen over een klantenportaal laten maken
Wat is een klantenportaal?
Een klantenportaal is een afgeschermde online omgeving waar je klanten met een eigen account inloggen om zaken zelf te regelen. Denk aan het inzien van orders, facturen en verzendstatus, het downloaden van documenten of het doorgeven van wijzigingen. De gegevens komen uit de systemen die je al gebruikt, zodat de klant ziet wat jij ziet zonder dat iemand het hoeft over te tikken.
Wat kost het om een klantenportaal te laten maken?
Software is een breed begrip: je betaalt voor een Ford Focus ander geld dan voor een Rolls Royce, en allebei brengen je van A naar B. Een dunne laag op een bestaand systeem kost iets heel anders dan een omgeving die vanaf nul wordt gebouwd met meerdere koppelingen en rollen. Een eerlijke inschatting kunnen we pas geven als we weten wat het moet oplossen en welke systemen eraan hangen. Daarom starten we met een kort, betaald discovery traject dat scope en aanpak scherp maakt voordat er groot budget vastligt.
Hoe lang duurt het om een klantportaal te laten bouwen?
Dat hangt sterk af van wat je eronder verstaat. Voor de eindgebruiker is het allebei een webinterface met een login, maar technisch is het verschil groot. Een dunne frontend op een bestaand systeem staat sneller dan iets dat vanaf nul wordt gebouwd met meerdere koppelingen, rollen en processen erin. In de discovery bepalen we welke van de twee jouw situatie is en wat dat betekent voor de doorlooptijd.
Hoe zit het met beveiliging en toegangsrechten?
Standaard werken we met tweefactorauthenticatie, rolgebaseerde toegangsrechten en versleuteling van data at rest. Voor authenticatie gebruiken we OAuth, aangevuld met DPoP zodat tokens niet buiten de bedoelde client bruikbaar zijn. Alle handelingen worden vastgelegd in audit trails en we hanteren het principle of least privilege: elke rol krijgt alleen toegang tot wat strikt nodig is.
Kunnen jullie koppelen aan ons bestaande systeem?
Ja, en dat is meestal het grootste deel van het werk. We bouwen koppelingen met onder andere Exact, Shopify, WooCommerce, PostNL, DPD, ReturnGo en Wasp, en met interne applicaties. Als een systeem een API heeft, is een koppeling vrijwel altijd mogelijk. Bij systemen zonder API kijken we naar alternatieven zoals bestandsuitwisseling of een tussenlaag.
Wat is het verschil tussen een klantenportaal en een leveranciersportaal?
Technisch is het verschil klein, functioneel is het groot. Bij een klantenportaal draait het om inzicht en selfservice voor afnemers: orders, facturen, status. Bij een leveranciersportaal of b2b portaal gaat het vaker om tweerichtingsverkeer: leveranciers uploaden documenten, bevestigen levering of voeren gegevens in die jouw proces raken. Dat vraagt andere rollen, andere validaties en meestal strengere audit trails.
Eerlijk: wanneer wij niet de juiste keuze zijn
Liever vooraf nee dan halverwege uit elkaar. We werken het best met opdrachtgevers die ruimte laten om mee te sturen op de richting, niet alleen op de uitvoering. Herken je dit niet, dan zijn wij waarschijnlijk niet de juiste partij.
- 01Wanneer standaardsoftware je proces goed dekt. Als er een pakket is dat doet wat je nodig hebt, adviseren we je dat te gebruiken. Maatwerk wordt pas interessant als je het pakket met uitzonderingen moet oprekken.
- 02Wanneer je klanten er niet op zitten te wachten. Een omgeving die niemand gebruikt kost geld en levert niets op. Als je niet weet welke vragen je klanten stellen, is dat het gesprek voordat we gaan bouwen.
- 03Wanneer je een fixed price wilt voor een scope die nog moet uitkristalliseren. Koppelingen met bestaande systemen leveren vrijwel altijd verrassingen op. We werken per milestone met eerlijke schattingen.
Vertel ons wat je bouwt
Geen pitch decks nodig. Een paar zinnen over je project is genoeg om een gesprek te starten.
Liever direct een founder mailen? Daniël · Maarten · Niels
Liever algemeen mailen? [email protected]