AI architecture voor Revenue Intelligence

De architectuur van een Revenue Intelligence-systeem bestaat uit lagen die elk één taak hebben: koppelingen die data uit CRM, facturatie en ERP lezen, een gemeenschappelijk datamodel dat klanten, contracten en facturen aan elkaar verbindt, een laag met vaste definities en regels, modellen die afwijkingen vinden en voorspellen, taalmodellen en agents die uitleggen en handelen, en daaromheen privacy, rechten, goedkeuring en een logboek. De AI-modellen zijn het kleinste deel. Of het systeem betrouwbaar is, wordt bepaald door het datamodel, de rechten en de controles eromheen.

Waarom architectuur hier belangrijker is dan het model

Bij Revenue Intelligence gaat het om geld. Een bevinding als "deze klant betaalt EUR 3.800 per jaar te weinig" moet kloppen, anders stuur je een klant een onterechte correctie of mis je een echt lek. Dat vraagt om een systeem waarin je van elk getal kunt zien waar het vandaan komt, welke stappen het heeft doorlopen en wie het heeft goedgekeurd.

Een losse chatbot op je CRM kan dat niet. Een goed opgebouwde architectuur wel. In het overzichtsartikel hoe werkt AI binnen Revenue Intelligence staan de lagen vanuit wat ze doen. Hier gaat het om hoe ze technisch in elkaar zitten en welke keuzes je daarin maakt.

De lagen op een rij

Koppelingen: lezen, niet overnemen

De eerste laag haalt data op uit de systemen die je al hebt: Salesforce, HubSpot of Pipedrive voor deals, Exact, AFAS, Twinfield of SAP voor facturen en debiteuren, een documentmap voor contracten, Zendesk of een ander supportsysteem voor tickets. Welke systemen je minimaal nodig hebt, staat in welke systemen moeten worden gekoppeld voor Revenue Intelligence.

Drie keuzes bepalen de kwaliteit van deze laag.

Leesrechten. Voor het vinden van omzetlekken hoeft het systeem niets te wijzigen. Een koppeling met alleen leesrechten kan niets kapot maken, ook niet als een ander deel van het systeem een fout maakt. Schrijfrechten horen apart, in de uitvoeringslaag, en alleen voor wat nodig is.

Incrementeel ophalen. Elke nacht alle facturen van tien jaar opnieuw ophalen is traag en belast je systemen. Een goede koppeling haalt alleen op wat is veranderd sinds de vorige keer, en weet wat te doen als er iets is verwijderd.

Historie bewaren. Een CRM overschrijft de sluitdatum als een verkoper hem aanpast. Voor een forecast en voor het vinden van patronen wil je juist weten dat die datum drie keer is verschoven. De ruwe opslag bewaart daarom elke versie, niet alleen de laatste.

Het gemeenschappelijke datamodel: waar het meeste werk zit

Dit is de laag die het minst zichtbaar is en het meeste bepaalt. Omzetlekkage zit tussen systemen, dus het systeem moet weten welke records in verschillende systemen over hetzelfde gaan.

Een gemeenschappelijk datamodel definieert de kernobjecten, meestal klant, contract, product, order, factuur en deal, en legt per object vast hoe het in elk bronsysteem heet. Klant K-1042 is in het CRM account 00158, in Exact debiteur 20417 en in de contractmap de map "Jansen Bouw". Die vertaling heet identiteitskoppeling, en daar gaan de meeste fouten mis.

Een voorbeeld van wat er dan gebeurt: als twee vestigingen van dezelfde klant als twee klanten worden gezien, lijkt de ene vestiging een klant die sterk krimpt en de andere een nieuwe klant. Het systeem meldt churn die er niet is. Andersom, als twee verschillende klanten met een vergelijkbare naam worden samengevoegd, verdwijnen echte afwijkingen in het gemiddelde.

Goede identiteitskoppeling gebruikt harde sleutels waar die er zijn (KvK-nummer, btw-nummer, een klantnummer dat in beide systemen staat) en stelt de rest voor ter bevestiging. Een model kan voorstellen dat twee records bij elkaar horen; een mens of een vaste regel bevestigt het. Meer over de opbouw van zo'n datamodel lees je in revenue data architecture voor B2B.

