Het verschil tussen een regel en een oordeel in uw processen

Een klant stuurt een mail met een klacht over een beschadigde levering. Uw medewerker opent de mail, denkt even na, en besluit een creditnota te sturen. Dat is in drie minuten geregeld. Maar als diezelfde medewerker ziek is, ligt de mail tot dinsdag te wachten. En de beslissing die er al in zat, die al drie jaar bij elke beschadigde levering hetzelfde uitpakt, heeft toch een mens nodig gehad.

Dit is precies waar het onderscheid tussen een regel en een oordeel praktisch wordt. Niet als theoretisch onderscheid, maar als de vraag die bepaalt wat u kunt automatiseren en wat u beter bij een mens laat. Die vraag is de basis van elk gesprek dat wij voeren voordat we een agent bouwen.

Een regel is iets wat u kunt opschrijven zonder context

Een regel heeft de vorm van: als X, dan Y. Altijd. Zonder uitzonderingen, of met uitzonderingen die ook als regel te beschrijven zijn. 'Bij een beschadigde levering sturen we een creditnota voor het beschadigde artikel.' Dat is een regel. U kunt hem opschrijven, een nieuwe medewerker in tien seconden uitleggen, en een agent in tien minuten instrueren.

Wat een regel niet heeft: grijstinten. Er is geen 'het hangt ervan af'. Er is geen 'normaal wel, maar bij die klant niet'. Als u die zinnen hoort in de mond van uw medewerker, bent u al bij een oordeel beland. Dat is geen probleem, dat is informatie.

Regels zijn ook stapelbaar. 'Bij schade sturen we een creditnota, tenzij de order al gecrediteerd was in de afgelopen 60 dagen, in dat geval gaat het naar de leidinggevende.' Dat zijn twee regels achter elkaar. Een agent kan dat aan. De grens ligt niet bij complexiteit, maar bij de vraag of alle uitzonderingen te benoemen zijn.

Een oordeel vereist iets wat niet in de systemen staat

Een oordeel is een beslissing waarbij de context buiten uw data valt. U weet dat de klant al jaren bij u koopt, maar u weet ook dat er gisteren een gespannen telefoongesprek was met de verkoper. Die combinatie van feiten en sfeer bepaalt of u soepel of terughoudend reageert. Dat staat nergens in een systeem.

Oordelen zijn ook de beslissingen waarbij twee redelijke mensen tot twee verschillende conclusies kunnen komen, zonder dat één van hen fout is. Mag deze klant een extra betalingstermijn, gezien de omstandigheden? Dat is geen rekensom. Dat is beleid plus relatie plus inschatting. Een agent heeft de eerste twee nodig om voor te bereiden, maar de derde hoort bij een mens.

Welke beslissingen in uw bedrijf maken uw mensen op basis van informatie die alleen in hun hoofd zit? Die vraag is vaak verrassender te beantwoorden dan u verwacht. Het antwoord wijst bijna altijd naar oordelen die u nog niet als zodanig herkend had.

Regels die als oordeel worden behandeld, kosten uw team onnodig tijd

Dit is de meest voorkomende verspilling die ik tegenkom. Een medewerker overweegt elke keer opnieuw wat eigenlijk allang vaststaat. Niet omdat de situatie complex is, maar omdat de regel nooit expliciet gemaakt is. Het voelt als nadenken, maar het is eigenlijk herhalen.

Denk aan debiteurenbeheer automatiseren. De beslissing om een herinnering te sturen bij een factuur van dertig dagen oud is geen oordeel, dat is een regel. Toch zit er bij veel bedrijven nog een medewerker die elke factuur handmatig langs loopt, erover nadenkt, en dan dezelfde mail stuurt als altijd. De agent kan dat signaleren en de herinnering klaarzetten. Uw medewerker verstuurt.

De echte winst zit niet alleen in de tijd die de medewerker terugkrijgt. Het zit ook in de consistentie. Een herinnering die altijd op dag dertig verstuurd wordt, werkt structureel anders dan een herinnering die op dag dertig, vijfendertig of veertig verstuurd wordt, afhankelijk van wie er tijd voor heeft.

