Ontwerp je CRM en klantportaal rond duidelijke besluiten

Een CRM op maat met klantportaal kan de route van aanvraag naar uitvoering en betaling verbinden. Klanten zien relevante informatie en kunnen afgesproken handelingen uitvoeren; medewerkers houden regie over scope, vrijgave en administratie. De belangrijkste ontwerpkeuze is welke gebruiker op welk moment welk besluit mag nemen.

Die keuze komt vóór het tekenen van een portaal. Een overzicht met offertes en betaalbuttons lijkt compact, maar daaronder liggen verschillende dossiers, documentversies, bevoegdheden en statussen. Door die afzonderlijk te ontwerpen voorkom je dat één algemene status allerlei zakelijke betekenissen krijgt.

Scheid klant, verkoopkans, document en betaling

Begin met een gegevensmodel dat de werkelijke relaties ondersteunt. Een bedrijf kan meerdere contactpersonen en verkoopkansen hebben. Een verkoopkans kan meerdere offerteversies opleveren. Een geaccepteerde opdracht kan verschillende facturen en betalingen krijgen. Dat past niet betrouwbaar in één klantregel met een veld “betaald”.

Een bruikbaar ontwerp maakt minimaal onderscheid tussen:

• De klantorganisatie en de gebruikers die namens die organisatie mogen werken.
• De concrete verkoopkans of opdracht, met eigenaar en afgesproken scope.
• Een offerte met afzonderlijke versies en de beoordeling van een specifieke versie.
• Een factuur of factuurvoorstel, met een verwijzing naar de financiële administratie.
• Een betaalpoging, de vastgestelde betaling en eventuele terugbetalingen.
• Vragen of tickets die aan de juiste opdracht of het juiste document zijn gekoppeld.

De precieze uitwerking verschilt per bedrijf. De kern is dat een wijziging van contactpersoon geen historische offerte overschrijft en een nieuwe betaalpoging niet automatisch een nieuwe factuur veroorzaakt. Voor de basisbegrippen kun je eerst lezen wat een CRM-systeem bijhoudt.

Maak rechten concreet per organisatie en handeling

Een klantgebruiker mag mogelijk voortgang bekijken, maar niet namens het bedrijf een offerte accepteren. Een contactpersoon voor administratie mag facturen downloaden, maar hoeft geen toegang tot inhoudelijke projectbestanden te hebben. Ook intern kunnen een verkoper, projectleider en financieel medewerker verschillende bevoegdheden nodig hebben.

Schrijf daarom per rol op welke dossiers en handelingen toegankelijk zijn. Toegang tot één opdracht geeft geen toegang tot alle opdrachten met een vergelijkbaar ID. De server moet de bevoegdheid beoordelen; alleen een knop verbergen is geen toegangscontrole. Dat sluit aan bij de OWASP-richtlijn om rechten bij iedere aanvraag te controleren.

Bepaal ook wie gebruikers uitnodigt, wie de zakelijke bevoegdheid bevestigt en hoe die wordt ingetrokken. Een werkend e-mailadres bewijst niet vanzelf dat iemand alle besluiten voor een organisatie mag nemen. Leg een proces vast voor wijzigingen van contactpersonen, verloren toegang en vertrek van medewerkers.

Laat goedkeuring naar één zichtbare offerteversie verwijzen

Wanneer een voorstel naar de klant gaat, moet duidelijk zijn welke scope, bedragen, voorwaarden en bijlagen bij die versie horen. Als daarna iets verandert, maak je een nieuwe versie of een expliciet wijzigingsproces. Een oude goedkeuring mag niet stilzwijgend naar nieuwe inhoud verwijzen.

De klant ziet de bedoelde versie en de handeling die wordt vastgelegd. Het systeem bewaart welke bevoegde gebruiker welk besluit nam en op welke versie dat betrekking had. Bij een gelijktijdige wijziging wordt het besluit tegengehouden totdat de actuele inhoud opnieuw is beoordeeld.

Dit is een technische inrichting voor traceerbaarheid, geen algemene uitspraak over juridische geldigheid. De vereiste ondertekening, bewijsvoering en contractuele werking moeten passen bij jullie documenten en situatie. Laat die eisen vooraf vaststellen wanneer ze voor het proces bepalend zijn.

Intern kan daarna een aparte vrijgave nodig blijven: capaciteit is bevestigd, een startvoorwaarde is vervuld of een afwijking is beoordeeld. Offerteacceptatie en opdrachtvrijgave hoeven dus niet dezelfde stap te zijn.

