Alle artikels
AI

Hoe bouw ik software die offertes voor aannemers automatisch voorbereidt?

Cover voor blogpost over automatiseren offertes met AI

"Overdag sta ik op de werf. 's Avonds zit ik aan de keukentafel offertes te maken. En van de helft hoor ik nooit meer iets."

Die zin hoorden we al vaker. De offerte is voor veel aannemers en installateurs het zwaarste administratieve werk van de week: hij eet uren op, hij moet snel de deur uit, en hij levert pas iets op als de klant tekent.

In dit artikel delen we hoe zo'n software in elkaar zou zitten: hoe een aanvraag binnenkomt, hoe je er posten en prijzen aan koppelt, hoe er een conceptofferte uitkomt in jouw template, en waar een mens het heft in handen moet houden. Geen code, gewoon de architectuur en de keuzes die er toe doen. Eerder schreven we dat offertes bij de AI-toepassingen horen die vandaag al echt werken. Dit keer gaan we een laag dieper.

Eén regel loopt door het hele artikel: AI maakt het concept, jij bepaalt de prijs. Een taalmodel leest aanvragen en schrijft teksten beter dan je zou denken. Rekenen en risico's inschatten mag je hem niet toevertrouwen.

Waar gaat de tijd in een offerte naartoe?

Het typwerk is zelden het probleem. De uren verdwijnen in wat ervoor en erna zit:

  • Uitzoeken wat de klant eigenlijk wil. "Graag een prijs voor een nieuwe badkamer", drie foto's bij, geen afmetingen. Eén keer heen en mailen kost al een halve dag.
  • Hoeveelheden bepalen. Uit een plan, een meetstaat van de architect, of je eigen notities van op de werf.
  • Prijzen opzoeken. Materiaalprijzen die van week tot week schuiven, uurlonen, onderaanneming, en een marge die per type werk anders ligt.
  • Teksten schrijven. Per post een duidelijke omschrijving, plus je vaste voorwaarden en uitsluitingen.
  • Opvolgen. Of: net niet. Veel offertes sterven niet omdat ze te duur zijn, maar omdat niemand na twee weken nog één keer heeft gebeld.

Van die vijf punten is er maar één een pure rekensom: de prijs. De rest is lezen, inschatten en schrijven, en dat is net waar AI vandaag sterk in is. Die verdeling bepaalt eigenlijk alles wat er komt.

Pijplijn voor offertes: webformulier, mail en werfbezoek komen samen en gaan door aanvraag begrijpen, posten koppelen, prijs berekenen en concept opmaken, tot een mens nakijkt, verstuurt en opvolgt. Ontbreekt er info, dan gaat er een gerichte vraag terug naar de klant.


Waar komen offerteaanvragen binnen?

Drie input stromen, zoals we ze kennen van facturen automatisch inboeken:

  1. Een webformulier. In onze ogen de beste deur, zolang je hem goed ontwerpt. Vraag per type werk de dingen die je nu achteraf per mail moet opvragen: oppervlakte, bouwjaar, huidige installatie, gewenste timing. Elke vraag hier is straks een mailtje minder.
  2. E-mail met bijlagen. Plannen, foto's, een meetstaat in Excel of PDF, soms een volledig lastenboek. Hang er een eigen adres bij zoals offertes@jouwbedrijf.be met een webhook (Microsoft Graph of Gmail API). Dat is betrouwbaarder dan een gedeelde inbox waar iemand op moet letten. Ligt alles vandaag nog in één algemene inbox? Dan kun je die eerst automatisch laten sorteren.
  3. Het werfbezoek. Handgeschreven notities, een schets op een servet, een spraakmemo opgenomen in de wagen. Die memo laat je uitschrijven, en daarna is hij een aanvraag net als de anderen.

Alles komt samen in één aanvraagdossier. De originele bestanden bewaar je ongewijzigd; alles wat de software eruit haalt, is afgeleide data.

Stap 1: de aanvraag begrijpen

