Documenteer bedrijfsregels voor AI-apps in eenvoudige taal

Waarom vage regels onbetrouwbare apps maken

Bedrijfsregels vertellen een app wat te doen in echte situaties. Ze beantwoorden vragen zoals wie een verzoek kan goedkeuren, hoe een totaal wordt berekend en wat er gebeurt als een zaak buiten het normale patroon valt.

Als die regels vaag zijn, moet de app alsnog een pad kiezen. Het kiest alleen misschien niet het pad dat jij verwachtte.

Neem een regel als "grote uitgaven vereisen goedkeuring door een manager." Een persoon vindt dat misschien duidelijk. Een bouwer niet. Wat telt als groot: $500, $5.000, of alles boven het teambudget? Welke manager: de directe manager, het afdelingshoofd of finance? Als niemand binnen twee dagen reageert, wacht het verzoek dan, verloopt het of gaat het naar iemand anders?

Daarom leiden vage regels tot onbetrouwbare apps. De bouwer kan alleen zo consistent zijn als de instructies die hij krijgt. Als de formulering ruimte laat voor giswerk, kan de app de ene keer op één manier reageren en de volgende keer anders bij een iets afwijkend geval.

De grootste problemen tonen zich meestal in een paar gebieden:

• berekeningen met ontbrekende details, zoals afronding, belasting, kortingen of datumbereiken
• uitzonderingen die iedereen aanneemt maar die niemand opschrijft
• goedkeuringsstappen zonder duidelijke eigenaar, volgorde of fallback

Een simpel voorbeeld laat het probleem zien. Een oprichter bouwt een interne onkostenapp in Koder.ai en schrijft: "Vergoed reiskosten, tenzij ze ongebruikelijk lijken." Dat klinkt redelijk, maar de app heeft geen betrouwbare manier om "ongebruikelijk" te beoordelen. De taxi van de ene medewerker wordt goedgekeurd, een vergelijkbare taxi van een ander wordt gemarkeerd en niemand weet waarom.

Betrouwbaar gedrag begint met regels die elke keer op dezelfde manier gevolgd kunnen worden. Woorden als "groot,", "dringend" en "speciale geval" moeten worden vervangen door exacte limieten, voorwaarden en acties. Als twee verschillende mensen de regel op dezelfde manier zouden toepassen, is de kans veel groter dat de app dat ook doet.

Hoe een duidelijke bedrijfsregel eruitziet

Een duidelijke bedrijfsregel behandelt één beslissing of één actie, niet een heel proces. Dat is belangrijker dan de meeste teams verwachten. Als één regel probeert goedkeuring, prijsstelling, uitzonderingen en notificaties tegelijk te dekken, moet de bouwer raden welk deel het belangrijkst is.

Een goede regel is makkelijk hardop voor te lezen. Iemand buiten je team moet het begrijpen zonder je interne afkortingen. Vervang termen als "fast-track", "standaardgeval" of "managerondertekening" door eenvoudige taal die precies zegt wat er gebeurt.

De meeste duidelijke regels beantwoorden vier basisvragen:

• Wie neemt de beslissing of voert de actie uit?
• Wanneer is de regel van toepassing?
• Wat verandert er in de app?
• Wat gebeurt er daarna?

Die structuur houdt de regel verbonden met echt gedrag. In plaats van te schrijven: "Grote bestellingen moeten worden beoordeeld," schrijf je: "Als een bestelling meer dan $5.000 is, moet de salesmanager deze goedkeuren voordat deze naar fulfillment kan." Eén zin, één beslissing, één resultaat.

Het helpt ook om gerelateerde regels gescheiden te houden. De goedkeuringsregel moet op zichzelf staan. De regel voor het verzenden van een e-mail moet apart zijn. De regel voor het blokkeren van verzending moet ook apart zijn. Dat maakt elke regel makkelijker te testen, bij te werken en te repareren.

Het verschil is makkelijk te zien:

"Premium klanten krijgen prioriteit behandeling" is vaag.

"Als de klant een premium abonnement heeft, wordt het supportverzoek gemarkeerd als Hoge Prioriteit wanneer het ticket wordt aangemaakt" is duidelijk.

De tweede versie noemt de trigger, de voorwaarde en de wijziging in de app. Het vertelt de bouwer hoe betrouwbaar gedrag eruit moet zien.

Als je een chat-gebaseerde bouwer gebruikt, maakt dit soort formuleringen een groot verschil. Duidelijke regels hebben geen juridische taal nodig. Ze hebben eenvoudige woorden, één idee per keer en een verwacht resultaat dat in één zin past.

