AI mag je offerte structureren, niet je prijs verzinnen

AI mag de aanvraag uit elkaar trekken, maar hij mag de prijs niet bij elkaar fantaseren. Dat onderscheid bepaalt of offerteautomatisering je commerciële proces sterker maakt of alleen overtuigender laat klinken wat niemand kan bewijzen.

Mijn stelling is eenvoudig: laat AI de rommelige voorkant van een offerte structureren, maar laat brondata, vaste rekenregels en een bevoegde mens bepalen wat er financieel en commercieel uit mag. De tekst van een offerte kan vloeiend zijn terwijl één verkeerde kostprijs je marge opeet.

AI hoort in een offerteproces bij interpretatie en voorbereiding. Prijs en marge horen bij versieerbare bronregels. Vrijgave hoort bij een eigenaar die de exacte offerte kan begrijpen, aanpassen of blokkeren. Zo blijft snelheid mogelijk zonder verantwoordelijkheid te verstoppen in een plausibel klinkend antwoord.

Structuur is nog geen waarheid

Een offerte begint zelden met nette velden. De vraag komt binnen als e-mail, pdf, notitie of een gesprekssamenvatting. Daarin staan productnamen die niet exact overeenkomen met je catalogus, hoeveelheden zonder eenheid, gewenste leverdata en aannames die niemand als aanname heeft gemarkeerd. Dat is precies het soort ongestructureerde input waar AI nuttig kan zijn.

Ik zou een model daar laten voorstellen: dit is de klant, dit zijn de vermoedelijke regels, dit ontbreekt nog en deze zin lijkt een commerciële belofte. Het resultaat moet een werkvoorstel zijn met bronverwijzingen, onzekerheden en uitzonderingsredenen. Het mag dus best zeggen: “Ik vermoed product X, maar de eenheid ontbreekt.”

Wat het model niet mag doen, is een ontbrekende verkoopprijs invullen omdat een vergelijkbaar product meestal ongeveer zoveel kost. OpenAI beschrijft zelf dat Structured Outputs de JSON-vorm aan een schema kan laten voldoen, terwijl waarden binnen die structuur nog steeds fout kunnen zijn. Een veld met de naam unit_price wordt niet waar doordat het netjes in JSON staat.

Dat lijkt een technische nuance, maar het is een commerciële grens. Een schema controleert of gross_margin een getal is. Het controleert niet of de kostprijs bij de juiste productversie hoort, of een korting is toegestaan en of de klant deze prijsafspraak werkelijk heeft. Structuur maakt controle mogelijk. Structuur vervangt de controle niet.

De belangrijkste velden voor de AI-laag zijn price en discount, aangevuld met source_ref, source_version, confidence_reason en needs_review. Zonder die herkomst produceert AI een nette samenvatting van een onduidelijke werkelijkheid.

Een prijs is een versie, geen suggestie

Prijs en marge leven in veel organisaties op meerdere plekken tegelijk. Een productcatalogus kent een verkoopprijs, een ERP kent een kostprijs, een CRM kent een klantafspraak en een verkoper kent een uitzondering die nergens is vastgelegd. Zodra een model uit al die bronnen een gemiddelde waarheid maakt, ben je niet aan het automatiseren. Je bent een nieuw, onzichtbaar prijssysteem aan het bouwen.

Een prijs die betrouwbaar een offerte in mag, heeft minstens een eigenaar, een versie, een ingangsdatum en een regel die uitlegt wanneer hij geldig is. Voor marge komen daar de kostprijs, de formule, de afronding en de mandaatgrens bij. Een korting onder de grens is dan geen creatieve schrijftaak, maar een beslissing met een benoemde eigenaar.

Dat is ook hoe zakelijke software prijsdata behandelt. HubSpot beschrijft prijsboeken als verzamelingen met aangepaste prijzen per regio, klantsegment of kanaal, die eerst gevalideerd en geactiveerd worden voordat ze voor deals en offertes beschikbaar zijn. De les is niet dat je HubSpot moet kiezen. De les is dat een prijsbron een eigen levenscyclus heeft.

