Hoe werkt AI binnen Revenue Intelligence?

AI binnen Revenue Intelligence is geen enkel model, maar een keten van verschillende technieken: rekenregels en statistiek die afwijkingen in omzetdata vinden, voorspellende modellen die kansen en bedragen schatten, taalmodellen die contracten en notities lezen en bevindingen uitleggen, en agents die binnen vaste grenzen acties voorbereiden of uitvoeren. Het getal zelf komt vrijwel altijd uit database-queries en voorspellende modellen, niet uit een taalmodel. Of het werkt, hangt minder af van hoe slim de modellen zijn dan van drie dingen eromheen: welke data ze mogen zien, hoe hun uitkomsten worden gecontroleerd, en wie beslist voordat er iets in je systemen verandert.

Vier soorten AI in één systeem

Het woord AI wordt gebruikt voor dingen die weinig met elkaar te maken hebben. In een Revenue Intelligence-systeem kom je er vier tegen, elk met een eigen taak.

De verwarring ontstaat als die vier door elkaar worden gehaald. Een taalmodel is goed in tekst, niet in rekenen. Een voorspellend model is goed in kansen, maar kan geen contract lezen. Een systeem dat een taalmodel een omzetcijfer laat bedenken, geeft je een getal dat overtuigend klinkt en nergens op rust. Het verschil tussen de twee grote families staat uitgelegd in predictive AI vs generative AI.

Wat een Revenue Intelligence-systeem in brede zin is, los van de AI, lees je in wat is Revenue Intelligence. Dit artikel gaat over de AI eronder.

De keten, van brondata tot actie

Een goed opgebouwd systeem werkt in lagen. Elke laag doet één ding en geeft zijn resultaat door aan de volgende. Dat maakt het controleerbaar: als er iets misgaat, kun je zien in welke laag. Hoe zo'n opbouw technisch in elkaar zit, staat uitgewerkt in AI architecture voor Revenue Intelligence. Hier loop ik de lagen langs vanuit de vraag wat ze in de praktijk doen.

1. Toegang: data lezen uit CRM, facturatie, ERP, contracten en support.
2. Verbinden: dezelfde klant, hetzelfde contract en dezelfde order in verschillende systemen aan elkaar koppelen.
3. Afwijkingen vinden: vergelijken wat er zou moeten zijn met wat er is.
4. Voorspellen: schatten wat er gaat gebeuren.
5. Uitleggen en lezen: tekst begrijpen en bevindingen in gewone taal teruggeven.
6. Handelen: acties voorbereiden of, met toestemming, uitvoeren.
7. Controle: over alle lagen heen bewaken of het klopt.

Laag 1: toegang tot de data

Alles begint bij de vraag waar de AI bij mag. Een Revenue Intelligence-systeem moet deals, facturen, contracten en klantgegevens kunnen lezen. Maar wie leestoegang geeft tot een CRM, geeft ook toegang tot namen, e-mailadressen en notities over mensen.

Twee principes bepalen of dat veilig is. Het eerste is minimale rechten: alleen leestoegang waar lezen genoeg is, alleen tot de systemen die nodig zijn, via een koppeling die per systeem in te trekken is. Waarom dat zwaarder weegt dan de kwaliteit van het model, staat in hoe geef je AI toegang tot bedrijfsdata.

Het tweede is dat persoonsgegevens niet verder reizen dan nodig. Voor het vinden van een omzetlek hoeft een AI-model niet te weten dat de contactpersoon Jan de Vries heet. Het moet weten dat klant K-1042 een contract heeft met een indexatieclausule. Door namen, e-mailadressen en andere herleidbare gegevens te vervangen door tokens voordat iets een model bereikt, blijft de analyse mogelijk zonder dat het model de mensen ziet. Hoe dat werkt, lees je in hoe werkt tokenisatie van bedrijfsdata, en in bredere zin in hoe bescherm je persoonsgegevens in AI-systemen.

Laag 2: systemen aan elkaar verbinden

Omzetlekkage zit bijna nooit in één systeem. Het zit tussen systemen: een deal in het CRM die geen order in het ERP heeft, een contract met een indexatieclausule die niet in de facturatie is verwerkt, een licentie-uitbreiding die de accountmanager heeft toegezegd en die nergens op een factuur staat.

Om dat te zien, moet het systeem weten dat "Bouwbedrijf Jansen B.V." in het CRM, "Jansen Bouw" in Exact en debiteur 20417 in de facturatie dezelfde klant zijn. Dat koppelen is minder spectaculair dan een voorspellend model, maar het is het werk waar de meeste fouten ontstaan. Een koppeling die twee klanten samenvoegt die niets met elkaar te maken hebben, of één klant in drieën splitst, maakt elke analyse daarna waardeloos.

