AI-offerte: wat u leest voordat u tekent

Een AI-offerte is een belofte die op papier staat voordat iemand uw data heeft gezien. Het nuttige deel is dus niet de prijs, maar de zinnen die zeggen wat “klaar” betekent, wie de uitzonderingen oppakt, wat buiten de scope valt en wat er na oplevering gebeurt. Zijn die vier vaag, dan is de prijs een gok. Ik lees beroepsmatig offertes, mijn eigen offertes inbegrepen, en dit zijn de regels die ik als eerste lees.

Veel kopers doen het andersom. Ze openen het document, springen naar het bedrag, kijken vluchtig naar de planning en vergelijken dan twee getallen die twee verschillende beloftes beschrijven. Dit stuk gaat over de rest van het document, want daar wordt een project gewonnen of verloren, maanden voordat iemand een regel code schrijft.

Wat hoort er in een AI-offerte?

Haal het logo, de methodiekslide en de alinea over het team weg, en een offerte die een handtekening verdient bevat zes dingen. Een zin die zegt wat er in uw bedrijf verandert als het project slaagt. Een definitie van “klaar” die u kunt toetsen. Een lijst van wat erin zit en wat erbuiten valt. Een lijst met aannames, waaronder wat de leverancier van u nodig heeft. Een manier om met wijzigingen om te gaan. En een plan voor de dag na oplevering.

Ik loop ze achtereenvolgens langs, want de meeste offertes die ik te zien krijg bevatten anderhalf van de zes. De zin over het resultaat staat er meestal wel, in marketingtaal. De definitie van “klaar” is meestal een werkwoord: “opleveren”, “implementeren”, “live zetten”. Een werkwoord is geen test.

De beste controle die ik ken: lees de resultaatzin hardop voor en vraag u af of iemand die u niet mag haar onwaar kan bewijzen. “Klantenservice verbeteren met AI” kan niet onwaar blijken, en dat is precies waarom ze zo makkelijk te schrijven is. “De eerste reactie op de twaalf meest gestelde vragen over bestellingen wordt door het systeem opgesteld en door een medewerker in minder dan dertig seconden goedgekeurd” kan op een dinsdagmiddag onwaar blijken. Kies de tweede soort zin, ook als die kleiner is. In mijn ervaring is de kleinere belofte degene die af komt.

Hoe stelt u acceptatiecriteria vast voor een AI-project?

Gewone software heeft een luxe die AI-werk niet heeft: dezelfde invoer levert dezelfde uitvoer, dus “werkt” kunt u één keer controleren. Een AI-systeem geeft antwoorden die meestal goed zijn, en de interessante vraag is hoe vaak, bij welke gevallen en wie dat beoordeelt. Acceptatiecriteria voor een AI-project vormen daarom een ander soort document, en als koper zou ik daar in een offerte de meeste tijd aan besteden.

Een bruikbaar criterium bestaat uit vier delen. Een steekproef: een set echte gevallen uit uw eigen bedrijf, getrokken vóór het project begint, geen demodata van de leverancier. Een maatstaf: wat telt als correct, zo opgeschreven dat twee mensen hetzelfde antwoord hetzelfde beoordelen. Een drempel: het aandeel gevallen dat moet slagen, het liefst uitgesplitst naar de makkelijke meerderheid en de lastige minderheid. En een eigenaar: de persoon aan uw kant die tekent voor akkoord, want een test die niemand aan uw kant uitvoert, voert de leverancier uiteindelijk alleen uit.

Staat er in de offerte “de succescriteria stellen we tijdens het project vast”, lees dat dan als “we bepalen hoe goed het moet zijn zodra we weten hoe goed het is”. Dat is niet oneerlijk, maar het schuift het risico naar u toe, op het moment dat u de minste informatie hebt. Ik heb liever in week één een discussie over de drempel dan in week twaalf een stil meningsverschil. Hoe een meetplan eruitziet, beschreef ik in wat u meet in een AI-pilot.

Er bestaat ook een legitieme versie van “dat spreken we later af”, en het loont om het verschil te kunnen zien. Sommige projecten kunnen pas een drempel vaststellen na een kleine, betaalde eerste fase die laat zien hoe de data eruitziet. Een goede offerte zegt dat dan, prijst die fase apart en benoemt het besluit aan het einde: doorgaan, bijsturen of stoppen. Het verschil is dat de onzekerheid een datum en een prijs heeft.

Wie pakt de uitzonderingen op die niet in de offerte staan?

Elk bedrijfsproces heeft een tekening en een werkelijkheid. De tekening is de versie waar iedereen het over eens was; de werkelijkheid bevat de klant die altijd te laat betaalt, het product dat alleen in een bundel naar één groothandel gaat en de order die de magazijnchef op vrijdag met de hand corrigeert. Niets daarvan staat in een offerte die na een eerste gesprek is geschreven, en het duikt allemaal op in het project.

