Een scopedocument schrijven voor een AI-agent

Gepubliceerd in augustus 2026.

TL;DR: Een scopedocument is wat “ik wil een AI-agent voor mijn bedrijf” omzet in een getal dat je kunt offreren en een klant kan tekenen. Het heeft zes onderdelen nodig: de trigger, de inputs, de outputs, de tools die het aanraakt, wat expliciet is uitgesloten, en een schriftelijke lijst met acceptatietests. Schrijf het voordat je een bouwvergoeding offreert, niet erna. Ik prijs het als een vast deliverable van $500–$1.000 voor een audit, los van de build.

[Operatorsperspectief] Ik draai meer dan 30 agents in productie voor een consultingmerk en Pickleland, een pickleballlocatie in Pflugerville, TX, en ik heb bovenop die ervaring agentbouwwerk voor klanten gescoped. De meest voorkomende reden dat een agentopdracht misgaat, is niet de code — het is dat niemand heeft opgeschreven wat “klaar” betekende voordat de factuur de deur uit ging. Een scopedocument lost dat in één sessie op. Het is het minst glamoureuze deliverable dat ik produceer, en het deliverable dat de meeste ruzies bespaart.

Inhoudsopgave

Waarom een scopedocument, geen offerte-e-mail

Een offerte-e-mail beschrijft wat je gaat doen. Een scopedocument definieert hoe “klaar” eruitziet — specifiek genoeg dat jij en de klant de afgeronde agent er allebei tegen kunnen afzetten en, zonder gesprek, het erover eens kunnen zijn of hij is geslaagd.

Dat onderscheid is belangrijk omdat AI-agentprijzen alleen werken als de bouwvergoeding vastzit aan iets vasts. Offreer een vaste prijs tegen een ongedefinieerde scope en je hebt een getal geoffreerd waar je niet echt tegen kunt leveren — het mentale model van de klant van “een AI-agent voor mijn bedrijf” blijft gratis uitbreiden totdat jij terugduwt, en terugduwen na de aanbetaling is een vervelender gesprek dan de grens definiëren voordat het zover is.

Ik schrijf er een voor elke build, ook kleine. Een single-workflow-agent krijgt een halve pagina. Een multi-agentsysteem krijgt het volledige document. Het format verandert niet — alleen de lengte.

De zes dingen die een scopedocument nodig heeft

1. De trigger. Wat start de agent — een formulierinzending, een geplande tijd, een inkomende e-mail, een webhook van een andere tool. Benoem de exacte trigger, niet een categorie trigger. “Draait wanneer een leadformulier wordt ingediend” is scope. “Handelt inkomende leads af” is dat niet.

2. De inputs. Welke data de agent ontvangt en waar die vandaan komt. Somme de velden op, niet alleen de bron — “naam, e-mail, bedrijfsgrootte, en het vrije-tekstveld van het Typeform-formulier,” niet “de formulierdata.”

3. De outputs. Wat de agent produceert en waar het naartoe gaat. Dezelfde regel: benoem de bestemming en het format. “Plaatst een conceptantwoord in het #leads-Slackkanaal voor menselijke goedkeuring” is scope. “Reageert op leads” is dat niet.

4. De tools en integraties die het aanraakt. Elke API, database of platform die de agent aanroept. Dit is ook waar je opschrijft wat je expliciet niet integreert — een klant die ervan uitgaat dat hun CRM inbegrepen is omdat ze het één keer noemden tijdens het intakegesprek, is de meest voorkomende bron van scope creep die ik heb gezien.

5. Wat is uitgesloten. Een korte, expliciete lijst van dingen die de agent niet zal doen, zelfs als ze aanverwant klinken. Bouw je een leadclassificatie-agent, schrijf dan “verstuurt geen uitgaande berichten” op, ook al lijkt dat vanzelfsprekend — vanzelfsprekend voor jou is niet vanzelfsprekend voor een klant die nog nooit software heeft gescoped.

6. De lijst met acceptatietests. De daadwerkelijke lijst met gevallen waaraan de afgeronde agent moet voldoen voordat de eindbetaling verschuldigd is. Niet “werkt goed” — specifieke, controleerbare gevallen: “classificeert correct 9 van de 10 voorbeeldleads uit de aangeleverde dataset,” “plaatst succesvol in het gekoppelde Slackkanaal zonder handmatige tussenkomst,” “handelt een misvormde inzending (ontbrekend e-mailveld) af zonder te crashen.” Dit is het belangrijkste onderdeel van het document, omdat het het onderdeel is waar beide partijen later naar kunnen wijzen zonder opnieuw te bediscussiëren wat er bedoeld was.

De template

Dit is de daadwerkelijke structuur die ik gebruik. Kopieer hem, vul de zes secties in, en je hebt een document waar je een prijs tegenover kunt zetten.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

De regels voor de bouwvergoeding en de retainer bestaan zodat de prijs direct verankerd is aan de scope erboven — zie hoe ik beide getallen dimensioneer als je nog nooit een build hebt geprijsd. Een klant die dit document tekent, tekent in dezelfde beweging voor de scope én de prijs, en dat is het hele punt.

Hoe ik het gesprek voer dat dit document oplevert

Ik prijs de scopingsessie zelf als een vaste audit van $500–$1.000, los van de bouwvergoeding — nooit erin verwerkt, ook niet wanneer de klant doorgaat. Twee redenen: het voorkomt dat de scopingfase onbetaald verkoopwerk wordt, en het zorgt ervoor dat de klant het gesprek serieus neemt in plaats van het als een gratis consult te behandelen.