Hier helpt AI op een bescheiden manier: het kan voorstellen welke records waarschijnlijk bij elkaar horen, op basis van naam, adres, KvK-nummer en transactiepatronen. Maar een voorstel is geen koppeling. De gevolgen van verkeerde of vervuilde data die toch wordt gebruikt, staan in wat gebeurt er als AI verkeerde bedrijfsdata gebruikt.

Laag 3: afwijkingen vinden

Dit is de laag waar de meeste omzetlekken worden gevonden. Er zijn twee manieren om een afwijking te zien.

Regels. Je weet wat er zou moeten zijn en controleert of het er is. Elke gewonnen deal hoort binnen dertig dagen een factuur te hebben. Elk contract met een indexatieclausule hoort in januari een hogere prijs te hebben. Elk uur meerwerk in de urenregistratie hoort op een factuur te staan. Regels zijn precies, uitlegbaar en vinden het grootste deel van de bekende lekken.

Anomaly detection. Je weet niet precies wat er mis kan gaan, maar je weet wat normaal is. Een klant die al drie jaar elke maand rond EUR 12.000 afneemt en nu drie maanden op EUR 7.000 staat. Een productgroep waar de gemiddelde korting in een kwartaal ineens vier punten hoger ligt. Een model leert het normale patroon en meldt wat daarvan afwijkt. Hoe dat werkt en waar het misgaat, lees je in wat is anomaly detection.

In de praktijk heb je beide nodig. Regels vinden wat je al kent. Anomaly detection vindt wat je nog niet had bedacht. Een systeem dat alleen op een van de twee draait, mist de helft.

Het belangrijkste werk in deze laag is het vertalen van een afwijking naar een bedrag. "Deze klant betaalt 4 procent minder dan zijn contract zegt" is een observatie. "Deze klant betaalt EUR 3.800 per jaar te weinig, sinds januari 2025" is een bevinding waar iemand iets mee kan.

Laag 4: voorspellen

Voorspellende modellen schatten wat er gaat gebeuren: de kans dat een deal sluit en wanneer, de kans dat een klant vertrekt, de omzet van het komende kwartaal met een bandbreedte. Ze leren van je eigen historie, en ze zijn zo goed als die historie. De algemene werking staat in wat is predictive analytics. Toegepast op omzet heet het forecasting, uitgelegd in AI revenue forecasting.

Voor Revenue Intelligence is het belangrijkste dat een voorspelling altijd met een onzekerheid komt. Een model dat zegt "deze klant heeft 70 procent kans om te vertrekken" zonder te laten zien waarop dat is gebaseerd, geeft je weinig om mee te werken. Een model dat zegt "de afname is vier maanden gedaald, er zijn drie escalaties in support en het contract loopt in maart af" geeft je een gesprek om te voeren.

Laag 5: tekst lezen en uitleggen

Taalmodellen hebben twee taken in een Revenue Intelligence-systeem.

Lezen wat niet in velden staat. Contracten, offertes, notities in het CRM, mails met afspraken. Een indexatieclausule staat meestal niet als veld in je ERP, maar als zin in een pdf. Een taalmodel kan die zin vinden en omzetten naar gegevens die een regel kan controleren: indexatie jaarlijks per 1 januari, op basis van een CBS-index, maximaal 5 procent.

Uitleggen wat er is gevonden. Een bevinding in gewone taal, met de bron erbij: welke factuur, welk contract, welke deal. En een antwoord op een vraag als "waarom is de forecast deze week gedaald?"

Hoe een taalmodel bij de juiste informatie komt, is een technische keuze met grote gevolgen. Voor vragen over cijfers wil je dat het systeem de database bevraagt en het exacte antwoord teruggeeft, niet dat een model in documenten zoekt naar iets wat erop lijkt. Voor vragen over tekst, zoals contractbepalingen, is zoeken in documenten wel de juiste weg. Dat verschil staat in RAG vs database queries voor bedrijfsdata. Het zoeken in tekst werkt met embeddings, uitgelegd in embeddings uitgelegd voor business software.

Een taalmodel kan maar een beperkte hoeveelheid tekst tegelijk verwerken. Wat erin past, bepaalt wat het kan zien; wat erbuiten valt, bestaat voor het model niet. Dat is waarom je een model niet "het hele CRM" geeft, zie context windows uitgelegd voor AI-systemen. Elke keer dat een model iets verwerkt, kost dat rekenkracht en tijd; wat dat betekent voor snelheid en kosten, staat in inference uitgelegd. En de vraag of je een model op je eigen data moet trainen of het beter bij de juiste informatie kunt laten zoeken, wordt behandeld in fine-tuning vs RAG voor bedrijfssoftware. Voor omzetdata is het antwoord bijna altijd: zoeken en bevragen, niet trainen, omdat je data elke dag verandert.