Berekeningen schrijven in eenvoudige taal

Berekeningen lijken vaak simpel totdat iemand ze probeert te bouwen. De veiligste aanpak is te beginnen met één korte zin die precies zegt wat de app moet doen.

Een goede regel klinkt als: "Het terugbetalingsbedrag is gelijk aan goedgekeurde kilometers maal het kilometerloon." Dat is veel duidelijker dan "bereken reiskosten" of "pas standaardvergoeding toe."

Na die eerste zin definieer je elke invoer die de app moet gebruiken. Wees specifiek genoeg zodat de bouwer niet hoeft te raden.

Wat je voor elke berekening moet definiëren

Voor elke berekening schrijf je uit:

• de inputs, met eenvoudige namen en eenheden
• waar elke waarde vandaan komt
• afrondingsregels
• eventuele minimum- of maximumwaarde
• wat er gebeurt als een waarde ontbreekt

Kleine details doen ertoe. "Rond het eindbedrag af op 2 decimalen" geeft een ander resultaat dan elke regel apart afronden. Als er een limiet is, zeg dan of de app bij die limiet stopt of een waarschuwing toont.

Een regel in eenvoudige taal kan er zo uitzien: "De reiskostenvergoeding is gelijk aan goedgekeurde kilometers x $0.67. Rond het eindbedrag af op 2 decimalen. De maximale vergoeding is $300 per reis. Als goedgekeurde kilometers leeg is, bereken het bedrag niet. Markeer het verzoek als incompleet en vraag de gebruiker om kilometers in te voeren."

Voeg daarna één of twee uitgewerkte voorbeelden met echte getallen toe. Voorbeelden onthullen sneller hiaten dan abstracte formules.

Example 1: "If approved miles is 120, reimbursement is 120 x $0.67 = $80.40. Because this is below the $300 cap, the final amount is $80.40."

Example 2: "If approved miles is 500, reimbursement is 500 x $0.67 = $335.00. Because the maximum is $300, the final amount is $300.00."

Deze stijl is makkelijker voor mensen om te beoordelen en eenvoudiger voor een bouwer om in app-gedrag om te zetten.

Uitzonderingen vastleggen zonder verwarring

De meeste apps falen niet op het hoofdpad. Ze falen op randgevallen.

Het normale pad kan eenvoudig zijn, maar echt werk bevat restituties na een deadline, VIP-klanten, ontbrekende documenten en eenmalige goedkeuringen. Als uitzonderingen worden weggelaten, vult de app het gat zelf in, en daar beginnen de inconsistente resultaten.

Een eenvoudige manier om uitzonderingen te schrijven is korte if-dan regels te gebruiken. Houd elke regel gericht op één voorwaarde en één uitkomst.

• Als de onkost minder dan $100 is, dan auto-goedgekeurd.
• Als de onkost minder dan $100 is maar ingediend na 30 dagen, dan stuur naar handmatige beoordeling.
• Als de werknemer bij het executive team hoort, dan overschrijdt hij de $100-limiet en wordt naar finance gestuurd.
• Als een finance-admin de claim als urgent markeert, dan geldt handmatige override en gaat de claim naar de top van de wachtrij.

Dit formaat maakt verborgen logica zichtbaar. Het helpt je ook om overlappingen te vinden voordat ze bugs worden.

Net zo belangrijk: zeg welke regel wint als twee regels botsen. Een klant kan in aanmerking komen voor een korting, maar de bestelling kan ook in een feestdag-blackout vallen. Schrijf de prioriteit in eenvoudige taal: "Als een feestdag-blackoutregel in conflict is met een klantkortingsregel, wint de blackoutregel."

Wees precies over grenzen. Datums, gebruikersrollen, locaties, accountstatus en handmatige overrides veranderen vaak de uitkomst. In plaats van te schrijven "late inzendingen vereisen goedkeuring," schrijf: "Als een verzoek meer dan 14 kalenderdagen na het evenement wordt ingediend, is managergoedkeuring vereist."

Zeg ook wat de app de gebruiker moet tonen bij elke uitzondering. Een goede regel stopt niet bij de beslissing. Ze definieert ook het bericht, zoals "Ingediend na 14 dagen. Managergoedkeuring vereist" of "Handmatige override toegepast door finance-admin."

Wanneer uitzonderingen op deze manier worden geschreven, voelen ongewone gevallen niet meer ongewone. Ze worden normaal, testbaar gedrag.

Goedkeuringslogica stap voor stap beschrijven

