Een AI-workflow ontwerpen: van melding tot gecontroleerde actie

'Kunnen we onze meldingen met AI afhandelen?' is een begrijpelijke vraag. Toch zit het lastige werk meestal vóór de toolkeuze. Wanneer is een melding compleet? Wie beslist over een onduidelijk geval? En hoe weet je dat er werkelijk een werkopdracht is aangemaakt?
Een AI-workflow ontwerpen betekent vastleggen hoe informatie via een beslissing tot een gecontroleerde actie leidt. Hieronder werken we één proces uit: medewerkers melden een defect, de facilitaire dienst krijgt een bruikbare werkopdracht.
Teken eerst het resultaat en de eigenaar
De gewenste uitkomst is een geregistreerde werkopdracht met locatie, object, omschrijving en aangewezen behandelgroep. De coördinator van de facilitaire dienst is proceseigenaar. Die bepaalt de categorieën en de route voor uitzonderingen.
Dit artikel gaat over die proceskeuzes. Onze algemene blog over AI-automatisering behandelt breder welke toepassingen en gereedschappen mogelijk zijn. Hier kiezen we geen catalogus aan tools, maar leggen we vast hoe één melding door het werk loopt.
LangChain onderscheidt vaste workflows van dynamische agents. Voor dit proces ligt de hoofdlijn vast. AI kan vrije tekst interpreteren; bestaande regels kunnen verplichte velden en de toegestane vervolgstappen controleren.
1. Invoer: maak duidelijk wat er binnenkomt
Een medewerker schrijft: 'Het apparaat naast het raam doet het weer niet.' Een mens die dezelfde ruimte kent, begrijpt misschien wat bedoeld wordt. Een automatisch proces mist locatie, object en mogelijk de aard van het defect. Dat is een invoerprobleem, geen reden om een uitgebreider model te kiezen.
Vraag minimaal de locatie, het object en de waarneming. Het systeem kan een keuzelijst met gebouwen aanbieden. AI kan uit een vrije omschrijving een voorstel voor object en klacht halen. Laat die suggestie zichtbaar bevestigen wanneer er twijfel is.
Bewaar de oorspronkelijke melding naast de gestructureerde samenvatting. Zo kan de behandelaar zien welke details uit de tekst komen en wat het systeem ervan gemaakt heeft. Gebruik geen oude melding als feitelijke beschrijving van het huidige defect.
2. Beslissing: leg elke afslag uit
Een defecte printer gaat volgens de afgesproken tabel naar werkplekondersteuning. Een kapotte deurklink gaat naar gebouwbeheer. Een onbekend object gaat naar de coördinator. De AI mag een categorie voorstellen, maar de categorie moet tot de toegestane lijst behoren.
Leg per afslag vast wat de reden is en welke informatie nog ontbreekt. 'Gebouwbeheer, omdat het object een deur betreft' is controleerbaar. 'Lage zekerheid' zonder verklaring helpt de coördinator minder. De onbekende route moet volwaardig ontworpen zijn, zodat het systeem geen categorie hoeft te verzinnen.
Laat vaste bedrijfsregels waar mogelijk door gewone software uitvoeren. AI hoeft bijvoorbeeld geen gebouwcode te raden als de medewerker die al heeft gekozen. Een model is vooral nuttig waar betekenis uit wisselende taal moet worden gehaald.
3. Actie: registreer één herkenbare werkopdracht
Na de beslissing maakt het systeem de werkopdracht aan in de afgesproken wachtrij. Iedere melding krijgt een uniek nummer. Dat nummer verbindt de oorspronkelijke invoer, de classificatie en de geregistreerde opdracht. De medewerker krijgt een ontvangstbevestiging met dat nummer.
Maak de grens van deze actie expliciet: registreren betekent nog niet dat een monteur is ingepland of dat het defect is opgelost. De tekst naar de medewerker moet passen bij de werkelijk bereikte toestand. Zo voorkom je verwachtingen die het proces niet kan waarmaken.
Als registratie goedkeuring vereist, plaats die vóór de echte schrijfactie. OpenAI beschrijft goedkeuringspauzes vóór tooluitvoering. Of je dezelfde techniek gebruikt, hangt van je platform af; de procesafspraak moet in de uitvoeringsroute terugkomen.
4. Controle: lees de opgeslagen uitkomst terug
Controleer na registratie of het werkordernummer bestaat en of locatie, categorie en omschrijving overeenkomen met de geaccepteerde gegevens. Een technisch geslaagde verbinding is onvoldoende als de opdracht in de verkeerde wachtrij staat.
Ook een medewerker moet het resultaat kunnen herkennen. Toon bijvoorbeeld 'Melding 184, gebouw B, printer tweede verdieping, ontvangen door werkplekondersteuning.' Dat is specifiek genoeg om een verkeerde locatie op te merken. Vermijd een algemene succesmelding zonder terugkoppeling.
Neem deze controle op in het procesontwerp, niet als losse handmatige stap die iemand moet onthouden. Hetzelfde geldt wanneer meerdere onderdelen samenwerken. De uitleg over orchestration helpt de afhankelijkheden tussen die onderdelen benoemen.
5. Herstel: ontwerp wat er gebeurt bij twijfel
Geef de melding vóór de eerste schrijfpoging een vaste referentie en gebruik die bij iedere herhaling. Laat het ontvangende systeem die referentie en de werkopdracht samen atomair opslaan, zodat dezelfde referentie één opdracht oplevert. Lees na een time-out de uitkomst terug. Een voorafgaande zoekopdracht alleen sluit gelijktijdige dubbele opslag niet uit.
Is de toestand niet vast te stellen, dan blijft de melding zichtbaar voor de coördinator met status 'registratie controleren'. Ze verdwijnt niet in een stil foutlog. De coördinator krijgt de laatste bekende stap en de gegevens die nodig zijn om verder te gaan.
LangGraph documenteert het bewaren van workflowtoestand. In dit ontwerp is dat nodig om vanaf de juiste stap te hervatten. Alleen de oorspronkelijke prompt opnieuw starten kan eerder uitgevoerde acties herhalen.
Beproef de hele route vóór je uitbreidt
Maak een kleine proefset met een complete printermelding, ontbrekende locatie, onbekend object en een onderbroken registratie. Dien ook twee meldingen tegelijk in met dezelfde referentie: de gewenste uitkomst is één werkopdracht. Schrijf per geval vooraf de juiste eindtoestand op. Laat een facilitair medewerker beoordelen of de werkopdracht voldoende informatie bevat om verder te werken.
Meet daarna waar correcties nodig zijn: invoer, categorisering, registratie of overdracht. Een totaalscore kan verbergen dat één zeldzame fout veel herstelwerk veroorzaakt. Pas eerst die stap aan voordat je extra afdelingen of acties toevoegt.
Wil je met je team een proces uitwerken, gebruik de incompany training als vertrekpunt voor een passend programma. Neem een bestaand proces mee met echte uitzonderingen. Juist daar wordt zichtbaar welke beslissingen bij AI, gewone software of een medewerker horen.
Zelf aan de slag met Vibe Coding?
Leer hoe je met AI-tools werkende apps bouwt. Onze praktische cursussen nemen je stap voor stap mee.
Blijf op de hoogte
Ontvang maandelijks de nieuwste tips over vibe coding, AI tools en exclusieve content.
Meer artikelen
Een MCP-server bouwen met één eenvoudige voorraadtool
Bouw een kleine MCP-server die fictieve voorraad uitleest. Je ziet het entrypoint, invoerschema, resultaat en foutgedrag zonder een bedrijfssysteem aan te sluiten.
Codex op Windows: kies bewust tussen native en WSL2
Je kunt Codex native op Windows gebruiken of binnen WSL2. Kies op basis van je project, en controleer apart waar de terminal en de agent draaien.
Claude Code hooks: start een vaste controle na een bewerking
Gebruik Claude Code hooks voor een kleine, vaste kwaliteitscontrole. Met een oefenvoorbeeld voor ontbrekende vertalingen en uitleg over wat de uitslag bewijst.