Laag 6: handelen met agents

Een bevinding die in een dashboard blijft staan, levert niets op. Iemand moet de factuur corrigeren, de klant bellen, de indexatie doorvoeren. Agents nemen een deel van dat werk over.

Een agent is een taalmodel met gereedschap: het kan een factuur opzoeken, een order opvragen, een taak aanmaken, een concept klaarzetten. Het model zelf raakt niets aan; het vraagt de software eromheen om een stuk gereedschap te gebruiken. Wat een agent is, lees je in wat is een AI agent. Hoe dat vragen om gereedschap technisch werkt, staat in wat is tool calling.

In revenue operations zijn de nuttige taken meestal saai: een afwijking onderzoeken in drie systemen en de bevindingen samenvatten, een herinnering aan een late betaler klaarzetten, een CRM-record bijwerken na een getekend contract, supporttickets van waardevolle accounts vooraan zetten. Toepassingen en valkuilen staan in wat zijn AI agents in RevOps.

De veiligheid van een agent zit niet in het model, maar in wat de software eromheen mag. Een agent die facturen mag lezen maar niet versturen, kan geen factuur de deur uit doen, wat het model ook denkt. Hoe smaller het gereedschap, hoe kleiner wat er mis kan gaan.

Laag 7: controle over alles heen

AI maakt fouten. Niet vaak, als het goed is ingericht, maar wel op een manier die moeilijk te zien is: een taalmodel dat een clausule verkeerd leest, een koppeling die twee klanten verwart, een model dat een patroon ziet dat toeval is. Daarom heeft elke laag controle nodig.

Monitoring. Wordt de nauwkeurigheid van een model minder? Leest de koppeling nog alle data, of mist er sinds een update een veld? Doet een agent iets wat hij niet eerder deed? Zie AI monitoring uitgelegd.

Output controleren. Een bevinding moet herleidbaar zijn naar de brondata: welke factuur, welk contract, welke regel. Een bevinding zonder bron is niet te controleren en dus niet te vertrouwen. Waarom dat geen formaliteit is, lees je in waarom AI-output gecontroleerd moet worden.

Zekerheid tonen. Elke bevinding en elke voorspelling hoort een zekerheid te hebben, en die zekerheid moet achteraf blijken te kloppen. Een systeem kan er ook voor kiezen een bevinding helemaal niet te tonen als de zekerheid te laag is. Hoe je beoordeelt of zo'n zekerheid iets betekent, staat in hoe weet je of een AI-aanbeveling betrouwbaar is.

Een mens beslist. Het belangrijkste onderscheid in het hele systeem is dat tussen aanbevelen en beslissen. Een AI die voorstelt de prijs van een klant te corrigeren, is iets anders dan een AI die dat doet. Dat verschil staat in AI recommendations vs AI decisions, en de manier waarop je mensen op de juiste plekken in het proces houdt, in human-in-the-loop AI uitgelegd.

Rekenvoorbeeld: één lek door de hele keten

Rekenvoorbeeld: stel je hebt 180 servicecontracten met een jaarlijkse indexatieclausule. Zo loopt één lek door de lagen heen.

1. Toegang. Het systeem leest de contracten uit de documentmap, de facturen uit de facturatie en de klanten uit het CRM. Namen en contactgegevens worden vervangen door tokens.
2. Lezen. Een taalmodel haalt uit elk contract de indexatieclausule: percentage of index, datum, maximum. Bij twaalf contracten is de tekst onduidelijk; die worden gemarkeerd voor een mens in plaats van gegokt.
3. Verbinden. Elk contract wordt gekoppeld aan de juiste debiteur en de juiste factuurregels.
4. Afwijking vinden. Een regel vergelijkt de prijs op de factuur van januari met die van december, per contract. Bij 23 contracten is de prijs niet gestegen, terwijl de clausule dat wel voorschreef.
5. Bedrag. Die 23 contracten hebben samen een jaarwaarde van EUR 460.000. Met een indexatie van 3,5 procent is het gemiste bedrag EUR 16.100 per jaar, en omdat indexatie doorwerkt in alle volgende jaren, is het na drie jaar al bijna EUR 50.000.
6. Zekerheid. Voor 19 contracten is de clausule eenduidig en de afwijking zeker. Voor 4 contracten is er een bijlage die mogelijk een uitzondering bevat. Die krijgen een lagere zekerheid.
7. Aanbeveling. Het systeem stelt voor de 19 zekere gevallen te corrigeren en de 4 twijfelgevallen te laten beoordelen door de contracteigenaar.
8. Handelen. Na goedkeuring zet een agent de correcties klaar in de facturatie en een concept-bericht aan de klant. Een mens verstuurt.
9. Controle. In februari controleert het systeem of de nieuwe prijzen op de facturen staan.