Goedkeuringslogica werkt het best als deze als een reeks beslissingen wordt geschreven, niet als een vage beleidsregel. Elke stap moet vijf vragen beantwoorden: wie handelt, wat triggert hun beoordeling, welke limieten gelden, hoe lang hebben ze, en welke status krijgt het verzoek nadat ze beslissen.

Begin met het benoemen van de rol, niet alleen het team. In plaats van te schrijven "finance beoordeelt grote verzoeken," schrijf: "De Finance Manager kan elk verzoek boven $5.000 goedkeuren, afwijzen of terugsturen." Dat haalt giswerk weg en maakt het gedrag makkelijker te bouwen.

Definieer daarna de trigger voor elke stap. Een trigger is de voorwaarde die het verzoek naar de volgende persoon stuurt. Het kan gebaseerd zijn op bedrag, afdeling, risiconiveau, verzoektype of een mix daarvan.

Bijvoorbeeld:

• Als het verzoek onder $500 is, beoordeelt de teamlead het.
• Als het verzoek $500 tot $5.000 is, beoordeelt de afdelingsmanager het nadat de teamlead heeft goedgekeurd.
• Als het verzoek boven $5.000 is, beoordeelt finance het nadat de afdelingsmanager heeft goedgekeurd.
• Als het verzoek als hoog risico is gemarkeerd, moet compliance het beoordelen vóór de definitieve goedkeuring.

Drempels hebben exacte grenzen nodig. Zeg niet "groot" of "gevoelig." Zeg "boven $5.000," "van de Sales-afdeling" of "risicoscore 8 of hoger." Als twee drempels tegelijk van toepassing kunnen zijn, zeg welke wint. Bijvoorbeeld: "Hoog risico gaat altijd naar compliance, zelfs als het bedrag laag is."

Je hebt ook een timeout-regel nodig. Als niemand reageert, mag de app niet voor altijd in limbo blijven. Zeg wat er gebeurt na een vaste tijd, zoals 48 uur of 3 werkdagen. Het verzoek kan worden geëscaleerd naar de manager van de goedkeurder, worden toegewezen aan een back-upgoedkeurder of automatisch worden geannuleerd.

Definieer tenslotte de status na elke beslissing. Houd de labels kort en consistent:

• Approved: het verzoek gaat verder of is voltooid.
• Rejected: het verzoek wordt gesloten en er wordt geen verdere actie ondernomen.
• Sent back: de aanvrager moet bewerken en opnieuw indienen.
• Escalated: het verzoek gaat naar een back-up of hogere goedkeurder.

Als goedkeuringslogica op deze manier wordt geschreven, heeft de bouwer minder ruimte om te raden en wordt de workflow veel betrouwbaarder.

Een eenvoudig regelsjabloon dat je kunt hergebruiken

Als je consistent gedrag wilt, geef elke regel dezelfde vorm. Gemengde schrijfstijlen leiden vaak tot gemengde resultaten.

Een simpel format werkt goed voor de meeste gevallen: trigger, voorwaarden, actie, resultaat. Het is kort genoeg om snel te schrijven en duidelijk genoeg voor iemand anders om later te beoordelen.

Gebruik één regel, één eenheid

Houd elke regel op een eigen regel, kaart of blok. Prop niet meerdere ideeën in één alinea. Als een regel prijsstelling, goedkeuring en een uitzondering tegelijk behandelt, wordt het moeilijk te testen en gemakkelijk verkeerd te lezen.

Een praktisch sjabloon ziet er zo uit:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

Je hoeft niet elk veld elke keer te gebruiken. Maar het behouden van dezelfde volgorde helpt mensen om regels snel te scannen.

Bijvoorbeeld:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Let op dat het voorbeeld onder de regel staat, niet erin. Dat houdt de regel netjes. Het voorbeeld toont alleen hoe de regel zich moet gedragen.

Markeer aannames duidelijk in plaats van ze te verbergen in de zin. Een kleine note zoals "Assumption" of "Needs confirmation" maakt open vragen makkelijk te beoordelen vóór de bouw.

Het helpt ook om je woordkeuze consistent te houden. Begin altijd triggers met "When," voorwaarden met "If," en acties met "Then." Kleine patronen zoals deze verminderen verwarring, vooral wanneer regels in app-logica worden omgezet.

Een snelle test werkt goed hier: kan iemand deze regel testen, en kan iemand het verkeerd lezen? Als het antwoord op de eerste nee is, of op de tweede ja, verscherp dan de formulering.

Voorbeeld: een onkosten-goedkeuringsapp

