Beste Renzo,
Dank voor de heldere opdracht. Ik heb je mail gecombineerd met wat Hamza en Marcella de afgelopen weken hebben verteld, en daar ook onderzoek bij gedaan naar wie dit soort dingen al bewezen heeft laten werken. Dat geeft samen een scherper en steviger onderbouwd advies dan één gesprek of alleen mijn eigen inschatting.
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.
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.
Voordat ik met advies kom, eerlijk antwoord op de vraag die je vast zelf ook had: bestaat dit al ergens? Ik heb dat uitgezocht, kritisch, niet alleen leveranciers-marketing overgenomen.
Het complete concept dat jullie voor ogen hebben — kennisbot, ochtendbriefing, conceptmails in eigen stijl én contractbewaking, allemaal per medewerker persoonlijk — bestaat als geheel nergens gedocumenteerd. Daarin lopen jullie voorop. Maar elk onderdeel apart is wel degelijk al bewezen, bij serieuze namen:
Twee onderdelen zijn nergens terug te vinden: een dagelijkse ochtendbriefing per medewerker, en subsidie-tracking als AI-feature. Dat is dus geen gekopieerd recept maar eigen terrein — precies waar de meeste winst zit, en ook waar je zelf het voorzichtigst moet beginnen omdat er geen blauwdruk is.
Volledig onderzoek met alle bronlinks: https://verslag.haartips.nl/r-greenfox-succesverhalen-fable.html
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.
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. 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 — precies het patroon dat bij Malt/Dust en bij Moderna werkt. 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.
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 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.
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. 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 het is dezelfde reden waarom IBM's AskHR 94 procent van de vragen zonder mens kan oplossen: strikte grenzen aan wat de bot wel en niet zegt.
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. Deze testset is meteen jullie kwaliteitsdocumentatie richting AVG en audits.
Twee lagen, zoals je zelf al stelde. De GreenFox-laag is voor iedereen gelijk: huisstijl, toon, de schrijfregels. De persoonlijke laag is één profielbestand per medewerker met rol, processen, systemen, ervaringsniveau en schrijfstijl.
Die schrijfstijl bouw je niet met een beschrijving maar met voorbeelden. Laat de medewerker tien tot twintig eigen, goedgekeurde verstuurde mails aanleveren, 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.
Eén waarschuwing, 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. 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. Doe je dit niet expliciet, dan verlies je het draagvlak voordat de techniek de kans krijgt — Randstads eigen aanpak (medewerkers bouwen zelf hun assistenten) laat zien dat eigenaarschap juist de sleutel tot adoptie is.
De snelste route naar jullie succescriterium 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.
Dan de kennisvragen-functie met citaatplicht als eerste zichtbare feature. Dit bouwt vertrouwen.
Daarna de ochtendbriefing. Dit is de gewoontevormer: één vast moment per dag. Bouw en test dit eerst volledig op nepdata; ik heb Hamza al gevraagd om een testmailbox en fictieve gegevens.
Dan pas conceptmails in eigen stijl en daarna de contract- en subsidiebewaking, omdat die koppelingen vraagt en dus de meeste bouwtijd kost. Alles blijft concept tot een mens het goedkeurt.
De tweede gebruiker start pas als de eerste het succescriterium haalt. Dan hergebruik je de complete motor en maak je alleen een nieuw profiel.
Fase 2, het realtime meeluisteren via Plaud, blijft geparkeerd tot fase 1 bewezen is. Ideeën die onderweg opkomen gaan naar het whiteboard, niet in de bouw.
Praten over citaatplicht is één ding, het zien werken is iets anders. Ik heb daarom alvast een demo-kennisbot gebouwd in de stijl van Appel, met fictieve voorbeeldstof uit de vier hoofdprocessen, inclusief een voorbeeld-vragenreeks die laat zien hoe de bot een terechte vraag met bron beantwoordt, én hoe hij netjes weigert bij een vraag over kandidaatgegevens:
https://goed.haartips.nl/greenfox-kennisbot-demo.html
Dit is een illustratie, geen kant-en-klaar product — Hamza ziet de structuur en bouwt hem na op jullie eigen server met echte data, en jullie versie is vanaf dat moment de echte.
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 met echte structuur op, samen met het format voor de testset dat Hamza daarna zelf onderhoudt.
Groet,
Jamal