martinwolve NvI-proof: conceptvragen omzetten naar indienbare NvI-vragen
Doel en achtergrond
Deze skill zet conceptvragen voor een Nota van Inlichtingen om in vragen die zo zijn geconstrueerd dat het antwoord niet anders geformuleerd kán worden dan als antwoord op de vraag.
De methode is empirisch afgeleid uit een integrale analyse van een volledige NvI-ronde (ruim 300 vraag-antwoordparen) bij een grote aanbesteding. Kernbevinding: aanbestedende diensten beantwoorden vragen via een beperkt aantal voorspelbare routes, en de vraagvorm bepaalt in hoge mate welke route wordt gekozen. Bevestigingsvragen met een toetsbare propositie leverden verreweg het vaakst een bruikbaar antwoord op; open vragen, samengestelde vragen en kale wijzigingsverzoeken leverden sjabloonantwoorden, faseverwijzingen of afwijzingen op.
De acht antwoordroutes van aanbestedende diensten:
| # | Route | Typerend signaal |
|---|---|---|
| 1 | Inhoudelijke bevestiging | "Uw aanname is juist", "Dit bevestigen wij" |
| 2 | "Document is aangepast" zonder inhoudelijk antwoord | "Het model/document is aangepast", zonder dat de nieuwe regel in de NvI staat |
| 3 | Uitgesteld antwoord | "Wij komen hierop terug in een volgende ronde" |
| 4 | Afwijzing zonder motivering | "De eis wordt gehandhaafd", "Uw verzoek wordt afgewezen" |
| 5 | Faseverwijzing | "Dit is geen onderdeel van deze fase", "Dit wordt in de gunningsfase/uitvoeringsfase bekendgemaakt", "Dit wordt per nadere opdracht bepaald" |
| 6 | Verwijzing zonder antwoord | "Zie document X", "Zie de publicatie op het platform" |
| 7 | Sjabloonantwoord dat de vraag niet raakt | dezelfde standaardformule als antwoord op inhoudelijk verschillende vragen |
| 8 | Onbeantwoordbaar door de vraag zelf | "Er is geen concrete vraag opgenomen", "De vraag is niet duidelijk" |
Routes 1 en (mits de inhoud wordt meegeleverd) 2 zijn de enige gewenste uitkomsten. De hele methode is erop gericht routes 3 t/m 8 door de formulering onmogelijk of zichtbaar onhoudbaar te maken. In de geanalyseerde NvI-ronde kwamen bovendien aantoonbare kopieer-en-plakfouten en identieke sjabloonantwoorden op verschillende vragen voor; houd er dus rekening mee dat ook een formeel gepubliceerd antwoord de vraag onbeantwoord kan laten.
Werkwijze
Volg bij elke aanroep deze vijf stappen. Werk in de taal van de aanbesteding (standaard Nederlands). Gebruik nooit het em dash-teken.
Stap 1: Intake
Vraag de gebruiker bij de start in welk format de herziene vragen opgeleverd moeten worden (gebruik daarvoor AskUserQuestion als dat beschikbaar is): md-bestand, Word-bestand (docx), xlsx-tabel (handig voor kopiëren naar het aanbestedingsplatform) of direct in de chat. Sla deze vraag over als de gebruiker het format al heeft genoemd; kies bij een niet-interactieve of onbeantwoorde situatie md-bestand als standaard en vermeld die aanname in de oplevering.
Stel daarnaast vast, uit de input of door het na te vragen: om welke aanbesteding en welke fase het gaat (bijvoorbeeld selectiefase of gunningsfase van een niet-openbare procedure, of de vragenronde van een openbare procedure), en of er beperkingen gelden zoals een maximum aantal vragen of een indeling in rubrieken of percelen op het platform.
Neem de aangeleverde conceptvragen aan in elke vorm (losse tekst, lijst, xlsx, docx, screenshot). Splits het materiaal in afzonderlijke te toetsen eenheden. Signaleer daarbij direct:
- passages zonder vraagzin (worden door aanbestedende diensten teruggelegd als onbeantwoordbaar);
- samengestelde vragen: splitsen in losse vragen is verplicht. Elke deelvraag wordt een eigen vraag volgens het volledige format. Een a/b/c-structuur binnen één vraag is alleen toegestaan als de onderdelen onlosmakelijk samenhangen (bijvoorbeeld een terugvaloptie die pas relevant wordt bij "nee"); sluit dan af met het verzoek de onderdelen elk afzonderlijk te beantwoorden;
- duplicaten of overlap met vragen die in een eerdere NvI van dezelfde aanbesteding al zijn beantwoord (wijs de gebruiker daarop als je dit herkent).
Stap 2: Toets elke conceptvraag met de twaalfpuntschecklist
| # | Toets |
|---|---|
| T1 | Exact één expliciete vraagzin met vraagteken? Samengestelde vragen zijn gesplitst (verplicht); alleen onlosmakelijk samenhangende onderdelen mogen als genummerde a/b/c met verzoek om beantwoording per onderdeel. |
| T2 | Is de kernvraag een bevestigingsvraag met een zelfstandig leesbare propositie waarin het gewenste antwoord al staat? |
| T3 | Vindplaats (document, paragraaf, pagina) plus letterlijk citaat aanwezig? |
| T4 | Relevantie voor de huidige fase van de procedure expliciet benoemd (koppeling aan wat de indiener in deze fase moet opstellen of aantonen, zoals de aanmelding, een geschiktheidseis, een in te dienen model of de referentiekeuze)? |
| T5 | Terugvaloptie aanwezig die bij "nee" om de geldende regel, toetsbare criteria of motivering vraagt? |
| T6 | Wordt geen gelijkwaardigheids- of voorafgaand geschiktheidsoordeel over de eigen casus gevraagd? (Dat is een doodlopende route: aanbestedende diensten geven daarover vooraf geen uitsluitsel. Vraag naar het beoordelingskader, de vereiste bewijsstukken en het moment van uitsluitsel.) |
| T7 | Toon feitelijk en neutraal, zonder mening, advies of verwijt? |
| T8 | Indien wijzigingsverzoek: onderbouwd met feitelijke onjuistheid, aantoonbaar markteffect of het toepasselijke juridische kader (bij Nederlandse aanbestedingen bijvoorbeeld de Aanbestedingswet 2012 en de Gids Proportionaliteit), en om een alternatief gevraagd bij afwijzing? Kale belangenverzoeken (meer tijd, minder eisen) worden vrijwel altijd met een standaardzin afgewezen. |
| T9 | Is per antwoordroute gecheckt dat een sjabloon- of verwijzingsantwoord zichtbaar niet zou passen op deze vraag? |
| T10 | Indien het antwoord tot een documentwijziging kan leiden: is verzocht de gewijzigde tekst integraal in de NvI op te nemen? |
| T11 | Juiste rubriek of perceel-tab gekozen als het platform daarmee werkt? Bij vragen die meerdere rubrieken of percelen raken: in de algemene rubriek indienen én expliciet vragen te bevestigen dat het antwoord voor alle onderdelen geldt (aanbestedende diensten laten antwoorden niet altijd automatisch breed doorwerken). |
| T12 | Eigen aanname vastgelegd als terugvalpositie ("bij het uitblijven van een andersluidend antwoord gaan wij er bij onze inschrijving/aanmelding van uit dat ...")? |
Stap 3: Herschrijf volgens het vaste format
[1] Rubriek: <rubriek of perceel-tab op het platform; breed geldend: de
algemene rubriek>
[2] Vindplaats: <documentnaam + versie, paragraaf, pagina>
[3] Citaat: "<letterlijke tekst waarover de vraag gaat>"
[4] Constatering: <feitelijke, neutrale beschrijving van de onduidelijkheid,
tegenstrijdigheid of het knelpunt>
[5] Relevantie voor deze fase: <één zin waarom het antwoord nu nodig is voor
wat de indiener in deze fase moet opstellen of aantonen>
[6] Vraag: "Kunt u bevestigen dat <volledige, zelfstandig leesbare propositie>?"
[7] Terugvaloptie: "Indien u dit niet bevestigt, verzoeken wij u aan te geven
<welke regel dan wel geldt / welke toetsbare criteria u hanteert / welk
alternatief u biedt>, en uw antwoord te motiveren."
[8] Indien documentaanpassing mogelijk: "Wij verzoeken u de gewijzigde tekst
integraal in de Nota van Inlichtingen op te nemen."
[9] Waar passend: "Bij het uitblijven van een andersluidend antwoord gaan wij
er bij onze inschrijving/aanmelding van uit dat <propositie>."
Vraag de gebruiker om ontbrekende gegevens (vindplaats, citaat, gewenste uitkomst, rubriek) wanneer die niet uit de input of context af te leiden zijn; laat in de herschreven vraag anders een duidelijk gemarkeerde invulplek achter zoals <VINDPLAATS: document, paragraaf, pagina>. Verzin nooit zelf documentnamen, paragraafnummers of citaten: een verkeerde verwijzing maakt de vraag onbruikbaar en schaadt de geloofwaardigheid richting de aanbestedende dienst.
De propositie in [6] moet zo zijn geformuleerd dat "Uw aanname is juist" als antwoord, samen met de vraag, een complete regel oplevert die zonder verdere interpretatie in het biddossier kan. Vermijd voornaamwoorden en verwijzingen die alleen in eigen context betekenis hebben.
Stap 4: Red-team toets (verplichte laatste stap per vraag)
Formuleer per herschreven vraag het slechtst denkbare antwoord dat formeel toch "een antwoord" is, gekozen uit de acht routes (bijvoorbeeld "Zie document X", "Dit is geen onderdeel van deze fase", "Het model is aangepast", een standaardsjabloon). Beoordeel: levert dat antwoord de indiener iets op, of blijft de vraag dan onbeantwoord? In het tweede geval is de vraag nog niet goed genoeg; herformuleer tot het ontwijkende antwoord zichtbaar niet meer past. Rapporteer per vraag welk worst-case antwoord is getoetst.
Stap 5: Lever twee producten op
De oplevering bestaat altijd uit twee gescheiden producten. Zo kan de vragenset direct de indieningsroute in, terwijl de verantwoording apart leesbaar blijft voor het team.
Product A: de indienbare vragenset, in het bij stap 1 gekozen format. Deze bevat uitsluitend de herschreven vragen, elk volledig volgens het format uit stap 3 en klaar om op het aanbestedingsplatform te plakken, met per vraag de beoogde rubriek en de eventueel nog in te vullen plekken duidelijk gemarkeerd. Geen toetsverantwoording in dit product.
Product B: een beknopt wijzigingsverslag (md, tenzij de gebruiker anders vraagt). Bovenaan een samenvattende tabel (vraag, rubriek, verwachte antwoordroute vóór en na herschrijving, nog aan te leveren gegevens). Daarna per vraag een kort blok:
## Vraag <n>: <korte titel>
**Oorspronkelijke conceptvraag**
> <letterlijke input>
**Wat is aangepast en waarom** (beknopt, 3 tot 6 regels)
<de belangrijkste ingrepen, elk met de reden: welk checklistpunt faalde en
welke ontwijkende antwoordroute daarmee wordt afgesneden>
**Verwachte antwoordroute bij ongewijzigde indiening**: route <#> (<naam>)
**Red-team toets**: <worst-case antwoord> -> <waarom de herschreven vraag
daartegen bestand is>
**Nog aan te leveren door de indiener**: <invulplekken zoals vindplaats,
citaat of rubriekkeuze; "geen" indien compleet>
Houd het verslag beknopt: het legt uit wat er is veranderd en waarom, het herhaalt niet de volledige herschreven vragen (die staan in product A). Gebruik voor bestandsnamen het patroon <onderwerp>-v<JJJJMMDD> en bied aan de bestanden naar de projectmap te schrijven.
Algemene aandachtspunten bij advisering
- Rechtsverwerking: aanbestedingsdocumenten bevatten vrijwel altijd een waarschuwingsplicht en rechtsverwerkingsclausule (in de Nederlandse praktijk mede gestoeld op het Grossmann-arrest). Onduidelijkheden die redelijkerwijs eerder geconstateerd konden worden mogen niet worden bewaard tot een latere ronde. Adviseer daarom nooit een bekend punt "voor later" te bewaren; behandel elke vragenronde als mogelijk de laatste kans.
- Toets bij een vervolgronde eerst de eerder gegeven antwoorden tegen de oorspronkelijke vragen. Een ontwijkend, onvolledig of aantoonbaar bij een andere vraag horend antwoord wordt hernomen met een verwijzing naar het vraag- en antwoordnummer en de zin dat het gepubliceerde antwoord geen betrekking heeft op de gestelde vraag.
- Gelijkwaardigheid van certificaten en referenties: vraag nooit om een voorafgaand oordeel over de eigen casus; vraag naar het beoordelingskader (bij Nederlandse aanbestedingen: artikel 2.96 Aanbestedingswet voor gelijkwaardige certificaten) en het moment waarop uitsluitsel volgt.
- Vertrouwelijkheid: vraagteksten worden doorgaans (geanonimiseerd) aan alle gegadigden gepubliceerd. Formuleer vragen zo dat publicatie geen eigen zwaktes of strategie prijsgeeft, of markeer ze expliciet als vertrouwelijk in te dienen, wetend dat de aanbestedende dienst daarover zelf beslist.
- Wees streng in de toetsing maar constructief in de herschrijving: elke conceptvraag verdient een indienbare versie, ook als de oorspronkelijke vraag zwak is.
- Neem inhoudelijke stellingen van de gebruiker (bijvoorbeeld welke eis onwerkbaar is) over als input, maar presenteer ze in de herschreven vraag altijd feitelijk en controleerbaar.
- Dit is tenderondersteuning, geen juridisch advies; vermeld dat alleen wanneer een vraag aanbestedingsrechtelijke positiekeuzes raakt (zoals rechtsverwerking of een voorgenomen bezwaar).
Wijzigingshistorie
- 1.0 (2026-09-08): eerste versie, gegeneraliseerd vanuit de skill eu400-proof naar alle Nederlandse aanbestedingen, inclusief beoordeling van gegeven antwoorden.