Een klantportaal is niet een website met een inlogknop. Dat is het begin, maar het is lang niet het eindpunt.
Een goed klantportaal is de plek waar klanten (of partners, leveranciers, distributeurs) precies de informatie en handelingen vinden die anders telefonisch, per mail of via een medewerker verlopen. Orderstatus opvragen. Een factuur downloaden. Een retour aanmelden. Een document goedkeuren. Openstaande acties inzien. Een nieuwe aanvraag indienen. Documenten uitwisselen met jouw team.
De impact is tweezijdig. Aan de klantkant: minder afhankelijkheid van jouw kantooruren, minder herhalen van informatie, meer transparantie over wat er speelt. Aan jullie kant: minder routinematig klantcontact dat mensen ophoudt van werk dat echt waarde toevoegt.
In de praktijk zijn er drie typen portalen die we regelmatig bouwen.
Elk van die drie vraagt een andere architectuur, een ander rechtenmodel en andere koppelingen. Wat ze gemeen hebben is de vraag die altijd eerst beantwoord moet worden: wat doet een klant nu handmatig dat hij zelf zou kunnen, en wat heeft hij daarvoor nodig?
Voor eindklanten die informatie willen over hun dossier, order, contract of ticket. Denk aan een groothandel waarvan klanten hun orderhistorie en openstaande facturen kunnen inzien, of een dienstverlener waarvan klanten de voortgang van hun project volgen.
Voor third parties die gestructureerd informatie aanleveren of raadplegen. Een leverancier die zijn factuurstatus bijhoudt, een distributeur die zijn orders plaatst, een partner die klantdossiers beheert.
Voor medewerkers die HR-zaken, IT-aanvragen of faciliteitsverzoeken zelfstandig willen afhandelen. Die vallen ook onder "portaal" maar worden intern gebouwd.
Een portaal is geen op zichzelf staand systeem maar een samenspel van componenten. We lopen ze door, inclusief de Zoho-applicaties die in elk onderdeel een rol spelen.
Wanneer de standaardportaalfunctionaliteiten van de Zoho-apps niet toereikend zijn (een eigen schermontwerp, eigen logica, koppelingen met externe systemen, specifieke workflows) bouwen we het portaal op Zoho Catalyst. Dat is Zoho's pro-code ontwikkelplatform waarop je eigen applicaties en portalen bouwt, binnen hetzelfde ecosysteem als de rest van je Zoho-omgeving.
Dat heeft als voordeel dat het portaal het gebruikersbeheer, de rechten en de data van je Zoho-omgeving deelt, maar volledig naar jouw wensen is ontworpen, inclusief jouw huisstijl, jouw schermindeling en jouw proceslogica.
Klanten vinden hun facturen, orderstatus en documenten nu zelf in het portaal. Onze binnendienst krijgt merkbaar minder telefoontjes met dezelfde vragen.
De meest gestelde vraag bij de oriëntatie is de kostenvraag. Het eerlijkste antwoord is: dat hangt af van wat je erin stopt.
Een portaal dat alleen facturen toont via Zoho Books is in weken te realiseren. Een portaal met volledige dossierinzage, documentuitwisseling, formulieren, ticketafhandeling, een koppeling met Exact Online en een ERP-koppeling voor orderstatus is een traject van maanden.
De terugverdientijd is vrijwel altijd aantoonbaar. Tel de uren die je binnendienst, finance of klantenservice kwijt is aan routinematige vragen die een portaal zelfstandig beantwoordt: factuurkopieën sturen, orderstatus doorspelen, documenten mailen, status doorbellen. Bij de meeste organisaties die we analyseren is dat tien tot dertig procent van het volume aan inkomend klantcontact. Bereken dat in mensuren per maand en de businesscase schrijft zichzelf.
Dat is de analyse die we altijd voorafgaand aan de bouwaanvraag maken: wat gaat het portaal afvangen, wat levert dat op, en wat is het verstandig om als eerste te bouwen?
Wil je een klantportaal laten bouwen? Vraag eerst een proefomgeving aan en ontdek zelf hoe de portaalfunctionaliteit van Zoho CRM, Zoho Desk en Zoho Books werkt. Wij helpen je graag op weg.
Een partnerportaal voor distributeurs, agenten of resellers vraagt andere keuzes dan een klantportaal voor eindklanten.
Wij bouwen portalen als onderdeel van bredere Zoho-trajecten en als zelfstandig project. Onze rol begint altijd bij de vraag wat het portaal moet doen, niet bij het kiezen van een template.
Onze breedte maakt ons advies anders dan dat van een webontwikkelaar die portalen in WordPress bouwt of een Zoho-reseller die alleen de standaardportaalfunctionaliteit kent. We kennen de integratielaag, de CRM-logica, de financiële koppelingen en de procesvragen die bepalen hoe een portaal werkelijk voor klanten werkt.
En wanneer het maatwerk vereist (eigen schermen, eigen logica, koppelingen die buiten de standaard vallen) hebben we een eigen ontwikkelteam dat op Zoho Catalyst bouwt. Dat is de combinatie die je nergens anders tegelijk vindt: Zoho-expertise plus pro-code ontwikkelcapaciteit, in één team.
Een portaal voor klanten in Nederland, België en Duitsland spreekt drie talen, en elk rechtensysteem heeft zijn eigen gebruikers, zijn eigen documenten en soms zijn eigen prijsafspraken.
Facturen voor de Belgische entiteit zien er anders uit dan voor de Nederlandse, met andere btw-nummers, andere wettelijke vermeldingen en mogelijk een ander boekhoudpakket als bron.
Welke klantdata sla je op in het portaal, op welke locatie, voor hoe lang? Bij klanten in meerdere EU-landen is de vraag uniform; bij klanten buiten de EU komen aanvullende doorgifteoverwegingen bij.
Eén land als piloot, lessen trekken, dan uitrollen naar de volgende. Niet alles tegelijk, want dan is de feedbackloop te traag. Wij werken in het Nederlands en het Engels en stemmen de begeleiding af op de landen waar je actief bent.
Wij werken een portaaltraject altijd in fases af.
Wat doet een klant nu dat het portaal moet overnemen? We tellen het volume en berekenen de businesscase.
Welke Zoho-standaardportaalfunctionaliteit volstaat, en waar is Zoho Catalyst nodig voor eigen logica of schermen?
Welke klant mag welke data zien, op basis van welk veld in welk systeem?
Exact Online, ERP, WMS, telefonie: welke data moet het portaal ophalen en welk systeem is daarin de bron?
Inclusief de randgevallen: wat ziet een klant zonder orders, een klant met een geblokkeerd account, een klant die voor het eerst inlogt?
Een selecte groep klanten gaat als eerste live, met feedbackronde.
Inclusief documentatie en de afspraken over wie het portaal beheert en doorontwikkelt.
Een website is publiek en informatief. Een klantportaal is besloten en transactioneel: klanten loggen in met hun eigen account en zien alleen hun eigen informatie (hun orders, hun facturen, hun dossier, hun tickets). Ze kunnen er ook handelingen verrichten: een aanvraag indienen, een document uploaden, een factuur downloaden. Dat vereist integraties met je backendsystemen die een reguliere website niet heeft.
Dat hangt af van de functionaliteiten die je wilt aanbieden. Zoho CRM voor klantdossiers en accountinformatie, Zoho Desk voor ticketing en supporthistorie, Zoho Books voor facturen en betalingen, Zoho WorkDrive voor documentuitwisseling, Zoho Forms voor aanvragen en meldingen, Zoho Sign voor digitale handtekening, Zoho Learn voor trainingen en certificering, en Zoho Catalyst voor de schermen en logica die buiten de standaard vallen.
Ja. Exact Online heeft een REST-API waarmee we factuurdata, betalingsstatus en klantinformatie ophalen en tonen in het portaal. De klant ziet de actuele stand vanuit Exact, zonder dat er een aparte administratie wordt bijgehouden. We bouwen de koppeling zo dat de data per klant gefilterd wordt en alleen de eigen informatie zichtbaar is.
Beveiliging bestaat uit drie lagen. De toegangslaag bepaalt wie kan inloggen, via welk mechanisme en of er meervoudige authenticatie vereist is. De rechtenlaag bepaalt per gebruiker welke data hij mag zien, en dwingt die filtering technisch af, zodat het niet alleen een weergavebeperking is maar ook een databegrenzing. De transportlaag versleutelt de verbinding via HTTPS en regelt hoe data wordt overgedragen tussen het portaal en de backendsystemen. Bij het gebruik van Zoho-platformen gelden de beveiligingscertificeringen en verwerkersovereenkomsten van Zoho voor de data die daar is opgeslagen.
Een eenvoudig portaal dat facturen en orderstatus toont via de standaard Zoho Books- en Desk-portaalfunctionaliteit is in enkele weken live. Een portaal met meertalige interface, eigen schermontwerp op Zoho Catalyst, documentuitwisseling, ERP-koppeling en een partnerrechtmodel loopt op naar maanden. We werken altijd in fases, zodat je vroeg iets werkends hebt waarop je feedback kunt geven.
Beide zijn mogelijk. Puur informatieve portalen (facturen downloaden, status inzien) zijn de eenvoudigste variant. Transactionele portalen laten klanten ook handelen: een order plaatsen, een retour aanmelden, een formulier indienen, een document uploaden, een goedkeuring geven. Die handelingen triggeren direct een actie in je backendsystemen.
Ja, en het wordt dan een leveranciers- of partnerportaal. De bouw is vergelijkbaar maar de rechtenlogica is anders: een partner mag zijn eigen klanten beheren maar niet die van andere partners, en de informatie die hij ziet (orders, commissies, leads) verschilt van wat een eindklant ziet. We bouwen regelmatig partnerportalen voor distributienetwerken en agentschappen.
Dat is een ontwerpvraag, niet een technische vraag. Een goed portaal vraagt geen technische voorkennis: de interface is intuïtief, de taal is begrijpelijk en de acties zijn minimaal. We testen altijd met echte gebruikers voordat we breed uitrollen. Hoe minder een klant hoeft te begrijpen van het systeem achter het portaal, hoe beter het ontwerp.
Mobile XL bouwt klant- en partnerportalen op Zoho, inclusief koppelingen met Exact Online en andere backendsystemen.
