CRM implementatie: standaard pakket of maatwerk?
Standaard is niet automatisch goedkoper en maatwerk is niet automatisch duurder. De keuze hangt af van je processen, je bereidheid tot onderhoud en wat je over vijf jaar wilt kunnen.
De keuze die je vóór de implementatie maakt
De meeste CRM-projecten die vastlopen, lopen niet vast op de techniek. Ze lopen vast op een keuze die aan het begin te snel is gemaakt: een pakket kiezen omdat het bekend is, of maatwerk kiezen omdat een pakket te duur leek. Beide redenen zeggen niets over de vraag die er echt toe doet.
Die vraag is: hoe uniek is het proces dat je wilt ondersteunen, en hoeveel ben je bereid te investeren om het draaiende te houden? Dit artikel helpt je die twee vragen te beantwoorden voordat je een offerte aanvraagt.
De hardnekkigste misvatting
Een standaardpakket wordt vaak gepresenteerd als de veilige, voorspelbare keuze en maatwerk als het dure avontuur. In de praktijk is dat beeld niet compleet.
Een Salesforce-implementatie kost óók veel tijd om in te richten. Objecten, velden, rechten, flows, rapportages, integraties, gebruikersadoptie: dat is werk, en het houdt niet op na livegang. Elke release, elk nieuw proces en elke nieuwe collega vraagt onderhoud. Die kosten zitten alleen niet in de licentie, dus je ziet ze minder goed.
Maatwerk maakt dezelfde kosten zichtbaar in één factuur. Dat voelt duurder, maar het is vooral eerlijker zichtbaar. De echte vraag is niet welke optie goedkoper lijkt, maar welke optie over vijf jaar het minst kost aan geld én aandacht.
Standaard is niet automatisch goedkoper. Maatwerk is niet automatisch duurder. Het verschil zit in waar de kosten zichtbaar worden.
Wanneer een standaardpakket de juiste keuze is
Een pakket als Salesforce levert je decennia aan doordacht productwerk. Dat is een enorme voorsprong, en je krijgt hem op de dag dat je begint.
- Je processen lijken in de kern op die van andere organisaties: leads, offertes, orders, klantvragen.
- Je hebt behoefte aan een ecosysteem: koppelingen, apps, gecertificeerde specialisten en een arbeidsmarkt die het systeem kent.
- Je wilt niet afhankelijk zijn van één leverancier of één ontwikkelaar voor doorontwikkeling.
- Compliance-eisen en certificeringen zijn belangrijk en je wilt die niet zelf hoeven aantonen.
- Je organisatie groeit snel en je weet nog niet precies waar je over twee jaar staat.
Het grote voordeel van standaard is niet de prijs. Het is dat je een bewezen fundament krijgt waar duizenden organisaties de scherpe randjes al vanaf hebben gesleten.
Wanneer maatwerk zinnig is
Maatwerk verdient zich terug wanneer je proces zelf het onderscheidende vermogen is. Niet wanneer je alleen goedkoper uit wilt zijn.
- Je kernproces wijkt wezenlijk af van wat pakketten ondersteunen, en dat verschil is precies waarom klanten voor je kiezen.
- Je vecht met een pakket dat je meer beperkt dan helpt, en de workarounds worden zelf een beheerlast.
- Het zwaartepunt ligt op koppelingen en dataverwerking, waarbij het CRM vooral een schil rond bestaande systemen is.
- Je hebt een klein team dat maar een fractie van een pakket gebruikt, terwijl je wel voor het geheel betaalt.
- Je bent bereid het bij te houden: budget en aandacht reserveren voor doorontwikkeling, niet alleen voor de bouw.
Wanneer maatwerk juist niet moet
Als niemand in je organisatie eigenaar wil zijn van het systeem, kies dan geen maatwerk. Een pakket blijft draaien als je even niet oplet; maatwerk dat niemand onderhoudt, verandert binnen twee jaar in een blok aan het been. Dat is de belangrijkste reden waarom maatwerkprojecten mislukken, en die reden is organisatorisch, niet technisch.
De rekensom die je zelden ziet
Licenties zijn terugkerende kosten en die tellen hard op. Een team van twintig mensen op Salesforce Enterprise betaalt in vijf jaar meer dan €200.000 aan licenties alleen, nog voor er één uur inrichting is gedaan.
Dat is geen argument tegen Salesforce, want daar krijg je veel voor terug. Het is een argument om de vergelijking eerlijk te maken: zet de terugkerende licentiekosten naast de eenmalige bouwkosten plus jaarlijks onderhoud, over dezelfde periode.
Reken het door voor je eigen situatie:
Wat kosten Salesforce-licenties jou?
Lijstprijzen per gebruiker per maand, doorgerekend over meerdere jaren.
Gepubliceerde lijstprijzen van Salesforce in euro's, per gebruiker per maand. Enterprise en hoger worden jaarlijks gefactureerd. Werkelijke prijzen liggen na onderhandeling vaak lager, en inrichting, migratie en beheer zitten er niet in. Prijzen gecontroleerd op 2026-08-03.
Bij maatwerk verschuift het zwaartepunt naar de start: je betaalt de bouw in het eerste jaar en daarna hosting en onderhoud. Bij een pakket betaal je elk jaar hetzelfde bedrag, ongeacht hoeveel je ervan gebruikt. Welke curve gunstiger uitpakt, hangt af van je aantal gebruikers en je horizon.
Kosten die in beide gevallen worden vergeten
- Inrichting en configuratie, vaak een veelvoud van de licentiekosten in jaar één.
- Datamigratie en het opschonen van bestaande data.
- Training en adoptie: een systeem dat niemand gebruikt, kost alleen maar.
- Doorlopend beheer: nieuwe wensen, nieuwe collega's, wijzigende processen.
- Integraties met je andere systemen, inclusief het onderhoud daarvan.
Kun je met AI een veilige CRM-applicatie bouwen?
Sinds AI-assistenten hele applicaties kunnen genereren, is bouwen goedkoper en sneller geworden. Dat is echt zo, en het verandert de rekensom hierboven. Maar het roept een terechte vraag op: is wat er uitkomt veilig genoeg voor klantdata?
Het eerlijke antwoord is: het kan, maar niet vanzelf. Een AI genereert code die werkt. Werkende code is niet hetzelfde als veilige code, en het verschil is voor een leek onzichtbaar. Een formulier dat data opslaat werkt prima, ook als iedereen op internet die data kan uitlezen.
Waar het in de praktijk misgaat is opvallend consistent: de database staat open voor iedereen met de publieke sleutel, API-endpoints controleren niet wie de aanvraag doet, geheimen belanden in de frontend, en er zit geen rem op het aantal aanvragen. Stuk voor stuk problemen die je niet ziet door de applicatie te gebruiken.
AI verlaagt de drempel om te bouwen, niet de eis om het goed te beveiligen. Wie dat verschil niet kent, levert een applicatie op die werkt tot het moment dat iemand ernaar kijkt.
Wat veilig maatwerk in de praktijk vereist
Dit zijn de maatregelen die wij standaard toepassen op wat we bouwen, waaronder ons eigen trainingsplatform. Ze zijn niet exotisch, maar ze zijn wel het verschil tussen een demo en een productiesysteem.
Autorisatie in de database zelf
Row Level Security zorgt dat de database per rij afdwingt wie wat mag zien. Niet de applicatie bepaalt de toegang, maar de database. Zo lekt er niets, ook niet als er een fout in de frontend zit.
Beveiligde API-endpoints
Elk endpoint controleert wie de aanvraag doet en of die persoon dit specifieke record mag benaderen. Authenticatie zonder autorisatie per record is een veelgemaakte fout.
Rate limiting
Een rem op het aantal aanvragen per gebruiker en per IP-adres. Voorkomt misbruik van formulieren en het leegtrekken van data via herhaalde aanvragen.
Geheimen buiten de frontend
Sleutels en tokens staan in environment variables op de server en komen nooit in code die de browser bereikt. Een sleutel in de frontend is een sleutel die iedereen heeft.
Versleuteling van gevoelige gegevens
Gegevens als toegangstokens slaan we versleuteld op met AES-256-GCM, met een afgeleide sleutel per klant. Bij een datalek is de inhoud daarmee niet bruikbaar.
Veilige koppelingen
Koppelingen met externe systemen verlopen via OAuth met PKCE en state-controle, zodat een onderschepte aanvraag niet herbruikbaar is.
Deze maatregelen zijn geen extraatje aan het eind van een project. Ze bepalen hoe je bouwt vanaf de eerste dag; achteraf inbouwen is duurder dan meteen goed doen.
Hoe je de knoop doorhakt
Loop deze vragen langs. Ze voorspellen de uitkomst beter dan een functionele eisenlijst.
- Is ons kernproces echt anders, of denken we dat alleen omdat we het zo gewend zijn?
- Wie wordt eigenaar van het systeem, met tijd en mandaat, ook over twee jaar?
- Wat gebeurt er als de bouwer of consultant morgen wegvalt?
- Hoeveel van een standaardpakket zouden we daadwerkelijk gebruiken?
- Kunnen we leven met de beperkingen van een pakket, of gaan we ertegenaan werken?
- Wat is onze horizon: drie jaar, of vijftien?
Twijfel je na deze vragen nog, dan is dat zelf een antwoord. Bij twijfel is een standaardpakket meestal de verstandigste keuze, omdat het je de mogelijkheid geeft later alsnog maatwerk toe te voegen. Andersom is veel moeilijker.
Wat wij anders doen dan andere Salesforce implementatie partners
De meeste implementatiepartners verkopen één antwoord, omdat ze één product kennen. Wij doen zowel Salesforce-implementaties als maatwerkontwikkeling, en dat maakt het advies vooraf eerlijker: we hebben geen belang bij een bepaalde uitkomst.
Vaker dan je zou verwachten is het advies om géén maatwerk te doen. Een pakket dat goed is ingericht, verslaat maatwerk dat niemand onderhoudt.
Bouwen we wel maatwerk, dan doen we dat op Next.js, Supabase, Vercel en Resend: volwassen technologie waar veel ontwikkelaars mee overweg kunnen. Dat is een bewuste keuze, want het beperkt je afhankelijkheid van ons.
Veelgestelde vragen
Is maatwerk goedkoper dan Salesforce?+
Soms, maar niet per definitie. Bij weinig gebruikers en een afwijkend proces kan maatwerk over vijf jaar gunstiger uitpakken, omdat je geen licenties per gebruiker betaalt. Bij veel gebruikers met standaardprocessen wint een pakket vrijwel altijd, omdat je de ontwikkelkosten deelt met alle andere klanten van die leverancier.
Hoe lang duurt een CRM-implementatie?+
Voor een standaardpakket met een afgebakende scope reken je op enkele weken tot enkele maanden, afhankelijk van datamigratie en integraties. Maatwerk begint doorgaans later met opleveren maar levert dan wel precies je eigen proces. In beide gevallen is de doorlooptijd vooral afhankelijk van hoe snel jouw organisatie knopen doorhakt.
Wat gebeurt er als de bouwer van ons maatwerk wegvalt?+
Dat is het belangrijkste risico van maatwerk en de reden om te kiezen voor gangbare technologie, leesbare code en documentatie. Wij bouwen op een stack die veel ontwikkelaars beheersen en je krijgt de broncode. Vraag daar bij elke maatwerkpartij naar; als het antwoord vaag is, is dat een waarschuwing.
Is een maatwerkapplicatie veilig genoeg voor klantgegevens?+
Dat hangt volledig af van hoe hij gebouwd is. Autorisatie in de database, beveiligde endpoints, rate limiting, geheimen op de server en versleuteling van gevoelige gegevens zijn het minimum. Een pakket levert dit standaard mee; bij maatwerk moet je het expliciet eisen en laten aantonen.
Kunnen we later nog overstappen van maatwerk naar een pakket?+
Ja, maar reken op een migratietraject: data overzetten, processen opnieuw inrichten, gebruikers opnieuw meenemen. Andersom, van pakket naar maatwerk, is meestal eenvoudiger omdat je data gestructureerd is. Dat is een reden om bij twijfel met een pakket te beginnen.
Kunnen we het combineren?+
Vaak is dat de beste uitkomst. Salesforce voor sales en service, waar het sterk in is, en een maatwerkschil voor het proces dat je uniek maakt, gekoppeld via API's. Je betaalt dan alleen licenties voor wie het pakket echt gebruikt.
Hulp bij de keuze of de bouw?
Twijfel je tussen standaard en maatwerk?
In een vrijblijvend gesprek van 30 minuten kijken we naar je processen en geven we een eerlijk advies, ook als dat betekent dat je ons niet nodig hebt.