waarom ik een agent-native crm bouwde

Veertien keer heb ik een enterprise-CRM van de eerste workshop tot live gebracht. Veertien keer van begin tot eind. En veertien keer zo’n beetje hetzelfde liedje: een implementatietraject van maanden, een prijs per gebruiker, en een laag consultants tussen de mensen die de software bouwen en de mensen die er straks mee moeten werken.

Ik was er zelf een, zo’n consultant. Ben het nog steeds, en ik doe het met plezier. Zit een organisatie met een ingewikkeld proceslandschap, dan klopt dat model ook gewoon: al die complexiteit vraagt om begeleiding, en die systemen kunnen dingen die niks anders kan.

Maar ergens tussen dat eerste en dat veertiende project begon er iets te knagen. Waarom gaat dit eigenlijk overal zo?

het patroon

Kijk eens naar zowat elk zakelijk softwarepakket. Je ziet steeds diezelfde drie bouwstenen terug. Een prijs per gebruiker, die meegroeit met je team, en dus met je succes. Een implementatietraject, want het systeem is te configureerbaar om zelf even op te zetten. En een implementatiepartner ertussen, een tussenlaag die de software helemaal niet zelf heeft gebouwd. De uren om hem werkend te krijgen, die factureert-ie wel.

In het enterprise-segment kan dat allemaal kloppen, hoor. Alleen is dat patroon vervolgens klakkeloos naar beneden gekopieerd. Naar bedrijven waar het nooit voor bedoeld was. Neem een dienstverlener met acht man. Die is bij de gangbare per-user-systemen zo enkele honderden euro’s per maand kwijt, plus nog implementatiekosten aan de start. En voor een installatiebedrijf of een schoonmaakbedrijf dat gewoon grip wil op z’n klanten, planning, offertes en facturen? Dat is geen dienstverlening meer. Dat is een tolpoort.

software codeert een bedrijfsmodel

En hier zit de gedachte die me niet meer losliet. Die drie bouwstenen? Geen van drieën een technische noodzaak. Het zijn keuzes.

Kijk. Een prijs per gebruiker is geen natuurwet. Iemand heeft ooit bedacht dat het geld moest opleveren, en zo werd het een verdienmodel. Dat implementatietraject zit er ook niet omdat het moet. Het zit er omdat de software zo in elkaar steekt dat niemand hem zonder hulp aan de praat krijgt. En die consultantlaag? Een heel ecosysteem dat verdient aan precies die afstand tussen de maker en de gebruiker. Toeval is dat niet.

Elke regel code legt een aanname vast over hoe er verdiend wordt. En zijn het keuzes, dan kun je ook andere keuzes maken.

de omkering

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

De grootste omkering zit in het fundament. Kijk, vrijwel elk systeem plakt er op dit moment AI achteraf bij. Op een product dat er al staat, als een assistentje in de zijbalk. Ik heb het precies andersom gedaan. Vanaf de allereerste regel code is het ding agent-native. De hele besturing loopt via een MCP-laag: je gegevens, custom objects, velden, import, export, alles. Wat een mens in het systeem kan, kan een agent net zo goed. En niet omdat dat er vandaag al spectaculair uitziet, hoor. Daar gaat het me niet om. Het gaat erom dat je mensen de komende jaren steeds vaker met AI-assistenten werken. Dan wil je een systeem dat daar vanaf het begin voor gebouwd is, in plaats van er achteraf op aangepast.

Tweede omkering: één vaste prijs, per organisatie, per maand. Geen prijs per gebruiker dus. Geen setupfee, geen implementatiekosten, geen verborgen posten voor integraties of opslag. Je betaalt dat ene bedrag en verder niks. De rekensom? Die laat ik graag aan de klant zelf over.

Derde omkering: geen consultants meer, de makers doen het zelf. Je zet het systeem zelf op, met een onboarding-agent en een werkinstructie-wizard die je bij elke stap bij de hand nemen. Geen traject, geen tussenlaag. Wie de software bouwt, levert ‘m ook, en zo zit alle kennis op één plek. Precies die afstand die ik in veertien projecten alleen maar groter zag worden: hier haal ik ‘m er gewoon uit.

En dat opzetten? Dat wordt nog directer dan zo’n wizard. Elke eerste omgeving krijgt een onboarding-agent. Die richt met een paar vragen je hele systeem alvast in. Niet alles, natuurlijk. Voor de rest ga je gewoon verder met je eigen agent, via onze MCP-laag. Want alles wat je in fikst kunt instellen, kun je net zo goed via die MCP doen. Tot en met de standaard admin-rol. Een functioneel beheerder zet er zo z’n hele systeem mee op, plus z’n eigen automation-flows. En dat, dat is precies de consultantlaag van hierboven. Die verdampt hier gewoon.

eerlijk over waar het staat

Nu het stukje dat in de meeste productverhalen keurig wordt overgeslagen: dit is jong.

Het systeem staat, en het werkt. Alleen is het nog niet door heel veel echte bedrijven op de proef gesteld. Dat verzwijg ik niet. Sterker nog, ik maak het onderdeel van het aanbod. Die eerste drie klanten? Dat noem ik geen klanten. Het zijn launching partners. Ze krijgen een vaste prijs voor twee jaar en een directe lijn met de bouwer, en in ruil helpen ze mij het systeem scherp te slijpen. Dat vind ik een eerlijker verhaal dan iets als af verkopen wat die belofte nog helemaal niet heeft waargemaakt.

En er loopt een grens, en die benoem ik net zo eerlijk. Heeft een bedrijf een echt complex, loodzwaar proceslandschap? Dan is dat een SAP-traject, en geen klus voor mij. Ik ken allebei die werelden goed genoeg om te weten waar de een ophoudt en de ander begint. En juist dat afbakenen maakt de claim geloofwaardig. Ik weet namelijk precies wat ik wél heel goed kan.

voor wie het nooit gebouwd was

Want daar draait het om, uiteindelijk. Enterprise-software is nooit gemaakt voor dat bedrijf van vijf tot vijftig man dat werk plant en dat uitvoert bij de klant. De installateur, de schoonmaker, de hovenier, de technische dienstverlener. Die kregen altijd een uitgeklede versie van een enterprise-idee. Verdienmodel gewoon meegeleverd.

En die jaren aan de enterprise-kant? Dat is voor mij geen ballast. Dat is juist het bewijs. Ik ken de sales- en serviceprocessen die deze software moet ondersteunen, gewoon omdat ik ze veertien keer op het allerhoogste niveau heb ingericht. Precies dát vertaal ik nu naar de schaal en het budget van het MKB. Het systeem heet fikst. en staat op fikst.app.

En wat me na al die go-lives het meest is bijgebleven, is dit. Gebruikers denken dat ze naar software zitten te kijken. Maar wat ze zien, is het verdienmodel van de maker. Software onthoudt de keuzes van z’n makers, langer nog dan die makers dat zelf doen. En het enige wat ik doe? Bij elke regel code andere keuzes onthouden.