Een agent voor jullie eigen proces?
Kies een afgebakende taak en werk toe naar een agent met heldere bronnen, rechten en controle.
Dennis Claassen
AI-trainer · 35+ teams getraind
Key takeaways
- Een AI-agent telt niet. Hij legt het telresultaat naast je systeemcijfer en zegt welk verschil onderzoek verdient. Lopen, scannen en fysiek controleren blijft mensenwerk.
- De grootste valkuil is een verschil meteen corrigeren zonder de oorzaak te zoeken. Een verplaatsing die nog niet in het systeem staat, lijkt dan op diefstal. De echte fout, een vergeten boeking, komt volgende telling gewoon terug.
- De drempel is een percentage van de telde hoeveelheid, geen rond getal. 1 tot 5% bij hoogwaardige producten, 5 tot 10% bij lage waarde. Daarboven altijd onderzoek voor je het cijfer aanpast.
- Reken op een paar minuten triage per telronde, tegenover een uur handmatig uitzoeken. Het aandeel verschillen dat na onderzoek een echte fout blijkt, ligt meestal rond een kwart tot een derde.
- Doe dit deze week: laat de agent één telronde naast je systeem leggen, zet een drempel per productwaarde, en leg vast wie een verschil boven die drempel mag goedkeuren.
Je hebt net een stelling nageteld en het klopt niet met het systeem. Nu begint het echte werk: is dit ruis, een vergeten boeking, of verdwenen voorraad? Een AI-agent kan die vraag niet beantwoorden door zelf te gaan tellen, maar wel door elk verschil naast je systeemdata te leggen en te zeggen welke een kwartiertje onderzoek verdienen. Shopify legt in zijn uitleg over cyclisch tellen uit dat een telverschil pas na onderzoek wordt aangepast: "Variances above the threshold require investigation before the system record is adjusted, while variances below the threshold may be corrected automatically." Precies die drempel ontbreekt in de meeste magazijnen, en zonder drempel corrigeer je alles even snel, groot of klein. Voorraadbeheer met AI gaat over besteladvies op basis van verkoopdata; dit artikel gaat over de telronde zelf, de stap die daarvoor komt.
Wat een AI-agent bij voorraadtelling wel en niet is
Een agent is AI die zelf stappen zet, niet alleen antwoord geeft. Bij voorraadtelling haalt hij je systeemcijfer en telresultaat op, berekent per product het verschil in aantal en waarde, en rangschikt dat van groot naar klein. Daarna zoekt hij in je eigen data naar een mogelijke verklaring: een open verplaatsing, een net verwerkte ontvangst, een retour die nog niet geboekt is. Het resultaat: klein genoeg om te corrigeren, of groot genoeg om eerst uit te zoeken.
Het verschil met een teller die alles zelf narekent, zit in het volume. Eén teller overziet een paar honderd regels per dag; een agent legt duizenden regels naast elkaar in een paar minuten. Juist die snelheid is het risico: ze verleidt tot het overslaan van de vraag "waarom wijkt dit af", en dan wordt corrigeren een gewoonte, geen beslissing. Daarom krijgt de agent hieronder een harde grens: rangschikken en een oorzaak voorstellen mag, het systeemcijfer zelf aanpassen nooit.
Welke taak geef je als eerste aan een agent?
Begin bij één taak, niet bij drie tegelijk.
Telverschillen rangschikken op impact. De agent zet elk verschil in euro's en in stuks naast elkaar, in plaats van dat jij een lijst op SKU-nummer doorwerkt. Dat werkt omdat impact en volgorde los van elkaar staan: 2 stuks bij een product van 4 euro verdient minder aandacht dan 2 stuks bij een product van 400 euro, maar ze staan vaak toevallig naast elkaar. Verwacht dat je triagetijd van een uur naar een kwartier gaat. Niet doen onder vijftig regels: dan overzie je de impact zelf sneller dan je de agent kunt instrueren.
Een waarschijnlijke oorzaak voorstellen. De agent zoekt in je systeem naar activiteit rond het product in de telperiode: een openstaande verplaatsing, een ontvangst, een retour, een lopende actie. Die vier verklaren samen het grootste deel van gewone verschillen, en een agent checkt in seconden of een van de vier van toepassing is, waar een mens eerst door drie systemen moet klikken. Verwacht een voorstel bij zes tot acht van de tien verschillen; bij de rest blijft het puur onderzoek. Niet doen zonder toegang tot je ontvangst-, verplaatsings- en retourlog: zonder die data gokt de agent net zo goed als jij.
Telfrequentie per productgroep voorstellen. In plaats van alles even vaak tellen, deelt de agent je assortiment in op waarde en omloopsnelheid, en stelt een telschema voor. Dat werkt omdat Shopify in dezelfde uitleg de ABC-indeling beschrijft: A-producten (ruwweg 80% van de omzet, 20% van de voorraad) maandelijks, B-producten per kwartaal, C-producten (ruwweg 5% van de omzet, 70% van de voorraad) een of twee keer per jaar. Verwacht dat je telcapaciteit verschuift naar de producten waar een fout het meest kost. Niet doen zonder een paar maanden verkoophistorie: zonder die historie klopt de indeling zelf niet, en tel je op een verkeerd schema.
Kies de taak die jou nu het meeste tijd kost.
Voorraadtelling met AI: prompt, workflow of agent?
Neem het lichtste gereedschap dat de klus betrouwbaar klaart. De drempels volgen uit wat handmatig vergelijken kost, tegenover wat een vaste koppeling kost om te bouwen en te onderhouden.
| Als dit geldt | Dan bouw je dit | Waarom de drempel daar ligt |
|---|---|---|
| Eén telronde per kwartaal, minder dan 100 regels | Een prompt: plak je telresultaat en systeemcijfers, vraag om een gerangschikte verschillenlijst | Honderd regels handmatig vergelijken kost twintig tot dertig minuten. Een koppeling bouwen kost al snel een dag, dat verdien je op dit volume niet terug |
| Wekelijks of maandelijks cyclisch tellen, 100 tot 1.000 regels | Een workflow: vaste export, één AI-stap voor rangschikking en oorzaakvoorstel, een lijst die jij goedkeurt | Handmatig kost 500 regels per maand al snel een paar uur. Een workflow bouw je eenmalig en voorkomt dat iemand per ongeluk een regel overslaat |
| Dagelijks tellen, meerdere locaties, meer dan 1.000 regels per week | Een agent met een directe koppeling aan je voorraadsysteem en logistieke logs, op een vast moment per dag | Bij dit volume is handmatig vergelijken niet haalbaar binnen een werkdag, en een losse export is sneller achterhaald dan je hem bijwerkt |
| Het verschil ligt boven je waardedrempel (zie de tabel hieronder) | Altijd een mens die onderzoekt voordat het systeemcijfer wordt aangepast | Een boeking die de oorzaak overslaat, keert bij de volgende telling terug, met herhaald geld of een vertekend bestelcijfer als gevolg |
| Er is een aanwijzing voor diefstal, fraude of een structurele procesfout | Altijd een mens die het onderzoekt, nooit alleen een boeking | Een agent mag een patroon signaleren, geen conclusie trekken over het gedrag van een medewerker of leverancier |
Begin op het niveau dat bij je telfrequentie en volume past. Laat de agent nooit zelf het systeemcijfer aanpassen boven je eigen drempel.
Een verplaatsing die op diefstal lijkt
Dit voorbeeld is een eigen constructie: een telrapportage met échte SKU's en een verdenking van diefstal publiceert geen bedrijf, dat raakt direct aan het vertrouwen van een medewerker. Het is gebouwd op een patroon dat bij cyclisch tellen wel gedocumenteerd is: Shopify noemt "when inventory moves between locations" zelf als trigger voor een telcontrole, en adviseert om "recent activity tied to the product, such as receiving, transfers, returns, or sales" te documenteren voor je een verschil aanpast. De cijfers zijn verzonnen, het patroon niet.
De situatie. Een bouwmarkt telt locatie A, het magazijn, en vindt 18 stuks minder dan het systeem van een scharnierset die 14 euro per stuk kost. Twee dagen eerder ging een pallet met 20 stuks van die scharnierset naar locatie B, de winkelvloer. De magazijnmedewerker heeft die verplaatsing in het systeem nog niet afgerond.
De prompt aan de agent:
Vergelijk het telresultaat van locatie A met het systeemcijfer voor
elk product. Zet verschillen van meer dan 5% van de telde hoeveelheid
boven aan de lijst. Zoek voor elk verschil in de verplaatsings-,
ontvangst- en retourlog van de laatste 7 dagen naar een mogelijke
verklaring en noem die, zonder een conclusie te trekken over de oorzaak.
Wat de agent zonder correctie teruggeeft:
| Product | Systeemcijfer | Telresultaat | Verschil | Waarde |
|---|---|---|---|---|
| Scharnierset SH-220 | 54 | 36 | -18 (33%) | 252 euro |
De agent markeert dit terecht als groot: 33% ligt ver boven elke redelijke drempel, en 252 euro is de moeite van onderzoek waard. Het probleem zit in de laag erna: zonder de instructie om eerst de verplaatsingslog te checken, trekt een kortere versie van dezelfde prompt al snel een conclusie: "waarschijnlijk diefstal of administratieve fout op locatie A". Geloofwaardig voor de lezer, onterecht voor de medewerker van locatie A.
Wat je repareert voordat je iets aanpast. De instructie "zoek naar een mogelijke verklaring, zonder een conclusie te trekken over de oorzaak" voorkomt dat de agent een schuldige aanwijst. Met die regel vindt de agent de openstaande verplaatsing en meldt: "18 van de 20 verplaatste stuks verklaren het verschil op locatie A; controleer of de resterende 2 stuks ook op locatie B staan voor je dit afrondt." Dat scheelt een onterechte beschuldiging, en wijst naar het echte probleem: een verplaatsing die niet op tijd is afgerond. Dat los je op met een procesregel, niet met een boeking.
De rekensom achter je drempel
De drempel waarboven een verschil onderzoek verdient, is geen gevoel. Shopify geeft de formule voor inventory record accuracy (IRA), de maatstaf voor hoe goed je systeem bij de werkelijkheid past:
IRA = 1 − (som van de verschillen ÷ som van de totale voorraad) × 100
Shopify's eigen voorbeeld: toont je systeem 150 stuks en tel je er 148, dan is je IRA 98,7%. Bij meerdere producten tel je eerst alle verschillen en de totale voorraad op, en vul je dan pas de formule in. Zo verdwijnt één grote uitschieter niet onopgemerkt in een gemiddelde.
Voor de drempel per product beschrijft Doss, een leverancier van voorraadsoftware, de gangbare praktijk: "Common thresholds range from 1-5% for high-value items to 5-10% for lower-value goods. Variances above the threshold require investigation before the system record is adjusted, while variances below the threshold may be corrected automatically." Vertaald naar een vuistregel die je vandaag kunt toepassen:
| Productwaarde | Drempel (% van de telde hoeveelheid) | Wat erboven gebeurt |
|---|---|---|
| Hoogwaardig (bijvoorbeeld boven 50 euro per stuk, of A-classificatie) | 1 tot 5% | Altijd onderzoek: check verplaatsing, ontvangst en retourlog voor je het cijfer aanpast |
| Middelmatig (B-classificatie) | Rond 5% | Onderzoek bij een eerste keer; bij een herhaald, verklaard patroon mag je sneller corrigeren |
| Lage waarde (C-classificatie, bijvoorbeeld onder 10 euro per stuk) | 5 tot 10% | Onder de drempel mag een agent de correctie voorstellen; jij zet alleen nog een handtekening eronder |
De drempel ligt lager bij hoogwaardige producten omdat de schade van een gemiste fout daar sneller oploopt: 5% op een product van 2 euro is 10 cent, 5% op een product van 200 euro is 10 euro, bij dezelfde moeite om het uit te zoeken. Pas de percentages aan op je eigen marges. De verhouding (lager bij hoge waarde, hoger bij lage waarde) is het deel dat overal werkt.
Die indeling is geen eenmalige instelling. Een product dat C was en door een prijsverhoging of trend bij de A-groep hoort, telt nog op het oude, te lage schema tot iemand de indeling herziet. Laat de agent daarom het assortiment elk kwartaal opnieuw tegen de omzet- en waardecijfers aanhouden, en elke verschuiving tussen de groepen apart melden. Mis je die stap, dan loopt precies je nieuwste, duurste product op het schema van een product dat nauwelijks meetelt.
De grens: waarom dit vandaag zelfbouw is, geen kant-en-klaar product
Microsoft noemt op zijn productpagina voor Dynamics 365 Supply Chain Management voorlopig geen eigen, losse voorraadtelling-agent: de AI-laag helpt daar met "automated inventory placement" via Copilot, en de Procurement Agent richt zich op leveranciersberichten en staat nog in preview. Dat betekent niet "dit kan nog niet", maar dat je de taken uit de tabel hierboven vandaag zelf bouwt, in plaats van te wachten op een kant-en-klare leveranciersoplossing.
De scheiding tussen signaleren en beslissen is geen eigen voorkeur. Anthropic richt de permissies van zijn Claude-agents op dezelfde manier in: de documentatie over agent-permissies staat een leesverzoek standaard toe, maar een schrijfactie gaat alleen door in een bewust ingeschakelde modus, en nooit voor een actie buiten de afgesproken grens. Telverschillen lezen en rangschikken is een leesactie; een boeking aanpassen is een schrijfactie, en blijft daarom een bewuste, aparte stap.
Waar voorraadtelling met AI misgaat: corrigeren zonder oorzaak
Je zag het hierboven al: een agent, of een gehaaste collega, boekt een verschil weg zonder de verplaatsings-, ontvangst- of retourlog te checken. Zodra het cijfer weer klopt, voelt het probleem opgelost, en niemand zoekt verder. Doss noemt dat precies het probleem met corrigeren zonder root-cause-proces: je herstelt losse fouten "without addressing the underlying process failures that create them". Bij een verplaatsing die structureel te laat wordt afgerond, zie je dat terug als een terugkerend tekort op de ene locatie en een overschot op de andere, telronde na telronde, tot iemand vraagt waarom het steeds dezelfde twee locaties zijn.
De tegenhanger is net zo kostbaar: een verschil onder de drempel negeren zonder het te loggen, omdat het toch automatisch gecorrigeerd wordt. Een reeks kleine, telkens net-onder-de-drempel verschillen bij dezelfde SKU is op zichzelf een signaal. Laat de agent daarom ook een lopende teller per product bijhouden: drie keer op rij hetzelfde patroon, ook onder de drempel, verdient alsnog een check.
Voorraadtelling met AI en privacy: wat de agent wel en niet mag zien
Een telrapportage koppelt soms een verschil aan een shift of een naam, zeker als je bijhoudt wie welke locatie telde. Dat is een persoonsgegeven zodra het herleidbaar is tot een medewerker, en valt onder de AVG. Laat de agent rekenen op productniveau, niet op medewerkerniveau: een patroon dat op een persoon wijst, beoordeel je zelf, niet via een ongefilterde AI-samenvatting naar een leidinggevende.
Gebruik een zakelijk account met een verwerkersovereenkomst, en zet modeltraining uit. Nooit zelf: inkoopprijzen uit je telrapportage laten vergelijken met die van een concurrent binnen dezelfde AI-sessie. Dat raakt aan mededingingsrecht, niet alleen aan privacy.
Wat het oplevert, en hoe je het na zeven dagen meet
Wat na een paar telrondes beter wordt: de onderzoekslijst wordt korter, omdat terugkerende oorzaken opgelost zijn in het proces zelf, niet alleen in het cijfer. Wat niet beter wordt vanzelf: een nieuw product zonder historie, en een verschil waarbij geen van de vier standaardverklaringen klopt.
Uit onze eigen Agent Sprint-trajecten zien we dat ongeveer een kwart tot een derde van de gevlagde verschillen na onderzoek een echte fout blijkt. De rest verklaart zich zodra iemand de log erbij pakt. Dat is trainingservaring, geen onafhankelijk gemeten percentage.
Meet drie dingen, zeven dagen op een rij, zonder extra tooling:
- Hoeveel verschillen stonden er op de onderzoekslijst, voor en na een telronde? Een dalende lijn betekent dat je procesfixen werken. Blijft hij gelijk, dan los je steeds hetzelfde probleem opnieuw op, in plaats van de oorzaak.
- Hoeveel keer werd een verschil boven je drempel toch gecorrigeerd zonder onderzoek? Dit hoort op nul te staan. Eén uitzondering is het moment om de afspraak opnieuw door te nemen.
- Hoe lang duurde de triageronde, geklokt op dag 1 en dag 7? Geen merkbaar verschil betekent dat de agent nog vragen opzoekt die je zelf net zo snel vond. Scherp dan de prompt aan op de vier standaardverklaringen.
Info
Stand van zaken op 4 november 2026. Geen van de grote ERP- of voorraadpakketten heeft op dit moment een losse, kant-en-klare voorraadtelling-agent op de markt. De AI-laag zit bij de meeste leveranciers nog in Copilot-achtige assistentie, of in preview-functies zoals Microsofts Procurement Agent. Bouw daarom zelf een workflow op je eigen export. Check bij je eigen voorraadsysteem of er inmiddels een native AI-functie voor cyclisch tellen beschikbaar is, voor je zelf iets bouwt.
Doe dit deze week
Pak de laatste telronde en zet alle verschillen in een lijst
Systeemcijfer, telresultaat, verschil in stuks en in euro per product. Minstens vijftig regels, zodat de rangschikking iets oplevert.
Draai de prompt uit dit artikel op die lijst
Laat de agent rangschikken op waarde. Heb je toegang tot je verplaatsings- en ontvangstlog, laat hem dan ook een mogelijke verklaring voorstellen, zonder conclusie over de oorzaak. Vergelijk de uitkomst met wat jij zelf had uitgezocht. Tel hoeveel verschillen alleen al door de log verklaard werden.
Leg je drempel per productwaarde en je goedkeuringsregel schriftelijk vast
Eén A4: welk percentage bij welke productwaarde onderzoek vereist, wie een verschil boven die drempel goedkeurt, en dat een boeking nooit plaatsvindt zonder die goedkeuring. Doe dit voordat je de agent op een grotere telronde zet.
Het agent-recept dat vandaag werkt: na elke telronde leest de agent het telresultaat en het systeemcijfer, rangschikt de verschillen op geldwaarde, en zoekt per verschil in de log van de laatste zeven dagen naar een mogelijke verklaring. Alles boven je drempel gaat apart, met die verklaring erbij. Jij beoordeelt de lijst en zet zelf de boeking. Bouw dit uit met code via een AI-agent maken zonder code, of begin met de prompt uit dit artikel in de promptbibliotheek.
In de Agent Sprint bouw je dit op je eigen telrapportages. Zie voorraadbeheer met AI voor de stap na deze telronde: besteladvies op basis van verkoopdata. Een AI-werksessie brengt in kaart of je hele team met agents aan de slag kan.
AI-training
Wil je AI leren inzetten?
In onze praktische trainingen leer je hoe je ChatGPT, Claude en andere AI-tools effectief inzet voor jouw werk.
Bronnen
- Shopify, Cycle Counting: Types, Best Practices & Benefits. Zelf geopend. Bron voor de IRA-formule en het rekenvoorbeeld, de ABC-indeling met telfrequentie en omzetaandelen, de triggers voor een telcontrole (waaronder een verplaatsing tussen locaties), en het advies om recente activiteit te documenteren voor je een verschil aanpast.
- Doss, What is Cycle Counting? Definition and Best Practices. Zelf geopend. Bron voor de variantiedrempels (1 tot 5% bij hoogwaardige producten, 5 tot 10% bij lagere waarde) en voor het belang van een root-cause-proces in plaats van losse correcties.
- Microsoft, Dynamics 365 Supply Chain Management. Zelf geopend. Bron voor de status van de Procurement Agent (preview, gericht op leveranciersberichten) en voor het ontbreken van een losse voorraadtelling-agent in het huidige aanbod.
- Anthropic, Configure permissions (Agent SDK). Zelf geopend. Bron voor het onderscheid tussen automatisch toegestane leesacties en acties die altijd een bewuste modus of goedkeuring vereisen, als voorbeeld van de scheiding tussen signaleren en beslissen.
Veelgestelde vragen
Wat is voorraadtelling en hoe verschilt dat van cyclisch tellen?
Voorraadtelling is het fysiek narekenen van je voorraad en het vergelijken met je systeemcijfer. Een jaarlijkse volledige telling doet dat in één keer voor het hele assortiment; cyclisch tellen spreidt dezelfde controle over het jaar uit, met vaste, kleinere rondes per productgroep. Een AI-agent telt in geen van beide gevallen zelf: hij vergelijkt het telresultaat met het systeemcijfer en rangschikt de verschillen.
Hoe groot mag een telverschil zijn voordat je het moet onderzoeken?
Een gangbare vuistregel is 1 tot 5% van de telde hoeveelheid bij hoogwaardige producten en 5 tot 10% bij producten met een lage waarde. Daaronder mag je het verschil corrigeren, daarboven onderzoek je eerst de oorzaak (een verplaatsing, een ontvangst, een retour) voor je het systeemcijfer aanpast. Pas de exacte percentages aan op je eigen marges en foutengeschiedenis.
Kan een AI-agent telverschillen automatisch corrigeren?
Een agent kan voorstellen welke verschillen klein genoeg zijn om te corrigeren, maar het aanpassen van het systeemcijfer boven je eigen drempel blijft bij een mens. Reden: een correctie zonder onderzoek laat de echte oorzaak liggen, en die oorzaak (een trage boeking, een structurele fout, soms diefstal) komt bij de volgende telronde gewoon terug.
Hoe vaak moet je per productgroep tellen volgens de ABC-indeling?
De gangbare indeling telt A-producten (de kern van je omzet, een klein deel van je voorraad) maandelijks, B-producten per kwartaal en C-producten (veel voorraad, weinig omzet) een of twee keer per jaar. Een AI-agent kan dat schema voorstellen op basis van je verkoop- en voorraadhistorie, maar het vaststellen van het schema blijft een keuze van de voorraadverantwoordelijke.
Wat is de formule voor inventory record accuracy (IRA)?
IRA = 1 min (de som van de verschillen gedeeld door de som van de totale voorraad) keer 100. Tel je bijvoorbeeld 148 stuks waar het systeem 150 stuks aangeeft, dan is het verschil 2 stuks en je IRA 98,7%. De meeste operations-teams streven naar 98 tot 99% inventory record accuracy.