Voor je offerteproces moet je daarom per beslisveld vastleggen welk systeem de actuele waarde bezit. De productcatalogus of het ERP kan de prijsversie bezitten. Een beleidslaag kan de margetoets en mandaatdrempel bezitten. Het offerteplatform kan de documentversie en verzendstatus bezitten. De workflowlaag kan vastleggen wie heeft vrijgegeven en welke versie daarvoor is gebruikt.

Neem een eenvoudig grensgeval. De offerte toont een bedrag van 7.500 euro, maar de regels tellen op tot 7.200 euro. Een model kan beide bedragen keurig naast elkaar zetten. Het mag niet kiezen welke waarde “waarschijnlijk” klopt. De kandidaat hoort naar een uitzonderingsroute met beide bronnen, de afwijking en een verantwoordelijke. Pas na herstel ontstaat een nieuwe versie.

Dat versieverschil is belangrijker dan het lijkt. Als een catalogus vandaag wijzigt, mag een offerte die gisteren is vrijgegeven niet stilletjes opnieuw worden berekend. De oude offerte moet terug te brengen zijn naar de prijsversie, kostprijs en korting die op dat moment geldig waren. Anders kun je later niet uitleggen waarom een klant een bedrag kreeg en waarom je marge anders uitviel.

Uitzonderingen zijn geen ruis

Veel AI-projecten behandelen uitzonderingen als de gevallen waarin het model “lage zekerheid” heeft. Dat is te vaag voor een offerteproces. Een eigenaar kan niets met een groene of oranje modelscore als niet duidelijk is welke zakelijke vraag nog openstaat.

Een bruikbare uitzondering heeft een reden die naar werk leidt: price_expired, source_mismatch, customer_ambiguous, cost_missing, discount_below_floor of duplicate_candidate. Bij price_expired moet iemand een geldige prijsversie kiezen. Bij source_mismatch moet iemand beslissen welke bron wint. Bij discount_below_floor moet een bevoegde persoon de commerciële consequentie dragen.

Dat is het verschil tussen AI als tekstgenerator en AI als onderdeel van een bestuurbare workflow. In een offerteplatform dat brondata, marge en vrijgave controleerbaar test is de uitzonderingsqueue geen afvalbak. Zij laat zien welke regels niet scherp genoeg zijn, welke bron geen eigenaar heeft en waar het proces nog op geheugen draait.

Dezelfde grens zie ik bij financiële documentverwerking. Bronbewijs, zakelijke match en een read-back na het schrijven zijn drie verschillende beweringen. Een document kan goed gelezen zijn zonder dat de klant, de prestatie of de prijs klopt. Een succesvolle API-aanroep kan een record hebben aangemaakt zonder te bewijzen dat de juiste versie is opgeslagen.

NIST beschrijft betrouwbaarheid daarom niet als een mooie demonstratie, maar als correcte werking onder de omstandigheden waarin een systeem wordt gebruikt. Het raamwerk koppelt validatie aan objectief bewijs, voortdurende monitoring en menselijke interventie wanneer AI fouten niet zelf kan detecteren of herstellen. Voor offertes betekent dat: test de standaardaanvraag, de verlopen prijs, de ontbrekende kostprijs, de dubbele klant en de wijziging na goedkeuring.

Vrijgave is een besluit, geen vinkje

Een menselijke vrijgave heeft alleen waarde als de mens iets anders kan doen dan op “akkoord” klikken. De beoordelaar moet de bron kunnen openen, de gebruikte prijsversie kunnen zien, de marge per regel kunnen begrijpen en weten welke uitzonderingen zijn opgelost. Anders is de mens alleen het laatste onderdeel van een automatische doorstuurstraat.

Ik maak daarom onderscheid tussen vier statussen: voorgesteld, controleerbaar, vrijgegeven en verzonden. Voorgesteld betekent dat AI een structuur heeft gemaakt. Controleerbaar betekent dat bronnen, regels en berekeningen compleet zijn. Vrijgegeven betekent dat een bevoegde eigenaar de exacte verzendinhoud accepteert. Verzonden betekent dat de klant de versie heeft ontvangen. Geen van die statussen mag stilzwijgend de volgende worden.

