waarom ik een agent-native bedrijfssysteem 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 dat gewoon grip wil op z’n klanten, planning, offertes en facturen? Dat is geen dienstverlening meer. Dat is een tolpoort.

wat er dan gebeurt

En die tolpoort staat er niet één keer, hè. Hij staat er bij elk pakket dat je erbij neemt.

De pakketten die het wél compleet doen, zijn zo duur dat de meeste kleinere bedrijven er niet eens aan beginnen. Dus koop je losse stukken. Een CRM, een boekhoudpakket, iets voor de offertes, iets voor het koudemiddelenlogboek, iets voor de warmteverliesberekening. Elk stuk voor een prijs die je voor dat ene stuk nog best kunt verdedigen.

Zo groei je in een paar jaar naar zes systemen en zes leveranciers, aan elkaar geknoopt met maatwerkkoppelingen. En daar gaat het mis. Zo’n koppeling weet niks van de bedoeling, die verplaatst velden. Verandert er aan één kant iets? Dan valt-ie stil, of hij schrijft stilletjes het verkeerde weg. En dat merk je pas als de factuur er niet uitgaat.

Bij de eerste klant was dat geen theorie. Zes pakketten naast elkaar, en eentje bestond alleen maar om de andere vijf aan elkaar te knopen. Samen kostten ze 14.880 euro per jaar, en dat bedrag komt uit hun eigen administratie. Ze zijn er nu allemaal uit. De hele optelsom staat op fikst.app.

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 installatiebedrijven, van airco en warmtepompen tot elektrotechniek, 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: je betaalt voor je kantoor. Je monteurs kosten niets. In dit vak zit het grootste deel van je team gewoon in de bus, en een prijs per gebruiker belast precies die mensen. Bij de eerste klant zitten er zestien van de tweeëntwintig op de bus. Dus tel ik alleen de mensen op kantoor, vijftig euro per kantoorgebruiker per maand exclusief btw, en dat staat gewoon op de site. Implementatie is er wel. Een vaste prijs die we vooraf afspreken, afhankelijk van de omvang van je team en van wat er overgezet moet worden. En na de livegang is je eerste maand gratis, zonder contract. Pas daarna start je abonnement. De rekensom? Die laat ik graag aan de klant zelf over.

Derde omkering: geen consultantlaag ertussen. De inrichting doe ik zelf, samen met de klant, op de manier waarop dat bedrijf werkt. Dus geen implementatiepartner die de software nooit heeft gebouwd en wel de uren factureert. Wie de software bouwt, levert ‘m ook, en zo zit alle kennis op één plek. Je vraag komt terecht bij degene die de code heeft geschreven. Precies die afstand die ik in veertien projecten alleen maar groter zag worden: hier haal ik ‘m er gewoon uit.

En wil je daarna zelf verder bouwen? Dat kan, 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. Ruim vierhonderd handelingen, altijd binnen de rechten die je hebt. Een functioneel beheerder zet er zo z’n eigen velden en automatiseringen mee op. 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 vijf 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 koeltechnicus, de warmtepompspecialist, 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 een installatiebedrijf. 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.