De bedragen zijn een voorbeeld. Het patroon laat zien waarom geen enkele laag het alleen kan: het taalmodel las de contracten, de regel vond de afwijking, de mens besliste, de agent deed het werk. Meer over dit soort lekken lees je in revenue leakage door vergeten prijsindexatie.

Wat AI hier niet kan

• Omzet zien die nergens staat. Meerwerk dat op de bouwplaats is afgesproken en nooit is vastgelegd, bestaat voor geen enkel systeem. AI kan wel signaleren dat een project opvallend weinig meerwerk heeft vergeleken met vergelijkbare projecten.
• Vervuilde data goedmaken. Een model op slechte data geeft slechte uitkomsten met een overtuigende uitleg. Het kan wel helpen de vervuiling te vinden.
• Weten wat je met een klant hebt afgesproken aan de telefoon. De accountmanager weet dat de indexatie dit jaar is kwijtgescholden om een verlenging binnen te halen. Het systeem ziet een afwijking. Daarom beslist een mens.
• De verantwoordelijkheid overnemen. Een systeem kan voorstellen, voorbereiden en uitvoeren wat is goedgekeurd. De keuze om een klant een correctie te sturen, blijft een zakelijke beslissing.

Hoe je een systeem beoordeelt

Of je nu een Revenue Intelligence-platform kiest, een module in je CRM aanzet of zelf iets bouwt, deze vragen scheiden een bruikbaar systeem van een demo.

1. Welke soort AI doet wat? Komt het omzetcijfer uit een database-query of voorspellend model, of uit een taalmodel?
2. Waar kan het bij, en met welke rechten? Alleen lezen, of ook schrijven? Onder welk account?
3. Wat ziet het model van je klanten? Worden persoonsgegevens vervangen voordat iets een AI-model bereikt?
4. Is elke bevinding herleidbaar? Kun je doorklikken naar de factuur, het contract, de deal?
5. Toont het een zekerheid, en klopt die? Wat gebeurt er met bevindingen onder de drempel?
6. Wie beslist? Welke acties voert het zelf uit, welke pas na goedkeuring?
7. Wordt het bewaakt? Merkt het systeem zelf wanneer een koppeling of model slechter gaat werken?
8. Is er een logboek? Kun je achteraf zien wat het las, wat het concludeerde en wat het deed?

Hoe RiOS dit inricht

RiOS, het platform van AutoMaat dat nu in bèta is, wordt op een aantal van deze principes gebouwd. De leeslaag haalt data uit je systemen en schrijft niet zelfstandig terug; automatiseringen draaien pas na goedkeuring. Een tokenisatielaag haalt namen, e-mailadressen en andere herleidbare gegevens eruit voordat iets een AI-model bereikt. Row-level security in de database bepaalt wie wat ziet, en een bevinding die de zekerheidsdrempel niet haalt, wordt niet getoond. Dat model staat uitgewerkt op de pagina beveiliging. De vragen hierboven gelden voor elk systeem, ook dit.

Veelgestelde vragen

Is Revenue Intelligence hetzelfde als een chatbot op je CRM?

Nee. Een chatbot kan vragen beantwoorden over wat er in het CRM staat. Revenue Intelligence verbindt meerdere systemen, zoekt actief naar afwijkingen, zet er een bedrag op en zorgt dat er iets mee gebeurt. Een taalmodel is daar één onderdeel van.

Leert de AI van mijn data?

Voorspellende modellen leren van je historische data, want dat is hoe ze jouw patronen herkennen. Taalmodellen worden in een goed ingericht systeem niet getraind op je data, maar krijgen per vraag alleen de informatie die nodig is. Vraag altijd na hoe een leverancier dat doet.

Kan AI zelf fouten in facturen herstellen?

Technisch kan een agent een correctie klaarzetten of uitvoeren. Of dat verstandig is, hangt af van de actie. Een concept klaarzetten dat een mens verstuurt, is iets anders dan zelfstandig creditnota's aanmaken. Begin met voorstellen en voorbereiden, en laat de uitvoering bij mensen tot het systeem zich heeft bewezen.

Hoe weet ik of een bevinding klopt?

Door hem te herleiden naar de bron. Een goede bevinding noemt de factuur, het contract en de regel waarop hij is gebaseerd, met een zekerheid. Kun je dat niet zien, dan kun je hem niet controleren.

Heb je een datateam nodig om dit te gebruiken?

Niet als het systeem de koppelingen, definities en controles al bevat. Wel heb je iemand nodig die de bevindingen beoordeelt en beslist wat ermee gebeurt. Dat is geen data-werk, maar zakelijk oordeel.