Van e-mailchaos naar een selfserviceportaal: een eerlijke casestudy
Een middelgroot dienstverlenend bedrijf verdronk in klant-e-mails — steeds dezelfde vragen, verdwenen bijlagen, niemand die zeker wist wie wat had beantwoord. Zo vervingen we de inbox door een portaal, wat werkte en wat we anders zouden doen.

Elke overvolle support-inbox vertelt hetzelfde verhaal, en het gaat nooit echt over e-mail. Het gaat over een bedrijf dat sneller groeide dan zijn manier om met klanten te praten. Tegen de tijd dat iemand zegt “we hebben een portaal nodig”, is de inbox meestal geen hulpmiddel meer maar een dagelijkse noodsituatie — een plek waar verzoeken verloren gaan, herhaald worden en tot discussie leiden. Dit is het verhaal van één bedrijf dat precies dat doormaakte, en wat er werkelijk nodig was om eruit te klimmen.
Ik wil het eerlijk vertellen, want casestudy's worden meestal geschreven alsof alles perfect ging en de cijfers van de ene op de andere dag verdrievoudigden. Dat gebeurde hier niet. Het ging goed — echt goed — maar er waren verkeerde afslagen, een functie die we bouwden en daarna weer verwijderden, en een moment na een week of zes waarop de klant zich stilletjes afvroeg of ze een fout hadden gemaakt. Dat deel doet er net zoveel toe als het resultaat, dus ik laat het erin staan.
Het bedrijf bestaat echt, maar is op hun verzoek geanonimiseerd: een zakelijke dienstverlener van zo'n 45 mensen die enkele honderden terugkerende B2B-klanten bedient. Denk aan onderhoud van apparatuur en compliance — het soort werk waarbij klanten voortdurend documenten, statusupdates en het indienen van verzoeken nodig hebben. De details doen er niet zoveel toe. Als uw team in een gedeelde inbox leeft, herkent u de vorm hiervan meteen.
De inbox die het bedrijf runde
Toen we voor het eerst met hen om tafel zaten, liep alles wat belangrijk was via één gedeelde mailbox — info@ — die vier mensen tegelijk in de gaten hielden. Klanten mailden om een dienst aan te vragen, een certificaat te vragen, een opdracht te controleren, een adres te wijzigen, een factuur te betwisten. Alles kwam op dezelfde plek binnen, in willekeurige volgorde, zonder status en zonder eigenaar.
De symptomen waren die ik elke keer zie. Dezelfde vragen kwamen tientallen keren per week binnen — “waar is mijn certificaat”, “wanneer komen jullie”, “kunnen jullie het rapport opnieuw sturen”. Bijlagen raakten kwijt of lagen drie antwoorden diep begraven. Twee medewerkers gaven soms binnen het uur een ander antwoord aan dezelfde klant. En niemand kon de simpelste managementvraag beantwoorden: hoeveel openstaande verzoeken hebben we nu? De inbox wist het niet. Hij wist alleen hoeveel ongelezen berichten er waren, en dat is iets heel anders.
“Een inbox vertelt u hoeveel berichten ongelezen zijn. Hij kan u nooit vertellen hoeveel klanten nog wachten. In dat gat lekt het vertrouwen weg.”
De kosten waren niet alleen tijd, al was daar genoeg van — we schatten later dat het team het grootste deel van twee volledige werkdagen per week kwijt was aan repetitieve, kopieer-plak-antwoorden. De grotere kost was de stille erosie van vertrouwen. Klanten konden hun eigen historie niet zien, dus vroegen ze opnieuw. Medewerkers konden niet zien wat er beloofd was, dus verontschuldigden ze zich te veel en leverden ze te veel. De hele relatie draaide op onrust.