Het model leest het hele dossier en vult een strak schema in: wie is de klant, waar ligt de werf, wat voor werk, welke hoeveelheden zijn bekend, wanneer wil de klant, welke bijlagen zitten erbij. Per veld geeft het aan hoe zeker het er van is (dezelfde aanpak als bij documenten verwerken met AI).

En dan komt de eerste winst, een saai dingetje: controleren wat er ontbreekt. Per type werk leg je vooraf vast welke gegevens je nodig hebt om te kunnen prijzen. Ontbreekt er iets, dan schrijft de software een gerichte vraag. Geen "kan u ons wat meer info bezorgen?", maar "hoe groot is de badkamer, en blijft de afvoer op zijn plaats?".

Tegelijkertijd maak je een oordeel over de aanvraag zelf: zit de werf in je regio, doe je dit type werk, is het project groot genoeg? Dat zijn jouw regels, geen AI. De stap eindigt in één van drie uitkomsten: offerte opmaken, eerst naar de werf, of eerst info opvragen.

Stap 2: van aanvraag naar posten

Een offerte is niets meer dan een lijst posten: hoeveelheid, eenheid, omschrijving, eenheidsprijs. En die posten moeten uit jouw catalogus komen, niet uit de verbeelding van een taalmodel.

Van strak naar soepel, in drie trappen:

  1. Vaste koppelingen. Een meetstaatcode die je al eens zag, of een standaardpakket per type werk. Een "warmtepomp lucht-water in een eengezinswoning" levert vrijwel altijd dezelfde reeks posten op. Dit dekt bij veel bedrijven al een groot deel van de aanvragen.
  2. Vergelijken met eerdere offertes. Zoek de offertes die het dichtst bij deze aanvraag liggen, en vertrek van hun posten. Wat vorig jaar klopte voor een vergelijkbare badkamer, klopt meestal opnieuw.
  3. Het model, als laatste vangnet. Alleen voor wat overblijft. Het krijgt je catalogus mee en mag enkel kiezen uit wat er staat. "Geen passende post gevonden" is een goed antwoord. Een verzonnen post is dat nooit.

Meetstaten van architecten zijn een verhaal apart: eigen nummering, eigen omschrijvingen, en elke architect schrijft net anders. Net daar zit het werk dat je wil overbruggen, hun post linken aan jouw artikel. Elke koppeling die je bevestigt, onthoudt de software voor de volgende keer.

Drie banen: het AI-model leest de aanvraag, stelt onbekende posten voor en schrijft de teksten; vaste regels controleren, koppelen bekende posten en berekenen prijs, btw en marge; jij doet eventueel een werfbezoek en keurt de offerte goed voor ze vertrekt


Stap 3: de prijs, en waarom AI dat niet zelf moet beslissen

Hier doet de AI niets. Dat is geen beperking, dat is een bewuste keuze. Taalmodellen rekenen slecht en klinken overtuigend. Die combinatie wil je net nergens in je prijs hebben.

De berekening is gewoon code: hoeveelheid maal eenheidsprijs, uren maal uurtarief, je marge per type werk of per klant, je afrondingsregels. En de materiaalprijzen komen uit prijslijsten die je regelmatig van je leveranciers importeert, zodat je vertrekt van de prijs van vandaag en niet van die van vorig jaar.

Btw is ook puur regelwerk. Of een post aan 6% of 21% gaat, of de btw verlegd wordt omdat je voor een andere aannemer werkt: dat hangt af van de klant, het werk en de woning. Die regels leg je één keer vast samen met je boekhouder, en daarna past de software ze consequent toe. Twijfelt ze, dan vraagt ze.

En tenslotte de controles. Net zo saai, net zo belangrijk:

  • Heeft elke post een prijs, en is die prijs niet ouder dan je zelf toelaat?
  • Zit de marge boven je minimum?
  • Wijkt het totaal sterk af van vergelijkbare offertes?
  • Zijn er posten met lage zekerheid uit stap 2?

Elk van die signalen komt straks bovenaan het nakijkscherm te staan.

Stap 4: het concept, in jouw stijl

