Wat we meenemen uit het gesprek met Hamza (4 juli)
Drie dingen bepalen dit hele advies, en die staan niet letterlijk in de mail, maar wel duidelijk in het gesprek:
Het echte probleem is éénpersoonsafhankelijkheid, niet gemak. Hamza zei het zelf: "een heel groot deel van het allerbelangrijkste kernproces hangt aan één persoon... als mijn vliegtuig neerstort, heb je een probleem." Dit project bestaat dus om kennis uit één hoofd te halen en in een systeem te zetten — niet om leuk met AI te spelen.
Verandermanagement is de bottleneck, niet techniek. Mensen voelen zich gecontroleerd zodra ze worden aangesproken, ook met de beste intentie. Junior intercedenten met zelfoverschatting nemen correctie slecht aan. Elke technische keuze hieronder is daarom mede gekozen om weerstand te voorkomen, niet alleen om functioneel te zijn.
Jullie zijn al zorgvuldig met risico. De harde datagrens, "alles blijft concept" en de governance bij Hamza alleen: dat is goed doordacht en dat advies bouwt daarop voort, niet eromheen.
a. De beste technische opzet
Bouw op wat er al staat: Microsoft. Jullie draaien al volledig op Microsoft 365 met Intune-beheerde laptops en Fairphones. Dat is niet zomaar een detail — het is de sterkste technische keuze die je al gemaakt hebt, nog voordat er één regel bot-code geschreven is.
Concreet:
Bouw de bot op Microsoft Copilot Studio + Azure OpenAI Service, binnen jullie eigen tenant, in plaats van een losstaande custom-bouw met een externe aanbieder. Dit heeft drie voordelen tegelijk:
1. Compliance is opgelost, niet beloofd. Azure heeft EU-datacenters en jullie hebben als Microsoft-klant al een verwerkersovereenkomst. Daarmee is "dataopslag binnen de EU, AVG geldt onverkort" een configuratie-instelling, geen los legal-traject.
2. Geen nieuwe app, geen nieuw beheer. De bot leeft in Teams en op de telefoon via de Microsoft-app die er al staat. Voor gebruikers is het gewoon "een collega in Teams", niet weer een nieuw account met nieuw wachtwoord.
3. Toegang volgt al bestaand beleid. Intune bepaalt al wie wat mag op welk device — die rechten kun je hergebruiken voor de bot in plaats van een apart rechtensysteem te bouwen.
Eén centrale motor, veel dunne profielen. Bouw niet per medewerker een aparte bot. Eén Copilot-agent, met per medewerker een eigen instructieset (rol, stijl, huidige taken) die bovenop een gedeelde kennisbasis zit.
Sla alle prompts, profielen en kennisbestanden op in een repository (Azure DevOps of GitHub, wat jullie al gebruiken) — niet los in de tool zelf. Elke wijziging is dan terug te draaien en te herleiden. Dat is ook jullie eigen eis (guardrail 4): kennis blijft van GreenFox, niet van de coach.
Guardrails technisch afdwingen, niet alleen afspreken:
Geen verzendrechten voor de bot. Geen koppeling naar buiten. Output landt in een concept-map of concept-mail in Outlook, een mens verstuurt.
Geen live koppeling naar Carerix/Easyflex in fase 1. Overzichten komen als export aan.
Alle bot-acties gelogd, alleen Hamza met adminrechten. Andere wensen gaan naar het whiteboard.
b. Het Proceshuis als betrouwbare kennisbasis
Kernprincipe: kleine bouwstenen, citaatplicht, en een harde toets voordat je vertrouwt.
Knip het Proceshuis op in losse bestanden per deelonderwerp, in vier mappen die de vier hoofdprocessen volgen: Sales, Werven en Selecteren, Ontwikkelen, Plaatsen. Eén bestand per vraag die een medewerker écht stelt (bijvoorbeeld "fase A zonder beding", "Doorzaam-budget", "offboarding-types"). Elk bestand krijgt een kop met eigenaar en laatst-gecheckt-datum, want verouderde kennis is het grootste sluipende risico.
De 15 kernregels staan hard in de instructies van de bot zelf, niet alleen ergens in een document. Regels als "nooit vrijwaring tekenen" of "geen onboarding zonder kredietcheck" mogen nooit afhangen van of de zoekfunctie het juiste stukje toevallig vindt.
Citaatplicht: de bot antwoordt alleen met een verwijzing naar het bronbestand. Vindt hij niets, dan is het verplichte antwoord: "Dit staat niet in het Proceshuis, check bij [proceseigenaar]." Dat is de "zegt wat hij niet weet"-eis die jullie zelf noemen, hard in de instructie in plaats van een hoop.
Bouw een testset vóórdat je vertrouwt. Laat de eerste gebruiker samen met een ervaren collega 30 vragen opschrijven: 20 met het juiste antwoord én bronverwijzing, en 10 strikvragen waarvan het antwoord bewust niet in het Proceshuis staat. De bot is pas klaar voor gebruik als hij de 20 goed beantwoordt mét bron, en bij alle 10 eerlijk toegeeft het niet te weten. Herhaal deze toets na elke grote wijziging aan de kennisbasis.
Kerngetallen krijgen een eigen bestand (omrekenfactor 2,53, het Doorzaam-budget van 2.500 euro, de 6-wekentermijn, de dag 3-10-17-cyclus) en worden apart getest. Dit zijn de fouten die het vertrouwen in één klap kapotmaken.
c. Een persoonlijk profiel per medewerker
Kernprincipe: de medewerker bouwt zijn eigen profiel mee — dat is meteen jullie verandermanagement.
Uit het gesprek: mensen gaan in de weerstand zodra iets voelt als controle. Draai het daarom om: het profiel is van de medewerker, niet over de medewerker.
Twee lagen per profiel, precies zoals jullie eigen eis (guardrail 5): een GreenFox-laag (voor iedereen gelijk, leidend — schrijfstijl zonder streepjes, dikgedrukt of emoji's, servicebeloften, altijd terugkoppelen) en een persoonlijke laag (rol, dagritme, wat de bot juist NIET moet doen).
Vul het profiel via één gesprek van een uur. Hamza vraagt: wat doe je op een normale dag, wat kost je de meeste tijd, welke mails schrijf je het vaakst. Laat de medewerker daarnaast 5 tot 10 eigen mails aanleveren als stijlvoorbeeld — dat is de snelste weg naar "herkenbaar persoonlijk, geen AI-mail".
De medewerker keurt zijn eigen profiel goed, en mag het via Hamza altijd laten aanpassen. Eigenaarschap is het verschil tussen "mijn assistent" en "hun controlesysteem".
Harde, opgeschreven afspraak: de bot rapporteert nooit per persoon aan leidinggevenden. Geen individuele gebruiksstatistieken naar management in fase 1. Dit is precies het punt dat de angst uit het gesprek ("ze voelen zich gecontroleerd") wegneemt — en het moet expliciet worden benoemd, niet stilzwijgend worden aangenomen.
d. De volgorde die het snelst bewezen waarde oplevert
Voor gebruiker 1 (administratief-operationeel profiel):
Week 1-2 — kennisbot. Alleen vraag-en-antwoord op het Proceshuis, met citaatplicht, getoetst met de 30-vragen-set. Geen koppelingen, geen risico. Dit is de fundering.
Week 2-3 — ochtendbriefing. Een kort dagelijks overzicht van openstaande acties, in het begin op basis van een handmatige lijst of export. Dit is elke dag zichtbaar, raakt geen gevoelige data, en is de snelste route naar "ik gebruik hem uit mezelf".
Week 3-4 — conceptmails in eigen stijl, startend met de drie meest voorkomende mailsoorten uit het profielgesprek. Medewerker beoordeelt elk concept, Hamza stelt de instructies bij op basis daarvan.
Week 4-6 — overzicht contracten en subsidieaanvragen, als laatste omdat dit het foutgevoeligst is (termijnen, fase A-regel, 6-wekentermijn). Begin met een wekelijkse export die de bot omzet naar een signaallijst, geen live koppeling.
Daarna gebruiker 2 (commercieel-relationeel): hergebruik de hele opzet, alleen een nieuw profiel en een nieuw startgesprek. Kost dat meer dan een dag of twee, dan is de architectuur nog niet goed genoeg — en dat wil je nu weten, niet bij medewerker twaalf.
Meet vanaf dag één het succescriterium dat jullie zelf noemen: gebruikt de medewerker de bot na twee weken uit zichzelf, en kan hij concrete tijdwinst in uren per week benoemen.
Bewust nog niet doen: fase 2 (meeluisteren via Plaud) pas starten zodra beide eerste gebruikers fase 1 aantoonbaar dagelijks gebruiken. Meeluisteren raakt direct kandidaatdata én het gevoel van gecontroleerd worden — dat vertrouwen verdien je eerst met een bot die simpelweg elke dag handig is.
Concrete eerste vervolgstap (deze week)
Hamza zet de fundering neer, nog vóór er één regel bot-logica staat:
Zet een Copilot Studio-agent op binnen de bestaande Microsoft-tenant (geen nieuwe externe tool, geen aparte compliance-discussie).
Zet de hoofdstukken Plaatsen en Ontwikkelen om naar losse kennisbestanden volgens het recept hierboven, in de repository die jullie al gebruiken.
Laat de eerste gebruiker samen met een ervaren collega de 30-vragen-testset maken (20 met antwoord + bron, 10 bewust onbeantwoordbaar).
Leg volgende week de mappenstructuur plus testset aan mij voor. Dan geef ik het exacte instructie-recept voor de kennisbot met citaatplicht, zodat jullie er direct bovenop kunnen bouwen.