Wat we bewust niet deden
De klant kwam bij ons met de vraag om een portaal, en onze eerste taak was hen af te remmen. Het is verleidelijk om ja te zeggen tegen de opdracht en meteen schermen te gaan bouwen. Maar een portaal is een groot object — inloggen, accounts, rechten, documenten, verzoeken, meldingen — en als je alles tegelijk bouwt, ben je negen maanden verder en lanceer je nog steeds iets waar niemand om vroeg.
Dus vóór enig ontwerp deden we twee dagen het onglamoureuze werk: de inbox lezen. We exporteerden een paar maanden mail en sorteerden die op wat klanten eigenlijk probeerden te doen. Niet wat ze zeiden — wat ze wilden. Het resultaat was verhelderend. Ongeveer driekwart van alle inkomende e-mail viel samen in slechts vier terugkerende taken: een document aanvragen, de status van een opdracht controleren, een nieuw serviceverzoek indienen en de eigen gegevens bijwerken.
Dit is het deel dat teams overslaan, en het is het deel dat het project redt. We ontwierpen geen portaal. We ontwierpen een manier om de vier meest herhaalde e-mails uit de inbox te halen. Die framing hield ons eerlijk telkens als iemand “nog één” functie wilde toevoegen.
Wat we werkelijk bouwden
De eerste release was bewust smal. Een klant kon inloggen, de opdrachten en documenten van de eigen organisatie zien, alles downloaden wat we ooit hadden gestuurd, een nieuw verzoek indienen via een kort gestructureerd formulier en de contactgegevens bijwerken. Dat was het. Geen livechat, geen dashboards vol grafieken, geen facturatieportaal. Vier taken, netjes uitgevoerd.
De documentkluis
De grootste verlichting was klanten hun eigen documenten laten ophalen. Elk certificaat, rapport en elke factuur die we uitgaven, werd nu automatisch aan hun account gekoppeld op het moment dat het werd gegenereerd. De e-mail “kunnen jullie die pdf opnieuw sturen” — veruit de meest voorkomende — hield gewoon op met binnenkomen. Klanten vroegen niet meer, omdat het niet meer hoefde.
Gestructureerde verzoeken in plaats van vrije-tekst-e-mail
Wanneer een klant een verzoek indiende via het portaal, beantwoordde hij een paar specifieke vragen in plaats van een alinea te schrijven. Dat klinkt klein; het was ingrijpend. Een gestructureerd verzoek komt binnen met alles wat het team nodig heeft om te handelen — geen drie e-mails heen en weer meer om erachter te komen welke locatie, welke machine, welke datum. Elk verzoek kreeg een status die de klant kon zien, wat het meeste “nog een update?”-najagen stilletjes de kop indrukte.
De stille automatisering erachter
Achter de schermen zat het echte werk in het koppelen van het portaal aan de systemen die ze al hadden, zodat niemand iets hoefde over te typen. Een nieuw portaalverzoek maakte een opdracht aan in hun bestaande backoffice-tool. Een afgerond document belandde vanzelf in de kluis. Statuswijzigingen zetten een korte e-mail in gang, zodat klanten niet steeds hoefden in te loggen om te controleren. Niets hiervan was flitsend. Het meeste van de waarde in zo'n portaal zit in de leidingen die niemand ooit ziet.

