Scripts
Module 4 — Textream-script
Kopieer volledig script
Download .txt
Open presentatie
Terug naar academy
MODULE 4 — BUILDR FOUNDATION [START OP SLIDE 1] Welkom bij Module 4 van Buildr Foundation. In deze module breng je alles samen in echte systemen: van ontwerp naar bouwen, testen, live zetten en onderhouden. [KLIK — NAAR SLIDE 2] Tijd om alles wat je hebt geleerd samen te brengen in één echt systeem. Geen theorie meer, maar een volledige build, van leeg vel papier tot iets dat daadwerkelijk werkt. Het voorbeeld dat we gebruiken: een verbouwingsbedrijf krijgt via het contactformulier op de website tientallen aanvragen per week binnen. Een deel daarvan is serieus en past precies bij wat het bedrijf doet. Een ander deel is te klein, verkeerde locatie, of simpelweg nog niet concreet genoeg. Op dit moment leest iemand alles met de hand door, en dat kost makkelijk een paar uur per week, met als risico dat een goede aanvraag pas na drie dagen wordt opgepikt. [KLIK — NAAR SLIDE 3] Stap één, het ontwerp. Net als in Module 2 schrijf je eerst de vijf zinnen op. Trigger: een nieuwe aanvraag komt binnen via het contactformulier. AI-verwerking: de AI beoordeelt de aanvraag op locatie, type project en budget-indicatie, en geeft een score met een korte onderbouwing. Orchestratie: scoort de aanvraag hoog, dan gaat er meteen een seintje naar de verkoper. Scoort die laag, dan krijgt de aanvrager een vriendelijk automatisch antwoord met een paar verduidelijkende vragen. [KLIK — NAAR SLIDE 4] Opslag: elke aanvraag, score en onderbouwing wordt vastgelegd. Output: een bericht naar de verkoper bij een hoge score, of een automatisch antwoord bij een lage score. Stap twee, de context vastleggen. Voordat je gaat bouwen, leg je de criteria van dit bedrijf één keer vast, in een Project of in een samenvattingsbestand zoals je in Module 3 hebt geleerd: wat telt als een goede aanvraag, welke locaties wel of niet, welk soort projecten passen bij het bedrijf. Die criteria gebruikt de AI bij elke nieuwe aanvraag opnieuw, zonder dat jij ze moet herhalen. Stap drie, het plan. [KLIK — NAAR SLIDE 5] Je opent de repo voor dit systeem in Claude Code, en je vraagt niet meteen om te bouwen. Een voorbeeld van de prompt die je hier zou gebruiken: "Ik wil een systeem dat nieuwe contactformulier-aanvragen automatisch beoordeelt op basis van de criteria die ik heb vastgelegd, een score teruggeeft met onderbouwing, en bij een hoge score een bericht stuurt naar de verkoper. Voordat je begint te bouwen: leg uit hoe je dit zou aanpakken, welke bestanden je nodig denkt te hebben, en wat de uitkomst precies wordt. Begin nog niet met bouwen." Je checkt dat plan, en pas als het klopt, geef je akkoord om te bouwen. Stap vier, bouwen en testen. [KLIK — NAAR SLIDE 6] Claude Code bouwt het systeem stap voor stap, en jij test het met echte aanvragen uit het verleden van dit bedrijf, niet met verzonnen voorbeelden. Klopt de score? Mist er een belangrijk criterium? Dat stuur je bij totdat het systeem aanvragen op precies dezelfde manier beoordeelt als de eigenaar dat zelf zou doen. De praktische conclusie: dit is de volledige cyclus, van ontwerp tot werkend systeem, en je gaat die cyclus de komende twee videoundefineds nog twee keer doorlopen, voor andere problemen. Het patroon blijft steeds hetzelfde, alleen de details veranderen. [KLIK — NAAR SLIDE 7] Tweede systeem. Een recruitmentbureau wil nieuwe kandidaten benaderen op LinkedIn, maar elk bericht handmatig personaliseren kost te veel tijd, terwijl een generiek kopieer-plak bericht nauwelijks reacties oplevert. Het ontwerp. Trigger: een nieuwe kandidaat wordt toegevoegd aan de lijst om te benaderen. AI-verwerking: de AI schrijft een persoonlijk eerste bericht, gebaseerd op de functie, het bedrijf en iets specifieks uit het profiel van de kandidaat. [KLIK — NAAR SLIDE 8] Orchestratie: het bericht wordt niet automatisch verstuurd, het gaat eerst naar een overzicht voor controle, zodat een mens er nog even naar kijkt voordat het de deur uit gaat. Opslag: elk verstuurd bericht wordt vastgelegd, samen met of er een reactie op kwam, zodat je na een tijdje kan zien welke aanpak het beste werkt. Output: een klaarstaand, persoonlijk bericht in het overzicht, in plaats van een leeg vel waar de recruiter zelf nog iets bij moet verzinnen. De AI-stap is hier het belangrijkste onderdeel, en de kwaliteit daarvan hangt volledig af van de prompt. Een voorbeeld: "Schrijf een eerste LinkedIn-bericht voor [naam], die werkt als [functie] bij [bedrijf]. [KLIK — NAAR SLIDE 9] Gebruik deze toon: direct, kort, geen overdreven enthousiasme. Verwijs naar iets specifieks uit hun profiel of recente activiteit: [specifiek detail]. Houd het bericht onder de vijftig woorden, en eindig met een open vraag, geen harde verkooppraat." Het verschil tussen dit en "schrijf een LinkedIn-bericht voor deze persoon" is precies het verschil dat je in Module 1 hebt gezien tussen een vage en een scherpe prompt. Let op de menselijke controle in dit systeem. [KLIK — NAAR SLIDE 10] Bij outreach is het verstandig om niet alles volledig automatisch te versturen. Eén kort moment van controle voordat een bericht de deur uit gaat, voorkomt rare of ongepaste berichten, en houdt het persoonlijke gevoel overeind dat juist het hele punt van dit systeem is. De praktische conclusie: hetzelfde patroon als bij de lead qualifier, ontwerp, context vastleggen, plan laten maken, bouwen en testen met echte profielen. Het enige verschil is waar in de flow je een mens laat meekijken voordat iets de deur uitgaat. [KLIK — NAAR SLIDE 11] Derde systeem. Een klein marketingbureau moet voor meerdere klanten elke week nieuwe social posts klaarzetten, en heeft daar simpelweg niet de tijd of het team voor. Het ontwerp. Trigger: elke maandagochtend gaat het systeem automatisch aan het werk. AI-verwerking: de AI schrijft een paar conceptposts, gebaseerd op vaste contentpijlers en op de posts die de afgelopen periode het beste hebben gepresteerd. [KLIK — NAAR SLIDE 12] Orchestratie: de conceptposts gaan naar een overzicht voor goedkeuring, niemand publiceert hier automatisch zonder controle. Opslag: elke gepubliceerde post en de bijbehorende resultaten worden bijgehouden, zodat het systeem na een paar weken weet wat wel en niet werkt voor deze specifieke klant. Output: een overzicht met klaarstaande conceptposts, in plaats van een leeg blanco scherm op maandagochtend. Hier zie je de opslag-laag op zijn best. [KLIK — NAAR SLIDE 13] De eerste paar weken schrijft de AI conceptposts op basis van een algemene briefing. Daarna geef je het de resultaten van de afgelopen periode mee. Een voorbeeld van die prompt: "Schrijf drie conceptposts voor deze week over [onderwerp], gebaseerd op deze contentpijlers: [pijler 1], [pijler 2]. Hier zijn de twee best presterende posts van de afgelopen maand: [voorbeeld 1], [voorbeeld 2]. Gebruik een vergelijkbare toon en structuur, want dat bleek te werken voor deze doelgroep." [KLIK — NAAR SLIDE 14] Zo wordt het systeem elke week een klein beetje slimmer, zonder dat jij iets handmatig moet bijhouden. De praktische conclusie: drie systemen, drie verschillende problemen, en steeds hetzelfde patroon. Ontwerp op papier, context vastleggen, plan laten maken, bouwen en testen met echte data. Zodra je dat een paar keer hebt gedaan, voelt het niet meer als drie losse vaardigheden, maar als één herhaalbaar proces. [KLIK — NAAR SLIDE 15] Je hebt nu drie systemen die werken op jouw laptop, in Claude Code, terwijl jij ernaar kijkt. Maar een systeem dat alleen werkt als jouw laptop open is en jij erbij zit, is geen systeem dat een bedrijf kan vertrouwen. Deployment is de stap waarmee je dat verandert: van iets dat alleen bij jou draait, naar iets dat altijd draait, ook als jij slaapt. In de praktijk betekent dit dat je systeem een vaste plek nodig heeft om te blijven draaien, meestal een simpele server in de cloud die continu aanstaat. Daar luistert je systeem de hele tijd naar triggers, en voert het de stappen uit zodra er iets gebeurt, zonder dat jij iets hoeft te doen. [KLIK — NAAR SLIDE 16] Een paar dingen zijn hierbij belangrijk, en die zijn allemaal terug te voeren op wat je al weet. De sleutels en wachtwoorden die je systeem gebruikt, moeten veilig worden opgeslagen, niet los ergens in de code waar iedereen ze kan zien. Het systeem moet zelf weer opstarten als het een keer crasht, in plaats van stil te blijven liggen totdat iemand het toevallig opmerkt. En jij moet op elk moment kunnen zien of het systeem nog actief is, zodat je niet pas ontdekt dat iets stuk is wanneer een klant erover belt. [KLIK — NAAR SLIDE 17] Een simpele checklist voordat iets echt live gaat: werkt het met echte data, niet alleen met testvoorbeelden. Staan de sleutels veilig opgeslagen, niet zichtbaar in de code zelf. Weet je hoe je kan checken of het systeem nog draait. En heb je een idee wat je doet als het toch een keer stopt. [KLIK — NAAR SLIDE 18] Als je op alle vier ja kan zeggen, is het systeem klaar om daadwerkelijk gebruikt te worden door een bedrijf. De praktische conclusie: deployment is niet het einde van het bouwen, het is het moment waarop een experiment een systeem wordt waar een bedrijf op kan vertrouwen. Zonder deze stap heb je een demo. Met deze stap heb je iets dat je daadwerkelijk kan verkopen. [KLIK — NAAR SLIDE 19] Een systeem live zetten voelt als de finish, maar het is eigenlijk het begin van een nieuwe, veel kleinere gewoonte: licht onderhoud. Dit is waar Module 2 over waarom systemen stuk gaan, weer helemaal terugkomt, maar dan in de praktijk in plaats van in theorie. Onderhoud betekent hier niet uren werk per week. [KLIK — NAAR SLIDE 20] Het betekent een paar minuten, regelmatig. Bijvoorbeeld bij de lead qualifier uit deze module: één keer per maand kijk je kort of de scores nog steeds kloppen met wat de eigenaar zelf zou geven, of er een nieuw veld op het contactformulier is bijgekomen dat het systeem nog niet kent, en of er foutmeldingen zijn opgebouwd die om aandacht vragen. Als er iets niet klopt, ga je niet vanaf nul zoeken. [KLIK — NAAR SLIDE 21] Je gaat terug naar de checklist uit Module 2: zijn de sleutels nog geldig, is het dataformaat nog hetzelfde, loop je tegen een limiet aan, vuurt de trigger nog af, en klopt de configuratie nog. Je opent de repo van dat specifieke systeem in Claude Code, beschrijft wat je ziet, en laat het meekijken: "Dit systeem geeft sinds gisteren geen meldingen meer voor nieuwe aanvragen, kan je checken wat er aan de hand is." [KLIK — NAAR SLIDE 22] Negen van de tien keer wijst die checklist je binnen een paar minuten naar de oorzaak. Dit lichte ritme, kort checken, bijsturen waar nodig, voorkomt het echte probleem: een klant die drie weken later belt omdat iets allang niet meer werkte, zonder dat jij het wist. Dat is het moment waarop vertrouwen verdwijnt, en dat is precies te voorkomen met een paar minuten per maand. [KLIK — NAAR SLIDE 23] De praktische conclusie: bouw onderhoud in als een vast, klein gewoonte, niet als iets dat je pas doet als een klant boos belt. Een paar minuten per systeem, per maand, is alles wat het kost om vertrouwen overeind te houden.