Beste Renzo,
Dank voor de heldere opdracht. Ik heb je mail gecombineerd met wat Hamza en Marcella de afgelopen weken hebben verteld, en dat geeft samen een scherper beeld dan elk gesprek los.
Wat mij het meest opvalt: de echte drijfveer achter dit project is niet gemak, maar risicospreiding. Marcella zei het zelf letterlijk: een groot deel van jullie kernproces hangt aan één persoon, en als zijn vliegtuig neerstort heeft GreenFox een probleem. Dat besef stuurt mijn hele advies. De bot is niet in de eerste plaats een handigheidje voor conceptmails. Het is de plek waar kennis die nu in iemands hoofd zit, landt in een vorm die versioneerd, toetsbaar en overdraagbaar is. Alles hieronder is daarop gebouwd.
Twee andere dingen neem ik mee. Hamza is praktisch al bezig met hardware en bewaakt terecht de AVG-kant, en jullie hebben een dichtgetimmerde Microsoft-omgeving met Intune-beheerde laptops en telefoons. Dat laatste is een groot voordeel, geen bijzaak. En jullie hebben bij de demo van Appel gezien dat het kernmechanisme dat jullie nodig hebben al werkt: een bot die alleen antwoordt uit aangeleverde stof, met bron, en netjes weigert zodra een vraag buiten die stof valt. Dat is precies het gedrag dat de GreenFox-kennisbot moet hebben.
Dan de vier vragen.
Bouw het als een interne webapplicatie binnen jullie Microsoft-omgeving. Geen app-store-app. Hamza beheert Intune volledig en kan telefoons met één druk resetten, dus een webapp achter jullie eigen inlog is veilig bereikbaar op elke laptop en Fairphone die jullie al beheren. Dat scheelt maanden bouwtijd en gebruikt de beveiliging die er al staat.
Over de hardware: voor lokale taalmodellen is de hoeveelheid geheugen bepalend, niet de rekenkracht. Een RTX 3090 heeft 24GB videogeheugen en dat begrenst je op middelgrote modellen. Een Apple M-chip met unified memory (64GB of meer) draait grotere modellen op één stille, zuinige machine. Hamza's gevoel klopte dus. Mijn advies: koop niet te groot. Het model is straks het meest vervangbare onderdeel van de hele opzet. Wat blijvend waarde heeft staat eromheen: de kennisbasis, de prompts, de profielen, de protocollen. Zorg dat die in versiebeheer op jullie eigen server staan en dat het model erachter een verwisselbaar blokje is.
Dat raakt ook het vendor-lock-in-punt uit het gesprek met Hamza. Werk in twee sporen. Spoor één: bouw en test snel met een API van een grote aanbieder, in een EU-regio, zonder dat er ooit kandidaat- of klantgegevens in gaan. Spoor twee: draai parallel een lokaal of Europees model (Mistral is het bekijken waard, Hamza keek er al naar) op de eigen server voor het gevoelige werk. Zo houd je bouwsnelheid én ben je niet afhankelijk van één Amerikaanse partij. Valt die weg of verandert regelgeving, dan schakel je om en behoud je je voorsprong. En omdat het op een aparte server draait, neemt het lokale model niet iemands werkmachine over, wat Hamza terecht niet wilde.
De architectuur zelf: één centrale motor, per medewerker een dun persoonlijk laagje. De centrale bot bevat de kennisbasis en de vaste regels. Elke persoonlijke assistent is dezelfde motor plus een profielbestand en een eigen gespreksgeheugen. Zo onderhoudt Hamza één systeem in plaats van straks vijftien losse bots, en is elke nieuwe medewerker vooral een nieuw profiel aanmaken.
Nog één afspraak die past bij jullie zelfstandigheidseis: alles wat ik adviseer leggen jullie vast in eigen protocol-documenten op eigen server. Mijn coaching moet zichzelf overbodig maken, niet onmisbaar.
Het Proceshuis is nu geschreven voor mensen. Voor een bot moet het in kleine, adresseerbare blokken. Eén pagina per processtap, met bovenaan vaste velden: welk hoofdproces, welke stap, wie is eigenaar, welk systeem (Carerix, Easyflex, WIZZR), welke termijn geldt, welke versie en datum. De bot antwoordt dan nooit uit een vage lap tekst maar altijd uit een specifiek, benoembaar blok.
De vijftien kernregels behandel je apart. Die gaan niet mee in de zoek-loterij maar staan altijd in het geheugen van de bot, als harde laag boven alles. Geen onboarding zonder kredietcheck en vrijwaring nooit tekenen mogen nooit afhangen van of de bot toevallig het juiste stukje tekst terugvond.
Alle getallen en termijnen zet je in tabellen, niet in lopende tekst. De omrekenfactor 2,53, de contactcyclus dag 3, 10 en 17, de servicebeloften, het Doorzaam-budget van 2.500 euro, de 6-wekentermijn bij offboarding. Taalmodellen maken de meeste fouten met cijfers die in proza verstopt zitten.
Dan het belangrijkste: citaatplicht en scope-weigering. Elke instructie aan de bot bevat drie regels. Antwoord alleen uit de meegeleverde kennisbasis. Noem bij elk antwoord de bron (proces, stap, versie). Staat het antwoord er niet in, zeg dan letterlijk dat je het niet weet en verwijs naar Hamza. Jullie hebben bij Appel live gezien dat dit werkt: de vraag buiten de biologiestof werd netjes geweigerd met een verwijzing terug naar de stof. Dat is geen belofte, dat is gedemonstreerd gedrag.
En je toetst het. Maak een vaste testset van zo'n veertig vragen met de juiste antwoorden erbij, plus tien strikvragen waarvan het antwoord bewust niet in het Proceshuis staat. Na elke wijziging in de kennisbasis draait Hamza die set. Elke goede weigering op een strikvraag is een bewijs dat het systeem eerlijk blijft. Deze testset is meteen jullie kwaliteitsdocumentatie richting AVG en audits: je kunt altijd laten zien hoe je de betrouwbaarheid bewaakt.
Twee lagen, zoals je zelf al stelde. De GreenFox-laag is voor iedereen gelijk: huisstijl, toon, de schrijfregels (geen AI-mail, geen opsmuk). De persoonlijke laag is één profielbestand per medewerker met rol, processen waarin diegene werkt, systemen, ervaringsniveau, voorkeuren en schrijfstijl.
Die schrijfstijl bouw je niet met een beschrijving maar met voorbeelden. Laat de medewerker tien tot twintig eigen, goedgekeurde verstuurde mails aanleveren (met eigen toestemming, ontdaan van kandidaat- en klantgegevens). De bot leert de stijl uit de voorbeelden. Elke correctie die de medewerker daarna geeft, wordt als feit in het profiel bijgeschreven, zodat de bot over sessies heen blijft leren wie hij bedient. Zo werkt mijn eigen geheugen ook, en het is het verschil tussen een bot die went en een bot die blijft irriteren.
Eén waarschuwing, en die komt rechtstreeks uit het gesprek met Marcella. Jullie medewerkers voelen zich snel gecontroleerd, en het intercedentenvak trekt jonge mensen die feedback al gauw horen als kritiek. Maak daarom vanaf dag één de afspraak, en spreek die hardop uit: de assistent werkt voor de medewerker, niet over de medewerker. Wat iemand met zijn bot bespreekt is van hem. Er gaat niets naar leidinggevenden, het is geen beoordelingsinstrument. De coach-kant die Marcella wil (beter leren coachen, betere gesprekken voeren) bouw je als privé-suggesties die de medewerker zelf kan aannemen of negeren, aansluitend op de gedrags- en houdingstrainingen die jullie al doen. Doe je dit niet expliciet, dan verlies je het draagvlak voordat de techniek de kans krijgt.
Praktisch: start elk profiel met een gesprek van een half uur waarin Hamza (of de bot zelf) vraagt naar taken, terugkerende klussen en wat de meeste tijd kost. Het profiel is een levend document onder versiebeheer, net als de rest.
De snelste route naar jullie succescriterium (medewerker gebruikt de bot na twee weken uit zichzelf en benoemt tijdwinst) is deze volgorde.
Eerst de kennisbasis en de testset: het Proceshuis-deel Plaatsen en Ontwikkelen omzetten naar blokken, kernregels apart, getallen in tabellen, testset erbij. Dit is het fundament en meteen de grootste stap in het verkleinen van het risico dat kennis maar bij één persoon zit, want vanaf dit moment bestaat die kennis buiten één hoofd.
Dan de kennisvragen-functie met citaatplicht als eerste zichtbare feature. Betrouwbaar antwoord op hoe zat het ook alweer met fase A zonder beding of welke termijn geldt bij offboarding, altijd met bron. Dit bouwt vertrouwen, en vertrouwen bepaalt of mensen terugkomen.
Daarna de ochtendbriefing. Dit is de gewoontevormer: één vast moment per dag waarop de bot iets nuttigs brengt (lopende termijnen, aandachtspunten, agenda van de dag). Het succescriterium gaat over uit zichzelf gebruiken, en niets bouwt een gewoonte zo goed als een dagelijks vast contactmoment. Bouw en test dit eerst volledig op nepdata; ik heb Hamza al gevraagd om een testmailbox en fictieve gegevens, precies hiervoor. Alle schakels moeten op orde zijn voordat er iets echts doorheen gaat.
Dan pas conceptmails in eigen stijl (het profiel uit vraag c moet er eerst zijn) en daarna de contract- en subsidiebewaking, omdat die koppelingen met Easyflex en WIZZR vraagt en dus de meeste bouwtijd kost. Alles blijft concept tot een mens het goedkeurt, conform jullie eigen regel.
De tweede gebruiker (Hasjiem of Patrick) start pas als de eerste het succescriterium haalt. Dan hergebruik je de complete motor en maak je alleen een nieuw profiel. Dat is meteen de test van je hele model: als gebruiker twee in dagen draait in plaats van weken, klopt de architectuur en kun je opschalen naar de rest.
Fase 2, het realtime meeluisteren via Plaud, blijft geparkeerd tot fase 1 bewezen is. Terecht van jullie. Ideeën die onderweg opkomen (Marcella noemde bijvoorbeeld communicatie met opdrachtgevers) gaan naar het whiteboard, niet in de bouw.
Praten over citaatplicht is één ding, het zien werken is iets anders. Daarom bouw ik voor jullie een demo-kennisbot in de stijl van Appel, die jullie bij de videocall al zagen. Per proces (Plaatsen en Ontwikkelen) een kennispaneel met de stappen, termijnen en regels. Bij elk antwoord zichtbaar uit welk blok en welke versie het komt. En een voorbeeld-vragenreeks waarin ook een vraag buiten de kennisbasis zit, zodat jullie live zien hoe de bot die weigert en terugverwijst, precies zoals Appel dat deed met de vraag buiten de biologiestof.
Ik bouw dit uitsluitend op de methodiek-informatie uit jouw mail en op wat Hamza aanlevert. Geen kandidaat- of klantgegevens, conform jullie harde grens. En het is een referentie, geen afhankelijkheid: Hamza ziet de structuur, bouwt hem na op jullie eigen server, en jullie versie is vanaf dat moment de echte. Jullie krijgen een klikbare link zodra hij staat.
Van jullie kant heb ik drie dingen nodig. Hamza stuurt de Proceshuis-hoofdstukken Plaatsen en Ontwikkelen plus de vijftien kernregels en de lijst met CAO- en subsidieregels, alleen methodiek. Hamza zet ook de testmailbox met fictieve gegevens klaar. En jullie prikken het vaste wekelijkse moment voor de coaching-vraag.
Van mijn kant: binnen een week na ontvangst van het materiaal lever ik de demo-kennisbot op, samen met het format voor de testset (de veertig vragen plus tien strikvragen) dat Hamza daarna zelf onderhoudt.
Daarmee staat na week één het fundament, en heeft Hamza een werkend voorbeeld om na te bouwen in plaats van een stapel adviezen om te interpreteren.
Groet,
Jamal
Werkend voorbeeld: https://goed.haartips.nl/greenfox-kennisbot-demo.html
🎙️ Bespreek met Jarvis