Het gesprek zelf duurt 30–45 minuten en is opgebouwd rond de zes secties hierboven, in die volgorde. Ik laat het gesprek niet afdwalen naar “wat een AI-agent theoretisch zou kunnen doen voor je bedrijf” — dat is een ander, duurder gesprek, en het is het gesprek dat documenten oplevert die niemand kan prijzen. Ik vraag eerst naar de trigger, omdat een klant die niet kan benoemen wat het proces start, meestal nog geen workflow heeft die stabiel genoeg is om te automatiseren — iets wat het waard is om naar boven te halen voordat een van jullie zich aan een build committeert.

Verstuur de prompt, niet de lege pagina

Ik schrijf de eerste versie van het document niet met de hand. Ik neem mijn gespreksnotities — vaak niet meer dan een rommelige alinea met bulletpoints — en plak dit in Claude:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

Die laatste instructie — hiaten markeren in plaats van ze op te vullen — is het onderdeel dat ertoe doet. Een model bedenkt maar al te graag een plausibel klinkende acceptatietest om het document af te maken, en een plausibel klinkende test die niet overeenkomt met wat de klant daadwerkelijk bedoelde, is erger dan een leemte waar je naar moet gaan vragen.

Veelgemaakte fouten die ik nog steeds zie

De exclusiesectie als laatste schrijven, of overslaan. De exclusiesectie is degene die de meeste mensen als optioneel behandelen. Het is degene die de meeste geschillen voorkomt. Schrijf hem voor de acceptatietests, niet erna.

Acceptatietests die gedrag beschrijven in plaats van resultaten. “De agent moet de toon van de klant begrijpen” is gedrag. “Het conceptantwoord van de agent wordt zonder wijzigingen goedgekeurd in 7 van de 10 voorbeeldgevallen” is een resultaat. Alleen resultaten zijn controleerbaar.

Scopen op basis van één gesprek zonder schriftelijke notities. Als het scopedocument het eerste schriftelijke artefact van de opdracht is, reconstrueer je het gesprek dagen later uit je geheugen. Maak notities tijdens het gesprek, in de volgorde van de zes secties, en het document schrijft zichzelf grotendeels.

De klant de scope laten schrijven. Een klant die in eigen woorden beschrijft wat hij wil, is input voor het document, niet het document zelf. Zijn taal is meestal feature-vormig (“ik wil dat het mijn leads afhandelt”), niet test-vormig. Dat vertalen naar controleerbare acceptatiecriteria is de eigenlijke waarde van de scopingsessie — daarom is het een betaald deliverable en geen formulier dat ze zelf invullen.

De tools die ik hiervoor gebruik

Claude stelt het document op basis van ruwe gespreksnotities met de prompt hierboven, en markeert hiaten in plaats van te gokken.

Notion is waar het afgeronde scopedocument leeft, gedeeld met de klant voordat er een aanbetaling wordt geïncasseerd — dezelfde plek waar ik de rest van het papierspoor van de opdracht bijhoud.

Airtable volgt welke opdrachten in scoping zitten versus getekend versus in de build, één rij per klant, zodat een scopedocument nooit weken onondertekend blijft liggen zonder dat iemand het merkt.

FAQ

Hoe lang moet een scopedocument zijn?

Zo lang als nodig is om elke acceptatietest controleerbaar te maken, en niet langer. Een single-workflow-agent kan een halve pagina zijn. Een multi-agentsysteem met meerdere integraties kan wel twee of drie pagina’s beslaan. Lengte is niet het doel — een klant en een developer die de acceptatietests onafhankelijk van elkaar lezen en het erover eens zijn of ze zijn geslaagd, is het doel.

Wat als de klant de scope wil wijzigen na ondertekening?

Dat is een change request, apart geprijsd en geoffreerd voordat het werk begint — leg die voorwaarde vast in het document zelf, zoals in de template hierboven. Een scopedocument dat stilzwijgend kan worden uitgebreid na ondertekening, is eigenlijk geen scopedocument.

Heb ik een scopedocument nodig voor heel kleine automatiseringen?

Ja, gewoon een korte. De waarde zit niet in de lengte — het zit erin dat je een schriftelijke lijst met acceptatietests hebt voordat je begint te bouwen, zodat “klaar” een checklist is in plaats van een gevoel. Ik heb kleine, informeel gescopede opdrachten langer zien duren dan grote, correct gescopede opdrachten, precies om deze reden.

Van wie is het scopedocument zelf — is het onderdeel van het deliverable?

Ik behandel het als eigendom van de klant, ongeacht of ze doorgaan naar een build, omdat ze hebben betaald voor de audit die het opleverde. Wat ik behoud, is de onderliggende template en prompt, op dezelfde manier als ik herbruikbare scaffolding tussen opdrachten behoud — de structuur van het document is van mij, de ingevulde inhoud over hun specifieke bedrijf is van hen.

Volgende stappen: Mijn AI Agents for Beginners-cursus behandelt het bouwen van de agents die zo’n scopedocument beschrijft. Het cowork-programma is voor operators die een gestructureerde omgeving willen om dit soort werk te oefenen en bouwen. Wil je liever het scopedocument voor je laten schrijven, boek dan een sessie van 30 minuten.