Je hebt nu drie kandidaten op je lijst staan. Een agent die tickets sorteert voordat ze escaleren. Een agent die het gat tussen oplevering en factuur dichtrijdt. En een agent die één keer denken laat uitgroeien tot tien keer publiceren. Alle drie zijn beschreven, alle drie zijn eerlijk begrensd op L2, en alle drie beloven geen autonome magie. De vraag die nog openstaat, is niet welke van de drie het beste werkt. Het is met welke je begint, en waarom je de andere twee laat wachten.
Dat is geen technische vraag. Het is een vraag over je organisatie. Wie in je team moet het eerst met een agent leren werken? Welke data-governance heb je al op orde, en welke nog niet? En welk domein levert de minste schade op als de eerste versie tegenvalt? Dat maakt dit een relatievraagstuk, niet alleen een architectuurvraagstuk. De volgorde waarin je agentic werk invoert, bepaalt hoeveel vertrouwen je team eraan overhoudt voor de tweede en de derde agent aan de beurt zijn.
Waarom niet alle drie tegelijk
De verleiding is reëel. Je hebt drie duidelijk beprijsde problemen, drie workflows die klaarliggen, en een board dat snelheid wil zien. Toch is gelijktijdig starten de duurste route, om drie redenen die los van elkaar al genoeg zijn.
De eerste reden is aandacht. Elke agent vraagt in de eerste weken een eigenaar die dagelijks meekijkt. Iemand die de conceptfacturen controleert. Iemand die de routering van tickets naast de werkelijkheid legt. Iemand die de stemtest op gepubliceerde content draait. Diezelfde mensen zitten vaak in hetzelfde kleine team. Drie tegelijk starten betekent drie halve reviews in plaats van één volledige, en een halve review levert geen betrouwbare nulmeting op.
De tweede reden is diagnose. Als je drie agents tegelijk aanzet en er iets misgaat, weet je niet welke. Loopt de facturatie vertraagd omdat de agent een BTW-uitzondering mist, of omdat de supportagent tegelijk een streep haalt door dezelfde klantdata? Je hebt geen controlegroep meer. Eén voor één invoeren geeft je een schoon signaal per workflow, en dat signaal heb je nodig om te weten of het probleem in het proces zit of in de agent.
De derde reden is vertrouwen, en die weegt het zwaarst. Elke agent die informatie over medewerkers verwerkt, zoals een override-ratio of een gespreksopname, raakt iets dat van die medewerker is. Introduceer je dat haastig en gestapeld, dan voelt het als toezicht in plaats van als hulpmiddel, en dat wantrouwen slaat terug op de volgende agent, ook als die zorgvuldiger is ingericht. Een eerste agent die goed landt, maakt de tweede makkelijker. Een eerste agent die overhaast aanvoelt, maakt de tweede onmogelijk te verkopen aan je eigen team.
De volgorde die wij aanhouden, en waarom
Onze inschatting, geen gemeten norm: begin met de workflow die het minste persoonsgegeven verwerkt en het kleinste blast radius heeft als iets misgaat. Dat is content-hergebruik. Je voert daar één bron in die je zelf kiest, geen database vol klantgegevens. Een misser in de output is een zwak stuk tekst, geen verkeerd bedrag op een factuur en geen verkeerd geroute klacht. Deze workflow leert je team bovendien de kernvaardigheid die de andere twee ook nodig hebben: bronnen daadwerkelijk vastleggen in plaats van laten verdampen in iemands hoofd. Zonder die discipline werkt geen van de drie agents, dus het is logisch om die discipline op te bouwen waar de inzet het laagst is.
Daarna volgt facturatie en debiteuren. De data is gevoeliger, financieel en soms persoonsgebonden, maar het proces is voorspelbaarder dan support: een factuurstroom heeft een vaste structuur, vaste regels en een vaste klok. Je hebt bovendien inmiddels, uit de eerste workflow, geleerd hoe review, correctie en escalatie in de praktijk voelen voor je team. Die ervaring maakt het makkelijker om vooraf de juiste drempels te zetten: wanneer een conceptfactuur automatisch klaar mag staan, en wanneer een mens moet tekenen voor er iets de deur uitgaat.
Pas als die twee draaien, is support-triage aan de beurt. Dit is de zwaarste van de drie, want hij raakt klantpersoonsgegevens direct, vaak in combinatie met betaalcontext, en hij raakt het werk van je eerstelijns- en tweedelijnsmedewerkers rechtstreeks. Je hebt op dit punt al twee keer laten zien, aan je team en aan jezelf, dat een agent een dossier aanlevert in plaats van een oordeel oplegt. Dat bewijs heb je nodig voordat je een workflow invoert die zichtbaar meet hoe vaak een medewerker het concept van de agent overschrijft.
Deze volgorde is een vuistregel, geen wet. Ligt bij jou het grootste, meetbare geldlek in de factuurstroom en heb je daar al een schone brondata, dan kan het verdedigbaar zijn om met facturatie te beginnen. De regel die wel altijd geldt: kies er één, meet die volledig uit, en pas dan pas op de volgende.
De randvoorwaarde die voor alle drie geldt
Voordat je met een van de drie begint, geldt één gedeelde regel. Die staat hier bewust vóór de doorverwijzingen naar de losse pagina’s. Elke workflow die bedrijfsdata verwerkt draagt datzelfde databehandelingsfundament, ongeacht welke je als eerste kiest.
Je hebt een verwerkersovereenkomst met je modelleverancier voordat er echte data wordt geplakt, ook geanonimiseerde. Je werkt in een zakelijk abonnement, nooit in een consumentenaccount. Je weet in welke regio de verwerking plaatsvindt en kunt dat aantonen. Je vervangt namen door rollen: Klant A, Medewerker 1, niet de echte naam, in elke test en in elke conceptversie. Je legt een bewaartermijn schriftelijk vast per gegevenssoort, en je wijst vooraf een naam aan die het escalatiepad tekent als er iets misgaat.
Eén punt verdient een aparte zin, omdat het bij alle drie de workflows terugkomt. Zodra een agent observeert wat een medewerker doet, is die data eigendom van die medewerker. Dat geldt voor een override op een conceptfactuur, een correctie op een ticketclassificatie, en een stemcorrectie op gepubliceerde tekst. Ze dient om zijn werklast te verlagen en de agent bij te sturen, nooit om hem te beoordelen. Wil je die data ooit voor een ander doel gebruiken, dan is dat een aparte beslissing, en bij Femke’s DMU heeft de ondernemingsraad daar vooraf een veto op. Zeg dat tegen je team voordat de eerste agent draait, niet nadat iemand het zelf ontdekt.
Deze randvoorwaarde staat niet ter discussie per workflow. Ze geldt voor de eerste die je kiest, en voor de twee die volgen.
Wat je nu concreet doet
Kies een van de drie workflows op basis van waar jouw data het lichtst is en waar de schade bij een misser het kleinst blijft. Begint jouw team voor het eerst met agentic werk, lees dan eerst hoe content-hergebruik een eenmalige, zelfgekozen bron omzet in meerdere publicaties. Die pagina leert je de vastlegdiscipline die de andere twee workflows daarna nodig hebben. Ligt je grootste, aantoonbare lek in de tijd tussen oplevering en factuur, ga dan direct door naar facturatie en debiteuren. Daar zet de agent conceptfacturen en afletterrapporten klaar, onder een handtekening van een mens. En zit de meeste frictie in de overdracht tussen je eerste en tweede lijn, kijk dan naar support-triage. Die agent komt binnen met een dossier in plaats van een kale melding, maar brengt wel de zwaarste governance-eis van de drie mee.
Twijfel je nog waar je eigen proces staat, dan is RENEW je eerdere stap. Een agent draait alleen op een proces dat al is vastgelegd. En het bredere kader waarom ik consequent op L2 blijf zitten en geen autonome magie verkoop, staat in de pillar over agentic werken.
Ik wil met jou bepalen welke van de drie workflows bij jouw organisatie als eerste aan de beurt is, op basis van je eigen datagevoeligheid en je eigen teamcapaciteit. Plan dat gesprek in, en ik lever je na afloop een geprioriteerde volgorde voor je eigen drie kandidaten, met de reden per stap.