Een onkostenapp is een goede testcase omdat het beleid bekend is en de randgevallen snel naar voren komen. Medewerkers kunnen maaltijden, taxi's, hotels en kleine klantkosten declareren, maar elke claim heeft limieten, uitzonderingen en goedkeuringsstappen. Dit is precies het soort proces waarbij eenvoudige taal ertoe doet.

Voorbeeldbeleid

Schrijf de maaltijdregel zo: medewerkers kunnen tot $40 per dag declareren voor maaltijden tijdens normale werkdagen. De app moet alle maaltijdbonnen voor dezelfde datum optellen en dat totaal vergelijken met de dagelijkse limiet, niet elk bonnetje afzonderlijk.

Als de medewerker $12 aan ontbijt en $22 aan lunch uitgeeft op dinsdag, is het totaal $34, dus de claim gaat door. Als daar op dezelfde dag nog een $15 diner bij komt, wordt het totaal $49 en moet de app de claim markeren als boven de limiet.

Voeg nu een uitzondering toe. Als de maaltijd plaatsvond tijdens goedgekeurd zakelijk reizen of een klantbijeenkomst, stijgt de dagelijkse limiet naar $75. Die uitzondering geldt alleen wanneer de medewerker bij Travel day = Yes of Client meeting = Yes selecteert en een korte notitie toevoegt met de klantnaam of het doel van de reis.

Dit is betrouwbaarder dan vage formuleringen zoals "speciale gevallen kunnen worden toegestaan" omdat de uitzondering gekoppeld is aan duidelijke voorwaarden.

Goedkeuringsstappen

De goedkeuringslogica kan net zo simpel blijven:

• Claims onder $100 worden goedgekeurd door de manager van de medewerker.
• Claims van $100 tot $500 hebben managergoedkeuring nodig, daarna financegoedkeuring.
• Claims boven $500 hebben managergoedkeuring, financegoedkeuring en goedkeuring door het afdelingshoofd nodig.
• Elke claim gemarkeerd als "travel" heeft ook finance-review nodig, zelfs als het bedrag onder $100 blijft.

Je kunt de regel testen met een paar eenvoudige gevallen. Een $36 maaltijdclaim op een normale werkdag moet worden goedgekeurd als bonnetjes zijn bijgevoegd. Een $60 maaltijdclaim op een reisdag moet slagen als travel is gemarkeerd en de notitie is ingevuld. Een $60 maaltijdclaim op een normale dag moet worden afgewezen of teruggestuurd voor correctie. Een $650 hotelclaim moet door alle drie goedkeuringsstappen heen gaan.

Dat is het doel: de regel zou elke keer hetzelfde resultaat moeten geven wanneer iemand hem test met echte gevallen.

Veelvoorkomende fouten die tot slechte resultaten leiden

Een regel kan voor een persoon duidelijk klinken en toch een bouwer in de war brengen. Dat gebeurt meestal wanneer het document vaag is, meerdere ideeën door elkaar gebruikt of inconsistent is van de ene regel naar de andere.

Een veelgemaakte fout is meerdere regels in één lange alinea proppen. Bijvoorbeeld: "Managers keuren reizen goed tenzij het totaal hoog is, finance controleert bonnetjes, en urgente verzoeken kunnen review overslaan." Dat lijkt efficiënt, maar het verbergt meerdere afzonderlijke beslissingen. Split het in aparte regels zodat elke actie één trigger en één uitkomst heeft.

Een ander probleem is vage taal. Woorden als normaal, groot, dringend of recent werken alleen als ze gedefinieerd zijn. Als "grote uitgave" alles boven $2.000 betekent, zeg dat. Als "dringend" betekent binnen 24 uur nodig, schrijf die exacte voorwaarde.

Ontbrekende data is een andere belangrijke bron van slechte resultaten. Teams beschrijven vaak het gelukkige pad en vergeten te zeggen wat moet gebeuren als informatie onvolledig of fout is. Als een verzoek geen bedrag, geen afdeling of geen bon heeft, moet de regel zeggen wat er daarna gebeurt.

De fouten die de meeste problemen veroorzaken zijn meestal:

• meerdere regels combineren in één alinea
• ongedefinieerde termen voor grootte, tijd of prioriteit gebruiken
• foutgevallen en ontbrekende velden vergeten
• de uiteindelijke goedkeuringsautoriteit onduidelijk laten
• namen voor hetzelfde ding halverwege veranderen

De uiteindelijke autoriteit doet er meer toe dan veel teams verwachten. Als een manager en een finance-reviewer het oneens zijn, wie neemt dan de laatste beslissing? Als niemand eigenaar is van de laatste stap, kan de app vastlopen of werk in cirkels blijven sturen.