Definities: één keer vastleggen wat omzet is

"Omzet" betekent in het CRM iets anders dan in de boekhouding, en "actieve klant" betekent voor sales iets anders dan voor finance. Als elk rapport en elk model zijn eigen definitie gebruikt, krijg je dashboards die elkaar tegenspreken.

Een definitielaag, ook wel semantische laag genoemd, legt elke metric één keer vast: wat telt als gerealiseerde omzet, wanneer is een klant verloren, hoe wordt een creditnota verrekend, op welke datum telt een jaarcontract. Alle regels, modellen, dashboards en taalmodellen gebruiken die ene definitie. Dat voorkomt ook dat een taalmodel een eigen berekening verzint: het vraagt de definitielaag om het getal.

Detectie en voorspelling

Hier draaien de regels en modellen die afwijkingen vinden. Regels voor wat je al kent: gewonnen deal zonder factuur, contract met indexatieclausule zonder prijsstijging. Anomaly detection voor wat afwijkt van het normale patroon. Voorspellende modellen voor kansen op winnen, vertrek en omzet.

De ontwerpkeuze die het meeste uitmaakt: elke uitkomst draagt zijn bron en zijn zekerheid mee. Een bevinding is niet alleen "klant K-1042 betaalt te weinig", maar ook welke factuurregels en welk contract, welke regel of welk model, en hoe zeker. Zonder die metadata is een bevinding niet te controleren, en dus niet te vertrouwen.

Een tweede keuze is wat er gebeurt met bevindingen met een lage zekerheid. Een systeem kan ze tonen met een waarschuwing, of ze helemaal niet publiceren tot er meer bewijs is. Dat tweede heet fail-closed: bij twijfel niets tonen. Het voorkomt dat een dashboard vol halve signalen staat waar niemand meer naar kijkt.

De privacylaag vóór elk taalmodel

Taalmodellen draaien vaak bij een externe partij. Wat je naar zo'n model stuurt, verlaat je eigen omgeving. Voor omzetanalyse is dat meestal niet nodig: het model hoeft niet te weten hoe je contactpersonen heten om een contractclausule te lezen of een bevinding uit te leggen.

Een privacylaag vervangt namen, e-mailadressen, telefoonnummers en andere herleidbare gegevens door tokens voordat iets een model bereikt, en zet ze terug als het antwoord binnen je eigen omgeving wordt getoond. Het model werkt met "contactpersoon T-81 van klant K-1042", jouw gebruiker ziet de echte naam. Hoe dat werkt en waar het lastig wordt, staat in hoe werkt tokenisatie van bedrijfsdata.

Taalmodellen en agents: gereedschap, geen sleutelbos

Een taalmodel of agent krijgt in een goede architectuur geen directe toegang tot de database. Het krijgt een vaste set gereedschappen: "zoek de facturen van deze klant", "geef de contractclausules van dit contract", "bereken de omzet volgens de standaarddefinitie". Elk gereedschap doet één ding, met de rechten die daarbij horen.

Dat heeft twee voordelen. Het model kan niets doen wat niet als gereedschap bestaat. En elk getal dat het model noemt, komt uit een exacte query op de definitielaag, niet uit een gok. Voor vragen over cijfers is dat altijd de juiste route; zoeken in documenten met een taalmodel is voor tekst. Dat onderscheid staat in RAG vs database queries voor bedrijfsdata.

Goedkeuring en uitvoering

Een systeem dat lekken vindt maar niets met ze doet, wordt een rapport dat in een la belandt. Een systeem dat zelf alles aanpast, wordt een risico. De architectuur daartussen: acties worden voorbereid als voorstel, met de bevinding en de bron erbij, en pas uitgevoerd na goedkeuring door iemand met de bevoegdheid daarvoor. Bij goedkeuring schrijft een aparte uitvoeringslaag, met alleen de schrijfrechten die voor die actie nodig zijn, terug naar het bronsysteem.

