waarom ik een agent-native crm bouwde

Veertien keer heb ik een enterprise-CRM van eerste workshop tot live gebracht. Veertien full-cycle projecten, en veertien keer grotendeels hetzelfde ritueel: een implementatietraject van maanden, een prijs per gebruiker, en een laag consultants tussen de mensen die de software maken en de mensen die ermee moeten werken.

Ik was zelf een van die consultants. Ik ben het nog steeds, en ik doe dat werk met plezier. Voor een organisatie met een complex proceslandschap is dat model verdedigbaar: die complexiteit vraagt om begeleiding, en die systemen kunnen dingen die niets anders kan.

Maar ergens tussen het eerste en het veertiende project begon een vraag te knagen. Waarom is dit eigenlijk overal zo?

het patroon

Kijk naar vrijwel elk zakelijk softwarepakket en je ziet dezelfde drie bouwstenen terug. Een prijs per gebruiker, die meegroeit met je team en dus meegroeit met je succes. Een implementatietraject, omdat het systeem te configureerbaar is om zelf op te zetten. En een implementatiepartner als tussenlaag, die de software niet gebouwd heeft maar wel de uren factureert om hem werkend te krijgen.

In het enterprise-segment kan dat kloppen. Het probleem is dat het patroon klakkeloos naar beneden is gekopieerd, naar bedrijven waar het nooit voor bedoeld was. Een dienstverlenend bedrijf met acht medewerkers betaalt bij gangbare per-user-systemen al snel enkele honderden euro’s per maand, plus implementatiekosten bij de start. Voor een installatiebedrijf of schoonmaakbedrijf dat gewoon grip wil op klanten, planning, offertes en facturen is dat geen dienstverlening. Dat is een tolpoort.

software codeert een bedrijfsmodel

Hier zit de gedachte die me niet meer losliet: die drie bouwstenen zijn geen technische noodzaak. Het zijn keuzes.

Een prijs per gebruiker is geen natuurwet, het is een verdienmodel. Een implementatietraject is geen natuurwet, het is het gevolg van software die zo is gebouwd dat niemand hem zonder hulp kan inrichten. De consultantlaag is geen natuurwet, het is een ecosysteem dat verdient aan precies die afstand tussen maker en gebruiker.

Elke regel code codeert een aanname over hoe er verdiend wordt. En als het keuzes zijn, kun je andere keuzes maken.

de omkering

Dus dat heb ik gedaan. Ik bouw een bedrijfssysteem voor dienstverlenende MKB-bedrijven, en ik heb elk van die drie bouwstenen omgedraaid.

De grootste omkering zit in het fundament. Vrijwel elk systeem plakt op dit moment AI achteraf op een bestaand product, als assistentje in de zijbalk. Ik heb het andersom gebouwd: het systeem is vanaf de eerste regel code agent-native. De volledige besturing, van gegevens en custom objects tot velden, import en export, loopt via een MCP-laag. Alles wat een mens in het systeem kan, kan een agent ook. Niet omdat dat vandaag al spectaculair oogt, maar omdat je medewerkers de komende jaren steeds vaker met AI-assistenten gaan werken, en het systeem daarvoor gebouwd moet zijn in plaats van erop aangepast.

De tweede omkering: één vaste prijs per organisatie per maand. Geen prijs per gebruiker, geen setupfee, geen implementatiekosten, geen verborgen posten voor integraties of opslag. Je betaalt dat bedrag, en verder niets. Ik laat de rekensom graag aan de klant zelf over.

De derde omkering: geen consultants, de makers zelf. Je zet het systeem zelf op met een onboarding-wizard en een werkinstructie-wizard die je door elke stap leiden. Geen traject, geen tussenlaag. Wie de software bouwt, levert hem ook, en de kennis zit op één plek. Precies de afstand die ik in veertien projecten heb zien groeien, is hier weggehaald.

eerlijk over waar het staat

Nu het deel dat in de meeste productverhalen ontbreekt: dit is jong.

Het systeem is gebouwd en werkt, maar het is nog niet door veel echte bedrijven getest. Dat verzwijg ik niet, ik maak het onderdeel van het aanbod. De eerste drie klanten zijn geen gewone klanten maar launching partners: ze krijgen een vaste prijs voor twee jaar en een directe lijn met de bouwer, en in ruil helpen ze mee het systeem scherp te krijgen. Dat is een eerlijker verhaal dan een product als af verkopen dat die belofte nog niet bewezen heeft.

En er is een grens die ik net zo eerlijk benoem. Heeft een bedrijf een complex, zwaar proceslandschap, dan is dat een SAP-traject en geen traject voor mij. Ik ken beide werelden goed genoeg om te weten waar de ene ophoudt en de andere begint. Juist die afbakening maakt de claim geloofwaardig: ik weet wat ik wél heel goed doe.

voor wie het nooit gebouwd was

Want daar draait het uiteindelijk om. Enterprise-software is nooit gebouwd voor het bedrijf met vijf tot vijftig mensen dat werk plant en uitvoert bij klanten. Voor de installateur, de schoonmaker, de hovenier, de technische dienstverlener. Die bedrijven kregen altijd een afgeslankte versie van een enterprise-gedachte, inclusief het bijbehorende verdienmodel.

Mijn jaren aan de enterprise-kant zijn daarbij geen ballast maar het bewijs. Ik ken de sales- en serviceprocessen die deze software moet ondersteunen, omdat ik ze veertien keer op het hoogste niveau heb ingericht. Dat vertaal ik nu naar de schaal en het budget van het MKB. Het systeem heet fikst. en staat op fikst.app.

Wat me na al die go-lives is bijgebleven, is dit: gebruikers denken dat ze tegen software aankijken, maar ze kijken tegen het verdienmodel van de maker aan. Software onthoudt de keuzes van zijn makers, veel langer dan de makers zelf. Het enige wat ik doe, is bij elke regel code andere keuzes onthouden.