Termwisselingen veroorzaken stillere fouten. Als je begint met "verzoek" en later het "submission" of "ticket" noemt, kunnen lezers aannemen dat het om verschillende items gaat. Kies één term en houd die consequent aan door het hele document.

Dit is nog belangrijker in een chat-gebaseerde bouwer, waar eenvoudige taal het gedrag stuurt. Duidelijke regels hoeven niet formeel te klinken. Ze moeten specifiek, consistent en compleet zijn.

Snelle checklist voordat je bouwt

Voordat je eisen omzet in schermen, flows of prompts, doe nog een laatste review. Een korte check nu kan uren reparatiewerk later besparen.

Maak elke regel testbaar. Elke regel moet eindigen met een duidelijke uitkomst zoals ja of nee, goedkeuren of afwijzen, fee toepassen of geen fee toepassen. Als twee mensen dezelfde zin kunnen lezen en verschillende antwoorden geven, moet de regel worden aangescherpt.

Schrijf elke berekening uit. Noem de inputs, de formule en wanneer de berekening plaatsvindt. Voeg afronding, valuta, dataverwerking en wat er moet gebeuren als een waarde ontbreekt of nul is.

Houd uitzonderingen apart. Schrijf eerst de standaardregel en voeg dan de uitzonderingen apart toe. De hoofduitgavlimiet mag niet verborgen zitten in een speciaal geval voor aannemers, urgente aankopen of vooraf goedgekeurd reizen.

Breng het volledige goedkeuringspad in kaart. Voor elke drempel, geef aan wie goedkeurt en wat er daarna gebeurt. Wees exact over randen: zeg of een regel begint boven $500 of bij $500 en hoger.

Doe daarna de nieuwe-collega-test. Geef de regel aan iemand die er nog niet aan heeft gewerkt en vraag hem om het in eigen woorden terug te leggen. Als ze extra context nodig hebben, is de regel nog te vaag.

Een klein voorbeeld toont waarom dit ertoe doet. "Manager keurt grote uitgaven goed" klinkt duidelijk totdat iemand vraagt of $500 als groot telt. "Manager keurt uitgaven boven $500 goed. Directeur keurt uitgaven boven $2.000 goed. Uitgaven van $500 of minder worden automatisch goedgekeurd" laat veel minder ruimte voor fouten.

Regels omzetten naar een werkende app

Zodra de regels duidelijk zijn, bespreek ze met de mensen die het proces elke dag gebruiken. Managers, coördinatoren, financepersoneel en goedkeurders zien vaak kleine details die nooit in het beleidsdocument terechtkomen. Die details bepalen meestal of een app soepel of frustrerend aanvoelt.

Behandel het regeldocument als werkinstructies, niet als een eenmalig concept. Het moet uitleggen wat gebeurt, wie beslist, wat de uitzonderingen zijn en wat de app moet doen als informatie ontbreekt.

Test voordat je de volledige app bouwt een paar echte scenario's uit recent werk. Gebruik zowel schone gevallen als rommelige: een standaardverzoek dat moet slagen, een verzoek met ontbrekende informatie, een uitzondering die handmatige beoordeling nodig heeft en een geval dat over een uitgavlimiet of goedkeuringsdrempel heen gaat.

Deze stap vangt hiaten vroeg. Een regel kan op papier duidelijk klinken maar uit elkaar vallen wanneer een echt verzoek niet in het verwachte patroon past.

Als die scenario's standhouden, zet ze dan in je bouwer. Als je een chat-gebaseerd platform gebruikt zoals Koder.ai, maakt een duidelijk regelschema het bouwen veel sneller omdat je een gedefinieerd proces naar schermen, acties en goedkeuringen vertaalt in plaats van ter plekke beslissingen te nemen.

Houd na lancering het document als de bron van waarheid. Wanneer beleid verandert, een nieuwe goedkeurder wordt toegevoegd of een limiet wordt aangepast, wijzig eerst het document en werk daarna de app bij. Dat houdt latere wijzigingen eenvoudiger en verkleint de kans dat verschillende mensen zich de regel anders herinneren.

Een kleine gewoonte helpt: bekijk de regels wanneer het proces verandert, niet alleen wanneer de app kapot gaat. Kleine updates vroeg doen is veel makkelijker dan verwarrend gedrag later repareren.

Als het document actueel blijft, wordt de app in de loop van de tijd makkelijker te testen, verbeteren en vertrouwenwekkender.