CRM-eisen opstellen: praktische wensenlijst voor het MKB

Begin met het bedrijfsprobleem, niet met CRM-functies

Een wensenlijst begint vaak met woorden als dashboard, automatisering, app en rapportage. Zulke termen klinken concreet, maar vertellen nog niet welk probleem het CRM moet oplossen. Een leverancier kan daardoor een functie aanvinken terwijl de dagelijkse werkwijze nog steeds niet klopt. Begin daarom met de huidige situatie: waar raakt opvolging zoek, welke informatie wordt dubbel ingevoerd, welke beslissing komt te laat en welke overdracht is onduidelijk?

Koppel ieder probleem aan een gewenste uitkomst die medewerkers herkennen. Bijvoorbeeld: iedere nieuwe aanvraag heeft binnen een afgesproken werkproces een eigenaar en volgende actie, of een manager kan zonder handmatig spreadsheet zien welke offertes wachten op reactie. Dit zijn geen garanties over omzet of snelheid. Het zijn bedrijfsdoelen waarmee je later kunt beoordelen of de CRM-inrichting daadwerkelijk bruikbaar is.

Breng eerst gebruikers, processen en beslismomenten in kaart

Noteer wie met het CRM werkt en welke verantwoordelijkheid elke rol heeft. Een verkoper registreert andere informatie dan een projectleider, servicemedewerker of beheerder. Beschrijf per rol welke records zichtbaar zijn, welke acties mogen worden uitgevoerd en wie een wijziging of uitzondering beoordeelt. Daarmee voorkom je dat rechten pas na de bouw als losse technische vraag opduiken.

Loop vervolgens enkele echte scenario’s door: een nieuwe lead, een bestaande klant met een vervolgvraag, een offerte zonder reactie, een contactpersoon die van bedrijf wisselt en een dubbel record. Noteer de trigger, benodigde gegevens, eigenaar, beslissing en verwachte volgende stap. Deze scenario’s vormen de ruggengraat van je CRM-eisen en later van de acceptatietest.

Schrijf iedere belangrijke CRM-eis als een toetsbaar scenario

Gebruik een vaste vorm: als een bepaalde rol in een herkenbare situatie een actie uitvoert, moet het systeem een controleerbare uitkomst geven. “Het CRM moet taken ondersteunen” wordt bijvoorbeeld: “Als een verkoper een offerte verstuurt, kan die persoon een opvolgdatum vastleggen en ziet de eigenaar de open taak op de afgesproken dag.” Daarmee wordt duidelijk wie handelt, welke informatie nodig is en wat je tijdens een demo moet kunnen zien.

Voeg alleen voorwaarden toe die nodig zijn om de uitkomst te beoordelen. Denk aan verplichte velden, toegestane statussen, zichtbaarheid per rol en gedrag bij ontbrekende data. Vermijd tegelijk dat je elk scherm vooraf ontwerpt. Een goede eis legt de gewenste werking vast, terwijl er ruimte blijft om een passende standaardinrichting of maatwerkoplossing voor te stellen. Werk je een geselecteerd scenario verder uit voor de bouw, gebruik dan het ingevulde voorbeeld van een functioneel ontwerp om ook invoer, bedrijfsregels en uitzonderingen vast te leggen.

Scheid must-haves, randvoorwaarden en latere wensen

Wanneer alles prioriteit één krijgt, kan niets echt richting geven. Deel de lijst daarom minimaal op in direct noodzakelijk, harde randvoorwaarde, later waardevol en bewust buiten de eerste scope. Een must-have ondersteunt een kernproces dat op de eerste werkdag moet functioneren. Een randvoorwaarde begrenst de oplossing, zoals een noodzakelijke gegevensbron, rolverdeling of exportmogelijkheid. Een latere wens mag de eerste release niet blokkeren.

