Hoe dat er in de praktijk uitziet.
Neem een installateur van warmtepompen. Vijftien mensen, sterke groei, en alles draait op Excel, mail en Whatsapp.
Stap 1 - Eerst tekenen we uit wie wat doet.
User journey mapping: ons functioneel vertrekpunt
We gaan samenzitten met de mensen die het werk doen en tekenen de stappen uit die ze effectief zetten: van binnenkomende aanvraag, over plaatsbezoek en offerte, tot installatie en oplevering.
Wat daar bovenkomt zijn niet alleen de gewone trajecten, maar ook alle uitzonderingen. Iedereen op kantoor kent die, maar ze staan nergens beschreven. En dat is precies wat er in je huidige processen fout loopt.

Waarom staan die capabilities erbij? Steeds vaker doen de AI-agents het echte werk. De fases blijven dan exact dezelfde; alleen de interactie verandert. Daarom benoemen we per fase of er een scherm nodig is, en/of een capability waar een agent mee kan werken.
Stap 2 - Dan leggen we vast wat er echt gebeurt.
Event sourcing: onze technische architectuur
Op basis van deze tekening bepalen we wat er moet bijgehouden worden over elke stap.
In plaats van alleen de huidige stand van zaken bij te houden — dit dossier staat op “in wacht” — leggen we elke gebeurtenis vast als een feit dat gebeurd is. Offerte verstuurd. Plaatsbezoek ingepland. Premie goedgekeurd. Materiaal besteld. Zoals een bank die elke transactie bijhoudt in plaats van enkel je saldo.

Stap 3 - En dan verandert er iets.
Het moment waarop je merkt dat je software vertrekt vanuit een model.
Zes maanden later beslist de zaakvoerder: we bestellen geen materiaal meer voor de premie is goedgekeurd. Te veel voorschotten die blijven hangen.
Bij klassieke maatwerksoftware is dat een change request, een offerte, en twee maanden wachten. Want die regel zit ergens verweven in code die intussen gegroeid is. Bij ons is het een aanpassing aan het model: er komt een voorwaarde bij tussen twee gebeurtenissen. De software volgt automatisch.

Eindelijk software die mee evolueert met je bedrijf.