Daarom zoek ik een zin die zegt wie de uitzonderingen vindt en wanneer. De eerlijke versie klinkt zo: de leverancier neemt in de eerste twee weken een steekproef van enkele honderden echte gevallen, maakt een lijst van de uitzonderingen en spreekt met u af welke het systeem afhandelt, welke naar een mens gaan en welke buiten de scope vallen. De slechte versie is stilte, en dat betekent in de praktijk dat de uitzonderingen tijdens het testen opduiken en worden omgedoopt tot “wijzigingsverzoeken”. Dat patroon beschreef ik uitgebreider in de uitzonderingenlijst, en ik vind het nog steeds het nuttigste document dat een project oplevert.

Een verwante regel: wat doet het systeem als het het niet zeker weet? Een offerte die het terugvalpad nergens noemt, heeft niet nagedacht over het werk. Het antwoord hoeft niet ingewikkeld te zijn. “Gevallen met lage zekerheid gaan met het concept erbij naar een vaste, bij naam genoemde medewerker” is een volledig antwoord. “Het model regelt dat” is het niet.

Wat laat een AI-offerte stilletjes weg?

Het scopehoofdstuk vertelt wat erbij zit. Het nuttige is te lezen wat ontbreekt, en bij AI-werk volgen de weglatingen een patroon. Ik controleer er zes.

• Datavoorbereiding. Iemand moet de data vinden, opschonen en koppelen. Gaat de offerte ervan uit dat alles netjes binnenkomt, vraag dan wie het netjes maakt en tegen welk tarief.
• Koppelingen. Aansluiten op uw boekhoudpakket, ERP of mailbox is vaak het halve werk. Een offerte die “koppelt met uw systemen” zegt zonder ze te noemen, heeft ze niet bekeken.
• Lopende kosten. Modelgebruik, hosting en monitoring zijn rekeningen die na oplevering doorlopen. Ze horen erin te staan als schatting met de aannames erachter, en als regel die u later aan de werkelijkheid kunt toetsen.
• Testen op uw data. Geen demo, maar de steekproef uit de acceptatiecriteria, door de leverancier uitgevoerd en herhaald na elke belangrijke wijziging.

• Mensen en training. De medewerkers die goedkeuren, corrigeren en doorverwijzen. Als niemand hun tijd begroot, wordt het systeem aangezet en daarna stilletjes gemeden.
• Beveiliging en gegevensbescherming. Waar de data heen gaat, wie ze verwerkt en wat de leverancier ermee doet. Gaat het om persoonsgegevens, dan is dit niet vrijblijvend en hoort het in de offerte, niet in een e-mail achteraf.

Voor de prijskant hiervan, hoe vaste prijzen en uurtarieven zich gedragen bij dit soort projecten, verwijs ik naar de vergelijking van vaste prijzen en uurtarieven voor AI-projecten. Mijn punt hier is smaller: een lage prijs met een korte scopelijst is geen lage prijs. Het is een andere scope die toevallig in kleinere letters is gedrukt.

Hoe hoort een AI-offerte met wijzigingen om te gaan?

Wijzigen is geen mislukking van een project, en een offerte die doet alsof dat wel zo is, is de eerste rode vlag. Zeker bij AI-werk leert u dingen zodra het systeem echte gevallen tegenkomt, en een deel daarvan is dat het oorspronkelijke idee bijgesteld moet worden. De vraag is niet óf er iets verandert, maar wie het wie vertelt, hoe vroeg en wat het kost.

Ik zoek drie dingen. Ten eerste een meldplicht: de leverancier zegt dat hij u laat weten zodra hij iets ziet dat meer kost of langer duurt, voordat het werk is gedaan en niet erna. Ten tweede een tarief: als de scope groeit, hoe wordt het extra werk dan geprijsd? Een dagtarief dat in de offerte staat, helpt meer dan de belofte dat men redelijk zal zijn. Ten derde een beslismoment: op geplande momenten, zoals het einde van de eerste fase, beslist u of u doorgaat, met genoeg informatie om nee te kunnen zeggen.

Vanuit het perspectief van de leverancier voeg ik iets toe dat ik op de dure manier heb geleerd. Een offerte die zwijgt over wijzigingen beschermt niemand. De klant gaat ervan uit dat alles wat hij later wil erbij zit, de leverancier gaat ervan uit dat niets erbij zit, en het eerste meningsverschil komt wanneer beide partijen zich benadeeld voelen. Het wijzigingsproces opschrijven voelt pessimistisch. Het is het tegenovergestelde: het zorgt ervoor dat beide partijen op goede voet blijven als het project groter blijkt dan het eerste gesprek deed vermoeden.

Wat gebeurt er na oplevering?

Zoek het hoofdstuk “overdracht” of “ondersteuning”, en zoek bij ontbreken ervan de zin die erin zou staan. Een systeem dat live gaat heeft een eigenaar, een logboek, een manier om te zien wanneer het slechter wordt en iemand die het kan aanpassen. Wie is dat na oplevering? Is het antwoord “ons team, op verzoek”, dan heeft het project een verborgen afhankelijkheid die pas in maand veertien als kostenpost zichtbaar wordt.