Noteer bij iedere hoge prioriteit waarom die indeling nodig is. “Moet kunnen koppelen” is onvoldoende. Schrijf met welk systeem, welke gegevens, in welke richting en voor welk proces. Als de onderbouwing ontbreekt, is het vaak een algemene voorkeur in plaats van een harde eis. Door ook uitgesloten onderdelen op te schrijven, voorkom je dat een offerte of implementatie ongemerkt steeds breder wordt.

Wie liever een bekende methode gebruikt, kan MoSCoW toepassen: Must, Should, Could en Won’t have this time. Het Agile Business Consortium geeft daarbij een bruikbare toets voor een must-have: wat gebeurt er als deze eis niet wordt gehaald? Als er nog een omweg bestaat, ook een handmatige en lastige, is het volgens die methode geen must-have maar een should- of could-have. Die vraag haalt veel schijnzekerheid uit een CRM-wensenlijst.

Leg data, eigenaarschap en migratiegrenzen expliciet vast

Bepaal welke kerngegevens het CRM moet bevatten, waar ze nu staan en welk systeem voor elk gegeven leidend blijft. Denk aan bedrijven, contactpersonen, aanvragen, offertes, activiteiten en toestemmings- of voorkeurgegevens waar die binnen het echte proces relevant zijn. Benoem wie datakwaliteit controleert en wie een fout record mag aanpassen of samenvoegen.

Maak ook de migratiegrens zichtbaar. Niet alle historische notities, bijlagen en oude statussen hoeven automatisch mee. Beschrijf welke historie gebruikers werkelijk nodig hebben en hoe je een proefimport controleert op aantallen, belangrijke velden en herkenbare dossiers. Hiermee wordt migratie een toetsbaar onderdeel van de scope, zonder foutloze of volledige overdracht te beloven.

Beschrijf koppelingen als gegevensstromen, niet als pakketnamen

Een pakketnaam op een eisenlijst zegt nog niet wat de integratie moet doen. Beschrijf welke gebeurtenis gegevens verstuurt, welke velden meegaan, welk systeem leidend is en wat er gebeurt bij een fout of dubbel record. Voor een websitekoppeling kan dat betekenen dat een geldig formulier een nieuwe aanvraag met bron en eigenaar aanmaakt, terwijl een bestaand contact niet als duplicaat wordt toegevoegd.

Maak onderscheid tussen een koppeling die noodzakelijk is voor de eerste werkdag en een uitbreiding die later kan volgen. Controleer ook wie toegang, wijzigingen en storingen beheert. Vraag bij leveranciers niet alleen of een integratie bestaat, maar laat het relevante scenario demonstreren en leg vast welke onderdelen standaard, configureerbaar of apart te bouwen zijn.

Neem beheer, toegang en verandering mee in de CRM-eisen

De eisen stoppen niet bij livegang. Leg vast wie gebruikers, rollen, pipelines, velden en rapportages kan beheren. Vraag hoe gegevens kunnen worden geëxporteerd, hoe wijzigingen worden aangevraagd en welke onderdelen afhankelijk zijn van een leverancier of externe dienst. Dit zijn praktische continuiteitsvragen, geen belofte dat een systeem altijd beschikbaar of zonder risico is.

Beschrijf daarnaast hoe nieuwe wensen worden beoordeeld. Een wijziging krijgt een eigenaar, reden, prioriteit, impact en besluit voor nu of later. Zo blijft de eisenlijst na de selectie bruikbaar als scope- en beslisdocument. Zonder die discipline groeit een compacte eerste versie alsnog uit tot een verzameling losse verzoeken waarvan niemand de samenhang bewaakt.

Maak van acceptatiecriteria een eerlijke vergelijkingsmethode

Koppel aan iedere kritieke eis één of meer tests met een verwachte uitkomst. Gebruik herkenbare voorbeeldrecords en laat verschillende rollen het scenario uitvoeren. Beoordeel niet alleen het ideale pad, maar ook ontbrekende gegevens, een dubbele klant, een verkeerde status en een gebruiker zonder rechten. Noteer vooraf welk resultaat voldoende is en wie intern akkoord geeft.