Ook hier is een concreet systeem leerzaam. In de actuele HubSpot-documentatie start een nieuwe quote als DRAFT; PENDING_APPROVAL, APPROVED en REJECTED zijn aparte toestanden in de quotelevenscyclus. Die scheiding tussen concept, goedkeuring en acceptatie door de koper staat expliciet in de Quotes API-documentatie. Het is een betere mentale kaart dan één status als ready.

AI mag de beoordelaar dus helpen door verschillen zichtbaar te maken. Zij kan de bronpassage naast de offerte regel zetten, de berekening uitleggen en de ontbrekende beslissing formuleren. Zij mag niet bepalen dat “ongeveer hetzelfde” voldoende is voor een prijs, marge of klantmatch.

Dat past bij de bredere ontwerpintuïtie van de Europese Commissie. Voor hoog-risico-AI verlangt artikel 14 dat menselijke toezichthouders de uitvoer kunnen begrijpen, negeren, overrulen of het systeem veilig onderbreken. De officiële uitleg benadrukt tegelijk dat de maatregelen moeten passen bij het risico en de mate van autonomie. Een gewone offerteworkflow valt niet automatisch onder hoog-risico-AI. Het principe blijft bruikbaar: menselijke controle is pas echt als de mens kan ingrijpen in het concrete besluit.

Een gewonnen deal is om dezelfde reden nog geen vrijgegeven uitvoering. Scope, beloften, capaciteit, startdatum en delivery-eigenaarschap moeten eerst een aparte vrijgavepoort passeren. Een offerte kan een prijsbesluit dragen zonder al een uitvoeringsbesluit te zijn. Houd die twee momenten uit elkaar.

Om eerlijk te zijn: volledige controle maakt AI waardeloos

Het sterkste tegenargument is terecht. Als iemand elke regel, elk bedrag en elke bron handmatig moet nalopen, verdwijnt een groot deel van de tijdwinst. Een bedrijf met vaste producten, stabiele prijzen en weinig uitzonderingen kan prima ver komen met automatische berekening en een steekproef. Wie menselijke vrijgave vertaalt naar opnieuw overtypen, heeft automatisering verkeerd ontworpen.

Daar ben ik het mee eens. Ik pleit niet voor een mens die als menselijke OCR naast een taalmodel gaat zitten. Ik pleit voor een systeem dat de voorspelbare route automatisch laat lopen wanneer de bron vers, de match uniek, de marge boven de grens en het mandaat duidelijk is. De mens hoort vooral te verschijnen waar een keuze of risico ontstaat.

De draai zit in wat je automatiseert. Automatiseer niet het verzinnen van een ontbrekende waarde. Automatiseer het ophalen van de juiste bron, het bevriezen van de gebruikte versie, het narekenen van de formule, het klaarzetten van bewijs en het routeren van uitzonderingen. Dan wordt menselijke vrijgave kleiner in volume en groter in betekenis.

Je kunt dat verschil achteraf meten. Niet met het aantal offertes dat groen uit de workflow komt, maar met de vraag hoeveel daarvan een bronversie, marge-uitkomst, uitzonderingsreden, vrijgave-eigenaar en read-back hebben. Een snelle fout die je niet meer kunt reconstrueren is geen efficiëntie. Het is uitgestelde administratie met rente.

De offerte moet later nog te verklaren zijn

Een offerte is geen tekstproduct. Het is een tijdelijk commercieel besluit dat later kan doorwerken in een order, project, factuur en klantverwachting. AI kan het besluit voorbereiden en de presentatie versnellen. Zij kan niet zelf de verantwoordelijkheid bezitten voor een prijs die nergens als bron bestaat.

De beslissende test is daarom niet of AI in een paar seconden een nette offerte maakt. De test is of je zes maanden later nog kunt antwoorden: welke bronversie gebruikte je, welke kostprijs en margeformule golden, welke uitzondering speelde, wie gaf vrij en welke verzendinhoud is precies verzonden?

Als dat antwoord ontbreekt, heb je vooral de buitenkant geautomatiseerd. Als het antwoord wel beschikbaar is, krijgt AI de juiste rol: snel in het ordenen van onzekerheid, bescheiden over wat zij niet weet en ondergeschikt aan regels en mensen die het commerciële besluit kunnen dragen. Een overtuigende offerte begint dan niet bij een verzonnen prijs, maar bij een waarheid die je kunt terugvinden.