De verkeerde afslag en de functie die we verwijderden
Nu het deel dat de meeste casestudy's verbergen. Ongeveer halverwege vroeg de klant om een berichtendraad in het portaal — een klein chatje bij elk verzoek zodat klanten en medewerkers binnen het portaal heen en weer konden praten. Het klonk redelijk. We bouwden het.
Het was een fout. De berichtendraad recreëerde precies het probleem dat we oplosten: een ongestructureerde plek waar gesprekken zich opstapelden, alleen was het nu een tweede inbox die medewerkers naast e-mail moesten bijhouden. Binnen een maand liepen verzoeken vast in chatdraden, waren klanten in de war of ze moesten berichten of mailen, en controleerde het team twee plekken in plaats van één. We hadden per ongeluk de mailbox binnen het portaal herbouwd.
Werkende software verwijderen waar u voor betaald heeft, voelt vreselijk. Maar de verkeerde functie lanceren en die uit koppigheid behouden is veel duurder. We schrapten het, de ruis daalde meteen, en het werd een van de nuttigste dingen die het project iedereen leerde.
Hoe we het uitrolden zonder oproer
Een portaal werkt alleen als klanten het daadwerkelijk gebruiken — en klanten verzetten zich heerlijk tegen het veranderen van hoe ze u bereiken. Zeg mensen “gebruik nu het portaal” en een flink aantal blijft gewoon mailen. Dus we forceerden het niet. We maakten het portaal het duidelijk makkelijkere pad en lieten het vanzelf winnen.
- 1Zachte start met vriendelijke klanten eerstWe nodigden een tiental van de meest betrokken klanten uit, keken hoe ze het gebruikten en poetsten de ruwe randjes weg voordat iemand anders het zag.
- 2Elk account vullen met echte waardeVanaf dag één bevatte het portaal van elke klant al hun eerdere documenten en openstaande opdrachten. Inloggen voelde meteen nuttig, niet als een leeg formulier om in te vullen.
- 3Herhaalde e-mails beantwoorden met een vriendelijk duwtjeAls de oude vragen nog per e-mail binnenkwamen, beantwoordden medewerkers ze — en voegden één zin toe: 'U kunt dit ook altijd hier ophalen.' Geen druk, gewoon een betere optie.
- 4Pas later nieuwe verzoeken via het portaal leidenZodra het gebruik gezond was, verwees het aanvraagformulier op de website naar het portaal. We schakelden e-mail nooit helemaal uit — we maakten het portaal alleen het pad van de minste weerstand.
Dat laatste punt is het waard om bij stil te staan. We stopten nooit met e-mail, en dat waren we ook niet van plan. Sommige klanten geven er altijd de voorkeur aan, en dat is prima. Het doel was nooit nul e-mails — het was om de repetitieve e-mails uit de inbox te draineren, zodat wat overbleef juist die e-mails waren die echt een mens nodig hadden.
De resultaten, met de eerlijke kanttekeningen
Zes maanden na de lancering was de verandering duidelijk genoeg dat niemand er nog over discussieerde. Ik geef u de cijfers, maar lees ze als illustratief — het is de ervaring van dit bedrijf, ruw gemeten, geen belofte. Uw resultaten zullen verschillen.
| Wat we volgden | Voor | Na |
|---|---|---|
| Repetitieve 'opnieuw sturen / status'-e-mails | Tientallen per dag | Een handvol per dag |
| Tijd aan kopieer-plak-antwoorden | ~2 dagen/week | Minder dan een halve dag/week |
| Documentaanvragen per e-mail | Het meest voorkomende e-mailtype | Vrijwel verdwenen |
| Openstaande verzoeken zichtbaar voor managers | Onkenbaar | Live in één oogopslag |
| Klanten die 'waar is het?' najagen | Constant | Zeldzaam |
De kop waar de klant om gaf, was de teruggewonnen tijd: het team kreeg het grootste deel van anderhalve dag per week terug die in de inbox verdween. Ze verkleinden het personeelsbestand niet — ze zetten die tijd in op het eigenlijke servicewerk en op het onboarden van nieuwe klanten, precies de uitkomst die we bijna altijd zien in kleine en middelgrote bedrijven. Automatisering verving hier geen mensen; het gaf hun hun week terug.
De zachtere winst was lastiger te meten maar makkelijk te voelen. Managers konden het werk eindelijk zien. Klanten hadden niet langer het gevoel dat ze in een leegte schreeuwden. En de inbox werd, voor het eerst in jaren, een rustige plek waar de binnenkomende berichten juist die waren waar een mens over moest nadenken.
“We kwamen niet op nul e-mails. We kwamen op nul zinloze e-mails — en dat bleek het getal dat ertoe deed.”

Wat we de volgende keer anders zouden doen
Twee dingen. Ten eerste zouden we de berichtenfunctie vanaf het begin afhouden — we wisten het beter en bouwden het toch, omdat ja zeggen makkelijker voelde dan het gesprek. Ten tweede zouden we klantaccounts nog eerder in de bouw vullen met hun historie, want het moment dat een portaal gevuld en persoonlijk voelt, is het moment dat mensen het gaan vertrouwen. Een leeg portaal is een klus; een portaal dat u al kent, is een verademing.
Als u naar uw eigen overvolle inbox staart, is de conclusie niet “bouw een portaal”. Het is vind eerst uw vier taken. Lees uw inbox zoals wij de hunne lazen. Het handvol dingen waar uw klanten steeds opnieuw om vragen, zijn de enige functies die ertoe doen. Al het andere is scope die u blij zult zijn te hebben weggelaten.
Verdrinkt u elke week in dezelfde e-mails?
Als uw team in een gedeelde inbox leeft en steeds dezelfde vragen beantwoordt, is een gericht klantportaal vaak de oplossing — goed gedaan, klein gehouden. Laten we samen naar uw vier taken kijken en bepalen wat écht de moeite waard is om te bouwen.
Bekijk hoe we klantportalen bouwenVeelgestelde vragen
Hoelang duurt het bouwen van een selfserviceportaal voor klanten?
Gaan klanten echt een portaal gebruiken in plaats van gewoon te mailen?
Moeten we onze bestaande software vervangen om een portaal toe te voegen?
Betekent een selfserviceportaal dat we supportmedewerkers moeten schrappen?
Hoe weten we of we klaar zijn voor een portaal?

Have a nice day is een softwarestudio die kleine en middelgrote bedrijven helpt digitaliseren — automatisering, AI en maatwerksoftware die werkt in de dagelijkse praktijk, niet alleen op slides.