Gebruik dezelfde scenario’s bij iedere leverancier. Vraag om een demo op jouw kernflow in plaats van alleen een standaardpresentatie. Registreer per eis of de oplossing standaard voldoet, configuratie vraagt, een bestaande integratie gebruikt, maatwerk vereist of niet past. Daardoor vergelijk je procesfit en uitvoeringsrisico op dezelfde basis, naast totale kosten en implementatieaanpak.

Hoe ziet één volledig uitgewerkte CRM-eis eruit?

Een voorbeeld maakt de vorm concreet. Stel dat offertes nu in een mailbox verdwijnen en niemand ziet welke nog op reactie wachten. Eis 07 kan dan zo worden vastgelegd. Scenario: als een verkoper een offerte verstuurt, legt die persoon in het CRM een opvolgdatum vast, en op die dag staat er een open taak bij de eigenaar van de offerte. Prioriteit: direct noodzakelijk. Reden: zonder deze taak blijft het huidige knelpunt bestaan en heeft de eerste release geen zichtbaar nut. Eigenaar: de commercieel verantwoordelijke.

Voorwaarden: een offerte zonder opvolgdatum kan niet de status verstuurd krijgen, en een taak verhuist mee als de offerte een andere eigenaar krijgt. Buiten scope voor nu: automatische herinneringsmails naar de klant. Acceptatietest: maak een testofferte met opvolgdatum morgen, wissel daarna de eigenaar en controleer of de taak bij de nieuwe eigenaar verschijnt. Probeer ook een offerte zonder datum op verstuurd te zetten; dat moet worden geweigerd met een duidelijke melding.

Vraag iedere leverancier per eis om één van vijf antwoorden: standaard aanwezig, met configuratie, via een bestaande integratie, als maatwerk of niet passend. Bij eis 07 zegt het verschil tussen die antwoorden veel over de werkelijke inspanning. Laat het antwoord tijdens de demo zien met dezelfde testofferte, zodat je niet twee presentaties vergelijkt maar twee uitkomsten op jouw eigen werksituatie.

Bouw een compacte CRM-wensenlijst in negen onderdelen

Een praktisch document kan bestaan uit: doel en huidige knelpunten; gebruikers en rollen; kernscenario’s; gegevens en eigenaarschap; functionele eisen; koppelingen; beheer en toegang; prioriteiten en uitsluitingen; acceptatiecriteria en beslissers. Geef iedere eis een stabiel nummer zodat offerte, vragen, demo en acceptatietest naar hetzelfde punt verwijzen.

Houd per eis een korte toelichting bij met zakelijke reden, prioriteit, eigenaar en bewijs. Een uitgebreid document is niet automatisch beter. De beste lijst maakt de belangrijkste keuzes begrijpelijk voor medewerkers en leveranciers en voorkomt dat algemene wensen als harde scope worden behandeld. Werk hem samen met sleutelgebruikers door en laat verschillen in werkwijze eerst intern beslissen.

Gebruik de eisenlijst voor standaard CRM én CRM op maat

Dezelfde eisen kunnen aantonen dat een standaardpakket prima past, dat gerichte configuratie nodig is of dat een onderscheidende kernflow maatwerk rechtvaardigt. Stuur niet vooraf op de grootste oplossing. Laat zien welke scenario’s standaard worden gedragen, waar medewerkers hun proces moeten aanpassen en welke afwijkingen structureel omwegen of dubbele invoer zouden veroorzaken.

Softora kan tijdens een scopegesprek voor bedrijfssoftware op maat helpen om processen, rollen, databronnen, koppelingen en acceptatiescenario’s scherp te krijgen. Dat garandeert niet dat ieder risico verdwijnt of iedere leverancier hetzelfde antwoord geeft. Het levert wel een controleerbare opdracht op voor een passend standaard CRM of een afgebakend CRM op maat, met een duidelijke route naar begroting en implementatie.