Begin niet met automatiseren, begin met het benoemen

Voordat u nadenkt over welke tool of welke agent u inzet, is er een stap die vrijwel iedereen overslaat: het expliciet maken van de regels die nu impliciet in uw medewerkers zitten. Dat klinkt eenvoudig. Dat is het niet.

Vraag uw medewerker om de vijf beslissingen te beschrijven die hij of zij elke week het vaakst maakt. Vraag daarna: zou een goede stagiair dit op dezelfde manier doen na één dag uitleg? Als het antwoord ja is, heeft u een regel. Als het antwoord is 'eigenlijk wel, maar je moet echt even weten hoe onze klanten werken', dan heeft u een oordeel, of een regel die nog niet goed genoeg beschreven is.

Dit gesprek levert twee dingen op. Eerst: u ontdekt welke processen klaar zijn voor automatisering. In het artikel over welk proces geschikt is voor een agent staat een bruikbaar filter om dat snel te beoordelen. Daarnaast: u maakt kennis expliciet die tot nu toe alleen in hoofden zat. Dat is waardevoller dan de automatisering zelf, omdat de kennis nu ook overdraagbaar is.

Oordelen maken agents niet nutteloos, ze bepalen de taakverdeling

Het misverstand dat ik het vaakst tegenkom: 'als een agent niet alles kan, heeft het weinig zin'. Dat klopt niet. Een agent hoeft het oordeel niet te nemen om waardevol te zijn. Hij kan het oordeel voorbereiden.

Stel dat u een klant heeft die een uitzonderlijk grote order plaatst, buiten het gangbare patroon. Moet u die accepteren zonder extra controle? Misschien, misschien niet. Dat is een oordeel. Maar de agent kan alle relevante informatie al boven water halen: orderhistorie, betaalgedrag, openstaande facturen, eerder contact. Uw medewerker hoeft dan geen tien minuten te zoeken. Die neemt het oordeel op basis van wat er al klaarligt.

Bij orderverwerking automatiseren werkt het precies zo. De controles zijn regels: klopt het adres, is er voldoende voorraad, voldoet de klant aan de kredietlimiet? Als alle lichten op groen staan, kan de orderregel klaargezet worden. Als er een geel licht is, gaat het naar een mens met alle informatie erbij. Niet het oordeel automatiseren, wel het voorwerk.

Regels die niet kloppen, zijn gevaarlijker dan oordelen

Eén belangrijk voorbehoud. Een regel die fout is, schaalt even snel als een regel die goed is. Als u een agent instrueert om altijd een creditnota te sturen bij een klacht, maar uw beleid is eigenlijk 'bij de eerste klacht van een nieuwe klant altijd eerst bellen', dan voert de agent het foute beleid consistent uit. Dat is duurder dan inconsistentie.

Dat is ook de reden dat guardrails niet optioneel zijn. Elke agent die wij bouwen heeft een laag met beleidsregels die bepaalt wat automatisch mag en wat langs een mens moet. Die regels stelt u zelf in, en u past ze aan als uw beleid verandert. Een agent zonder die laag is een medewerker zonder handleiding die nooit vragen stelt.

Controleer uw regels dus voordat u automatiseert. Niet perfect, want perfecte regels bestaan niet. Maar goed genoeg dat een buitenstaander ze zonder toelichting kan toepassen. Als dat lukt, kunt u automatiseren. Als het niet lukt, heeft u werk te doen aan het beleid, en dat werk loont ook als u nooit een agent bouwt.

Maandag begint met één proces opschrijven

Kies maandag één proces dat uw team minstens drie keer per week uitvoert. Schrijf op wat er beslist wordt, op basis van welke informatie, en of de uitkomst altijd hetzelfde is. Als dat lukt in een half A4, heeft u waarschijnlijk een regel. Als u halverwege merkt dat u uitzonderingen stapelt die u eigenlijk ook niet goed kunt beschrijven, bent u bij een oordeel. Dat onderscheid is het begin van alles.