Nu mag het model eindelijk weer schrijven. Een duidelijke omschrijving per post in jouw toon, een korte inleiding die verwijst naar wat de klant vroeg, en je vaste voorwaarden en uitsluitingen erachter. Wil je varianten, zoals een volledige warmtepomp naast een hybride oplossing, dan maakt AI ze allebei op, met exact dezelfde prijslogica.

Het resultaat landt in een nakijkscherm: de aanvraag links, het concept rechts, de twijfelgevallen gemarkeerd. Alles kun je nog aanpassen. En net daar zit een mooi bijkomend effect: elke aanpassing leert het systeem iets. Vervang je een post, dan heb je ongemerkt een nieuwe koppeling gemaakt voor stap 2.

De offerte vertrekt pas nadat jij er goedgekeurd hebt: als PDF in je huisstijl, of als concept in het offerte- of boekhoudpakket dat je al gebruikt. Automatisch versturen zonder dat iemand keek, doen we niet. Een offerte is een belofte, en die geef je zelf.

Stap 5: offerte opvolgen

De offerte is verstuurd. En dan?

Precies hier stopt de meeste software. Deze niet: ze weet wanneer de offerte vertrok, of er gereageerd werd, en (deel je offertes via een link) ook of die link geopend werd. Na een termijn die jij kiest, stelt ze een opvolgmail voor. Elke ochtend krijg je één kort overzicht: "4 offertes liggen al langer dan tien dagen, samen goed voor €38.000. Twee klanten zagen hun offerte gisteren nog eens na."

Win je een offerte of verlies je die, dan noteer je waarom: één klik. Na een paar maanden heb je inzicht dat de meeste bedrijven nooit krijgen: welk type werk je wint, waar je te duur bent, en hoe lang klanten gemiddeld twijfelen. Zo'n overzicht hoort op een dashboard, niet in een spreadsheet die niemand bijhoudt.

Waarom event sourcing hier goed past

Een offerte leeft. Versie 1 vertrekt, de klant wil plots een andere tegel, dan komt er versie 2, de materiaalprijs stijgt, en volgt versie 3. Welke versie heeft de klant nu ondertekend, en met de prijzen van welke dag?

Daarom schrijf je bij event sourcing elke gebeurtenis weg in plaats van een rij te overschrijven: aanvraag ontvangen, info opgevraagd, concept opgemaakt, post aangepast, versie verstuurd, aanvaard. Die log pas je nooit aan, je vult ze enkel aan.

Wat je krijgt: de volledige geschiedenis van elke offerte zonder extra werk, een sluitend antwoord als later iemand betwist wat er beloofd werd, én de mogelijkheid om met verbeterde prijslogica terug te rekenen op oude aanvragen en meteen te zien wat er anders uit was gevallen.

Voor wie het technisch wil weten

Architectuur: webformulier, mailbox en gebruikers verbinden met intake, verwerking in Go, PostgreSQL, object storage, nakijkscherm en een API met MCP, binnen een blauwe lijn die aangeeft wat van de klant is. Erbuiten staan een Europees AI-model, leveranciersprijslijsten, een offertepakket en een AI-assistent.


Alles binnen de blauwe lijn is van jou. Wat erbuiten staat, koop je aan of sluit je op aan.

  • Go voor de verwerkingspijplijn. Het is veel kleine stappen die wachten op een AI-model of een mailserver, precies waar Go goed in is.
  • Vue.js voor het nakijkscherm, het enige scherm dat er echt toe doet. Snel, toetsenbordvriendelijk, en ontworpen voor iemand die er elke dag mee werkt.
  • PostgreSQL voor de event log, de projecties en de wachtrij.
  • Object storage voor plannen, foto's en de verstuurde PDF's.
  • Een API, met MCP erbovenop. Vandaag praat je nakijkscherm ermee, morgen je AI-assistent. Waarom je dat best meteen voorziet, lees je in Is jouw software klaar voor MCP's?
  • Europese infrastructuur, op ons managed platform of bij jou, met Docker Compose op één goed beheerde server.

Eén keuze verdient extra aandacht: welk AI-model je aanvragen te zien krijgt. Plannen, adressen en foto's van woningen naar een Amerikaanse API sturen is een beslissing, geen technisch detail. Een Europees model is hier geen compromis, en voor gegevens van particuliere klanten speelt de GDPR sowieso mee. Pin ook de modelversie vast, anders veranderen je concepten ongemerkt op een dag dat je provider een update uitrolt.