Goede offertes zeggen wat u aan het eind krijgt naast het werkende systeem: documentatie die een nieuwe collega kan volgen, de steekproef en de beoordelingsmethode zodat u de acceptatietest zelf opnieuw kunt uitvoeren, toegang tot code en configuratie, en een benoemde interne eigenaar. De leverancierskant van dit verhaal beschreef ik in het lock-inprobleem dat niemand op het lijstje zet: het beste bewijs dat een project werkt, is dat u de bouwer niet meer nodig hebt om het draaiend te houden. Een offerte kan dat beloven of weglaten, en door te lezen ziet u welke van de twee het is.

Wat zijn de rode vlaggen in een AI-offerte?

Na het lezen van offertes aan beide kanten van de tafel vind ik de waarschuwingssignalen vrij constant. Geen enkele is op zichzelf doorslaggevend, maar drie of meer in één document is een gesprek waard voordat u iets tekent.

• Een gegarandeerde nauwkeurigheid voordat iemand uw data heeft gezien. Een getal dat zonder steekproef wordt beloofd, is meestal gekozen om de opdracht binnen te halen.
• Geen aannamehoofdstuk. Elke schatting rust op aannames. Staan ze er niet, dan zijn ze er nog steeds; u ziet ze alleen niet.
• Het woord “koppelt” zonder systeemnaam. Meestal betekent het dat nog niemand heeft gekeken.
• Inspanning in weken, resultaat in bijvoeglijke naamwoorden. “Robuust, schaalbaar, intelligent” is niet te testen. Een getal of een steekproef wel.
• Niets over wat u moet aanleveren. AI-projecten vragen uw tijd, uw data en uw beslissingen. Een offerte die daar niets over vraagt, is naïef of van plan er later om te vragen.
• Een demo in plaats van een plan. Een demo laat zien dat het idee kan. Ze laat niet zien dat het werk in de praktijk haalbaar is, en over de kloof tussen demo en productie schreef ik eerder.

Hoe beoordeelt en vergelijkt u AI-offertes?

Hebt u twee of drie offertes, dan is de verleiding groot om een tabel te maken met prijs, doorlooptijd en een kolom met functies. Ik zou een andere tabel maken, met de namen van de leveranciers bovenaan en deze rijen langs de zijkant: de resultaatzin, de test, het uitzonderingsproces, de uitsluitingen, de wijzigingsregels, de overdracht. Vul elke cel in vanuit het document en schrijf “niet vermeld” waar een cel leeg blijft. Een offerte met vijf keer “niet vermeld” is niet goedkoper dan een zonder; ze is onaf.

Stel daarna elke leverancier schriftelijk dezelfde twee vragen en vergelijk hoe ze antwoorden. Wat zou uw schatting onjuist maken? Wat hebt u de eerste maand van ons nodig? U zoekt niet het juiste antwoord. U kijkt of het antwoord specifiek is, of het zonder defensieve reactie komt en of het de offerte verandert. Een leverancier die het document aanpast na een goede vraag, laat zien hoe het project zal lopen.

Het gesprek over prijs is iets anders dan het document; wat een AI-consultant daarbij hoort als u over prijs praat, heb ik apart beschreven. En als de offertes te groot voelen om te beoordelen, is dat vaak een teken dat de eerste stap kleiner moet; hoe u een AI proof of concept afbakent behandelt dat. Weet u nog niet bij wie u een offerte wilt aanvragen, begin dan met wat u moet vragen voordat u een AI-consultant inhuurt.

Wat staat er in mijn eigen offertes?

Ik sluit af met wat ik probeer te doen als ik er zelf een schrijf, deels om mezelf eraan te houden. De eerste pagina zegt in twee of drie zinnen wat er in uw bedrijf anders is als het werkt, en wat niet verandert. De tweede pagina zegt hoe we dat vaststellen, met de steekproef, de maatstaf en de drempel, en wie aan uw kant tekent voor akkoord. De scopelijst heeft een kolom “buiten scope” die even lang is als de kolom “binnen scope”. De aannames zijn genummerd, zodat we ernaar kunnen verwijzen als er één onjuist blijkt. Bij de prijs staat een korte alinea over wat hem zou doen verschuiven, en ruwweg met hoeveel.

Het is geen offerte die elke vergelijking wint. Een korter, zelfverzekerder document met een lager bedrag kan daarnaast beter overkomen. Maar ik heb nog nooit een project zien mislukken omdat de offerte te specifiek was. Ik heb er genoeg zien mislukken omdat ze dat niet was, en de betrokkenen waren zelden onzorgvuldig. Ze hadden een zin getekend die voor beide kanten iets anders betekende.

Lees het dus, voordat u tekent, zoals u een contract leest met iemand met wie u over een jaar nog wilt werken. Let op wat meetbaar is, wie bij naam genoemd wordt, wat is uitgesloten en wat er daarna gebeurt. Wilt u een tweede mening over een offerte die u hebt ontvangen, dan voer ik dat gesprek graag, en het hoort bij wat een AI-consultant voor het mkb doet: soms is het nuttige antwoord dat de offerte in orde is, en soms is het een lijstje van vijf vragen om terug te sturen.

Veelgestelde vragen