Bereid facturatie voor vanuit goedgekeurde brongegevens

Een CRM kan de benodigde gegevens verzamelen en een factuurvoorstel doorgeven. Bepaal welk pakket leidend blijft voor de definitieve factuur, financiële instellingen en documentnummering. De verantwoordelijke voor de administratie beoordeelt de inrichting van onder meer financiële velden en verwerking.

Maak verschil tussen een voorstel voorbereiden, een document definitief maken en het verzenden. De bevoegdheid voor de ene stap geeft niet automatisch toestemming voor de volgende. Ontbrekende klantreferenties, afwijkende prestaties of een gewijzigde opdracht leiden tot controle, niet tot een stilzwijgende standaardwaarde.

Leg de koppeling tussen opdracht, bronregels en extern document vast. Dan kan een medewerker verklaren waarom een bedrag is voorgesteld en wat al is verwerkt. Bekijk ook de scope van facturatie als onderdeel van een bedrijfsproces.

Een betaalpagina is niet het bewijs van ontvangst

Een klant kan na een betaalpoging terugkeren in het portaal voordat de definitieve status bekend is, of de browser sluiten zonder terug te keren. Laat de status daarom niet afhangen van de pagina die de klant bezoekt.

Bij Mollie beschrijft de documentatie over betaalstatus en fulfilment dat de backend de actuele betaling ophaalt. Het portaal koppelt die betaling vervolgens aan de juiste organisatie, opdracht en factuur. Een ontvangen melding is aanleiding voor verwerking, geen zelfstandig bewijs dat een willekeurig dossier betaald is.

Houd meerdere betaalpogingen apart. Een verlopen poging kan naast een geslaagde poging bestaan. Een betaling kan ook gedeeltelijk aan een openstaand bedrag worden toegewezen wanneer het proces dat ondersteunt. Controleer bedragen en valuta en voorkom dat dezelfde gebeurtenis het saldo twee keer aanpast.

Terugbetalingen krijgen een eigen status en bevoegdheid. Mollie biedt hiervoor een refund-API. De aanwezigheid van die functie betekent niet dat iedere portaalgebruiker een terugbetaling mag starten of dat aanvragen direct definitief zijn verwerkt.

Vergelijk de administraties, ook zonder foutmelding

Naast verwerking van gebeurtenissen is een controleoverzicht nodig. Welke facturen staan open, welke betalingen zijn ontvangen maar nog niet toegewezen, en welke terugbetalingen wachten op een definitieve uitkomst? Een ontbrekende gebeurtenis hoeft geen technische foutmelding te veroorzaken.

Laat daarom periodiek vaststellen of de eigen status aansluit op de betaalprovider en de financiële administratie, voor zover de beschikbare gegevens dat toelaten. Een verschil krijgt een eigenaar en een herstelroute. De klant ziet een passende tussenstatus zolang de uitkomst niet vaststaat.

Acceptatie vraagt ook om onhandige scenario’s

Laat vóór ingebruikname de volledige route testen met representatieve testgegevens. Naast een normale opdracht horen deze gevallen erbij:

• Een klant probeert met een gewijzigd dossier-ID gegevens van een andere organisatie te openen.
• Een gebruiker zonder beslisbevoegdheid probeert een offerte te accepteren.
• De offerte wordt gewijzigd terwijl de klant de oude versie open heeft.
• Een factuuraanvraag krijgt een time-out nadat het externe document al is aangemaakt.
• Een betaalmelding komt dubbel of in een andere volgorde binnen.
• Een betaalpoging mislukt, een volgende slaagt en er volgt later een gedeeltelijke terugbetaling.
• Een beheerder trekt toegang in terwijl een gebruiker nog een documentlink heeft.

De acceptatie is niet alleen “geen foutmelding”. Controleer de gegevens, zichtbaarheid, saldo’s en geschiedenis in alle betrokken systemen. Maak duidelijk wie afwijkingen na oplevering oppakt en welke informatie daarbij beschikbaar is.

Een bestaande CRM- of portaalmodule kan deze scope soms ondersteunen. Maatwerk past wanneer essentiële procesregels of bevoegdheden daarmee niet goed te realiseren zijn. Bespreek de gegevens en besluiten bij CRM op maat; voor de betaalverbinding staat de afbakening op Mollie-integraties.