Voor sommige acties kan de goedkeuring na verloop van tijd vervallen, bijvoorbeeld het aanmaken van een taak in het CRM. Voor andere blijft hij altijd nodig, bijvoorbeeld alles wat een klant bereikt.

Toegang, logboek en monitoring

Toegang. Wie welke klanten, bedragen en bevindingen mag zien, wordt het veiligst in de database zelf afgedwongen, met row-level security, en niet alleen in de applicatie. Dan kan een fout in de voorkant het niet omzeilen.

Logboek. Per stap: welke data werd gelezen, welk model of welke regel een bevinding maakte, wie goedkeurde, wat er werd teruggeschreven. Het logboek staat op een plek waar agents alleen naartoe kunnen schrijven, niet in kunnen wijzigen.

Monitoring. Een koppeling die sinds een update een veld mist, een model waarvan de nauwkeurigheid daalt, een agent die opeens veel meer acties voorstelt. Zonder monitoring merk je dat pas als de cijfers niet meer kloppen. Zie AI monitoring uitgelegd.

Keuzes die je vooraf maakt

Batch of realtime? Voor de meeste omzetlekken is een nachtelijke verwerking genoeg. Een factuur die een dag te laat als afwijking verschijnt, kost niets. Realtime is duurder en complexer, en alleen nodig voor zaken als fraude of voorraad.

Eigen datawarehouse of apart platform? Als je al een datawarehouse hebt, bijvoorbeeld in Snowflake, kun je de onderste lagen daarop bouwen. Het datamodel, de definities, de regels en de controles moet je dan wel zelf maken en onderhouden. Een apart platform brengt die mee, maar je bent afhankelijk van hoe het is ingericht.

Welke modellen waar? Voorspellende modellen draaien vaak prima in je eigen omgeving. Grote taalmodellen meestal niet, en daar hoort de privacylaag voor.

Voor RiOS staat de doelarchitectuur, met leeslaag, tokenisatielaag, row-level security en fail-closed publicatie, op de pagina beveiliging. Het platform is in bèta; de pagina beschrijft het model waarop het wordt gebouwd.

Controlelijst voor een architectuurgesprek

1. Welke koppelingen zijn alleen-lezen, en welke hebben schrijfrechten, onder welk account?
2. Wordt de historie van wijzigingen bewaard, of alleen de laatste stand?
3. Hoe worden klanten over systemen heen gekoppeld, en wie bevestigt twijfelgevallen?
4. Waar zijn de definities van omzet en behoud vastgelegd, en gebruiken alle onderdelen dezelfde?
5. Heeft elke bevinding een bron en een zekerheid, en wat gebeurt er onder de drempel?
6. Wat ziet een taalmodel van je klanten?
7. Kan een agent iets buiten zijn gereedschap om?
8. Wat wordt gelogd, waar, en wie kan het wijzigen?
9. Wie krijgt een alarm als een koppeling of model het slechter gaat doen?

Veelgestelde vragen

Is dit niet gewoon een datawarehouse met AI erop?

Het fundament lijkt erop. Het verschil zit in wat erbovenop komt: vaste definities voor omzet, regels en modellen voor lekken, een privacylaag, gereedschap voor agents, goedkeuring en een logboek. Een datawarehouse zonder die lagen is opslag, geen Revenue Intelligence.

Moet alle data naar één plek?

Voor analyse wel een kopie van de relevante velden, anders kun je systemen niet naast elkaar leggen. Je bronsystemen blijven de bron van waarheid; het systeem leest ze en vervangt ze niet.

Hoe lang duurt het om zoiets op te zetten?

Dat hangt vooral af van de staat van je data en het aantal systemen, niet van de AI. Het koppelen van klanten over systemen heen en het vastleggen van definities kost de meeste tijd.

Waar gaat het in de praktijk het vaakst mis?

In de identiteitskoppeling en de definities. Een model op data waarin klanten verkeerd zijn gekoppeld of omzet op drie manieren wordt berekend, geeft overtuigende maar verkeerde bevindingen.