Hoe weet je of het goed werkt?

Hier heb je een voordeel dat weinig AI-projecten hebben: het juiste antwoord ligt al in je archief. Elke offerte die je de voorbije jaren verstuurde is een testgeval. Geef de software de oorspronkelijke aanvraag, laat haar een concept maken, en vergelijk het met wat je toen echt hebt verstuurd.

Wat je meet:

  • Herkenning: vond de software de posten die jij toen gebruikte?
  • Koppeling: koos ze hetzelfde artikel uit je catalogus, of liet ze eerlijk open wat ze niet wist?
  • Prijs: hoe ver ligt het concept van je echte offerte, na correctie voor prijsstijgingen?

Honderd afgewerkte offertes volstaan om te starten. En draai die set na elke aanpassing aan prompt, catalogus of model opnieuw, want anders merk je achteruitgang niet. Hoe je zo een evaluatie opzet, staat in AI testen en evalueren.

Waar gaat het meestal mis?

  • Een prijslijst die niet klopt. De software rekent niet beter dan de prijzen die je haar geeft. Zit je prijskennis vandaag nog in je hoofd in plaats van in een lijst, dan begin je daar. Geen AI-project, en dat is ook goed.
  • Alles tegelijk willen. Begin met één type werk dat veel terugkomt, niet met je hele catalogus.
  • Het model laten meten op foto's. Een foto geeft context, maar geen afmetingen. Hoeveelheden komen uit plannen, meetstaten of je eigen werfbezoek. Altijd.
  • Te snel automatisch versturen. Eén foute prijs bij een goede klant kost je meer dan de tijdswinst van een hele maand.
  • Vergeten dat een offerte ook een verkoopdocument is. Een correcte maar kille lijst posten wint minder dan een offerte die laat zien dat je de vraag begrepen hebt.

Heb je hier maatwerk voor nodig?

Eerlijk antwoord: niet altijd. Werk je met vaste pakketten en weinig variatie, dan is een standaard offertepakket goed genoeg. Maatwerk begint te loonten wanneer je offertes afhangen van je eigen prijslogica, wanneer je meetstaten van architecten verwerkt, of wanneer je al een pakket hebt dat de prijs berekent maar niets doet met de aanvraag ervoor en de opvolging erna. Dan bouw je geen vervanging, maar een laag eromheen.

Veelgestelde vragen

Kan AI zelf de prijs van een offerte bepalen?

Nee, en dat wil je ook niet. AI leest de aanvraag en schrijft de teksten. De prijs komt uit je eigen prijslijst en rekenregels, en jij keurt ze goed.

Werkt dit samen met mijn bestaand offerte- of boekhoudpakket?

Meestal wel. De software levert de conceptofferte aan via de API van je pakket, of maakt een PDF in je eigen huisstijl als je nog geen pakket hebt.

Hoeveel tijd bespaart het?

Dat hangt af van hoe gestandaardiseerd je werk is. Daarom meten we het in fase 1 op je eigen offertes, voor je beslist om verder te bouwen.

Verstuurt de software offertes automatisch naar klanten?

Niet zonder jouw goedkeuring. Vragen om ontbrekende info en opvolgmails kan je wel automatisch laten vertrekken als je dat wil.

Wat met de privacy van mijn klanten?

Aanvragen bevatten namen, adressen en soms foto's van woningen. Die verwerk je best met een Europees AI-model, met een verwerkersovereenkomst en een duidelijke bewaartermijn.


Offertes zijn het werk dat je avonden opslokt én je omzet bepaalt. En wat kost een offerte bij jou vandaag, van eerste mail tot verstuurde PDF?

Vertel ons hoe een offerte bij jullie tot stand komt, dan schetsen we samen wat er in fase één zou zitten.

Gepubliceerd op 29 sep 2026
Profile picture of cofounder Mathias
Engineering
Mathias Beke

Bouwt software die snel draait, weinig kost, en volledig op Europese servers staat.