Het ontwerp van een goedkeuringsmatrix begint met drempels, back-up goedkeurders, vervangers en escalaties, zodat je schermen het echte beslisproces weergeven.
Een nette gebruikersinterface kan nog steeds een rommelig proces verbergen. Als de goedkeuringslogica niet eerst is vastgelegd, zien mensen misschien knoppen voor Goedkeuren en Afwijzen maar weten ze nog steeds niet wie moet handelen, wanneer ze moeten handelen of wat er daarna gebeurt.
Die verwarring verschijnt snel in het dagelijkse werk. Iemand dient een verzoek in, het komt in de app terecht en de eerste vraag is: "Gaat dit naar de manager, de financiënafdeling of naar beide?" Het scherm oogt af, maar het beslispad ontbreekt.
Dit gebeurt omdat schermen regels eenvoudiger laten lijken dan ze zijn. Een formulier kan status, opmerkingen en actiekoppen tonen, maar het kan niet raden welke goedkeuringsmatrix erachter zit. Als de organisatie limieten op bedragen, afdelingsregels of tijdelijke gevolmachtigden heeft, begint de UI te haperen zodra die gevallen zich voordoen.
Het duurt vaak maar één uitzondering om het werk buiten de app te duwen. Meestal gaan goedkeuringen naar een afdelingshoofd, behalve wanneer het verzoek dringend is, boven een bepaald bedrag ligt of de goedkeurder met verlof is. Als dat niet in kaart is gebracht, vallen mensen terug op e-mail, chat of spreadsheets.
Dan ontstaat een groter probleem: elk team voert zijn eigen versie van de regels in. Operations stuurt het verzoek de ene kant op, financiën een andere kant, en support behandelt uitzonderingen anders dan HR. De app wordt een gedeeld scherm voor inconsistente beslissingen in plaats van een gedeeld proces.
De waarschuwingssignalen zijn meestal eenvoudig te herkennen:
Beleidsupdates leggen deze zwakte snel bloot. Wanneer de logica in het scherm leeft in plaats van in duidelijke workflowregels, verandert elke drempel of rolwijziging in UI-herwerk. Dat vertraagt teams, creëert nieuwe fouten en ondermijnt het vertrouwen van gebruikers.
Het scherm zou het beslispad moeten weerspiegelen, niet definiëren. Wanneer de matrix eerst duidelijk is, wordt de UI eenvoudiger, stabieler en makkelijker in gebruik.
Begin met de beslislogica, niet met het scherm. Een degelijke goedkeuringsmatrix begint als een eenvoudige tabel die laat zien wie wat mag goedkeuren, onder welke voorwaarden, en wat er gebeurt als iemand niet beschikbaar is. Als die logica vaag is, zal zelfs een afgewerkte interface mensen verwarren.
Voor elk type verzoek breng je de goedkeuringsniveaus in volgorde in kaart. Noteer de rol die elke stap bezit en wat die stap toestaat: goedkeuren, afwijzen, beoordelen of terugsturen. Rollen werken beter dan persoonsnamen omdat mensen van baan veranderen, teams verschuiven en het proces toch stand moet houden.
Bepaal daarna de regels die de route veranderen. Bedrag is de voor de hand liggende trigger, maar het is zelden de enige. Goedkeuringsworkflows hangen vaak af van regio, afdeling, leverancierstype, verzoekcategorie of risiconiveau. Hetzelfde bedrag kan in het ene team routine zijn en in het andere gevoelig.
Afwezigheden hebben ook regels nodig. Als de hoofdgoedkeurder afwezig is, wie neemt dan direct over? Als de vervanger tijdelijk is, welke data gelden dan? Zonder dat blijven verzoeken stil liggen omdat niemand weet wie er deze week eigenaar is.
Tijdslimieten zijn net zo belangrijk. Bepaal wat er gebeurt als een verzoek geen reactie krijgt. Je kunt bijvoorbeeld een herinnering sturen na één dag, escaleren na twee dagen en operations informeren na drie. Die keuzes beïnvloeden statuslabels, meldingen en wachtrijweergaven, dus ze moeten worden vastgelegd voordat het schermontwerp begint.
Een praktische matrix beantwoordt meestal vijf basisvragen:
Als je die antwoorden vroeg in kaart brengt, wordt de rest van de bouw veel eenvoudiger.
Gebruik een tabel, whiteboard of spreadsheet. Houd het simpel genoeg zodat een manager, teamleider en procesverantwoordelijke het in één keer begrijpen.
Begin met het opsommen van elk verzoektype dat goedkeuring nodig heeft. Probeer niet alles in één generieke workflow te dwingen als het bedrijf verzoeken al verschillend behandelt. Een inkoopverzoek, terugbetaling, kortingstoekenning en toegangsaanvraag hebben vaak verschillende goedkeurders, limieten en deadlines nodig.
Schrijf vervolgens de eerste goedkeurder en daarna elk beslispunt daarachter op. Noteer voor elk verzoektype wie het als eerste beoordeelt en wat er gebeurt na goedkeuring of afwijzing. Volg het pad totdat je een einduitkomst bereikt, zoals goedgekeurd, afgewezen, teruggestuurd voor bewerking of geannuleerd.
Voeg daarna de drempels toe die de route veranderen. Hier blijven veel teams later steken. Als een verzoek onder $500 naar een teamleider gaat maar alles boven $500 naar een afdelingshoofd, noteer dat nu. Als urgente verzoeken een stap overslaan of een snellere route volgen, leg dat vast.
Vervolgens noteer je uitzonderingen, deadlines en eindstatussen. Neem gevallen op zoals ontbrekende documenten, dubbele verzoeken, beleidsoverschrijdingen en achterstallige goedkeuringen. De regel is niet af totdat je weet hoe hij zich gedraagt als dingen misgaan.
Ten slotte bespreek je de conceptversie met de mensen die vandaag verzoeken goedkeuren. Vraag waar werk gewoonlijk vastloopt, waar stappen worden overgeslagen en wat er gebeurt als de normale goedkeurder niet beschikbaar is. Reële gewoonten onthullen vaak regels die nooit gedocumenteerd zijn.
Een klein voorbeeld maakt dit duidelijk. Stel je een inkoopverzoek voor: kantoorbenodigdheden onder $200 gaan naar de teamleider, software tussen $200 en $2.000 naar de afdelingsmanager, en alles daarboven moet ook door financiën. Als het formulier bedrag en categorie niet vroeg vastlegt, kan de UI het verzoek niet naar de juiste route sturen.
Drempels werken alleen wanneer mensen ze snel kunnen aflezen en telkens hetzelfde beslissen. Als een regel zegt "kleine aankopen" of "hoog-risico leveranciers," interpreteren verschillende mensen dat anders. Gebruik vaste bedragen, data en benoemde voorwaarden in plaats daarvan.
Een duidelijkere regel klinkt zo: "Tot $1.000 gaat naar de teamleider. $1.001 tot $5.000 gaat naar de afdelingsmanager. Meer dan $5.000 gaat naar financiën en de directeur." Niemand hoeft te raden waar het verzoek thuishoort.
Bedrag is een veelvoorkomende trigger, maar het moet niet de enige factor zijn als je proces van andere aspecten afhangt. Een goedkope softwareaankoop bij een nieuwe leverancier kan meer controle nodig hebben dan een grotere bestelling bij een goedgekeurde leverancier.
De meeste teams hebben maar een kleine set routeringsregels nodig. Veelvoorkomende voorbeelden zijn bedragscategorie, leveranciersstatus, aankoopcategorie, afdeling en urgentie. Het belangrijkste is niet het aantal regels, maar of iedereen ze op dezelfde manier toepast.
De volgorde van regels is ook belangrijk. Als mensen niet weten welke voorwaarde voorgaat, zullen ze hetzelfde verzoek verschillend routeren. Kies één volgorde en houd je daaraan. Je kunt eerst leveranciersstatus controleren, dan categorie, dan bedrag. Of je controleert eerst het bedrag en behandelt uitzonderingen daarna. Beide werken als iedereen dezelfde volgorde volgt.
Het helpt ook om te definiëren wie een drempel mag overrulen en wanneer. Zonder dat wachten medewerkers te lang of omzeilen ze het proces via e-mail en chat. "De financieel directeur mag boven-limiet verzoeken goedkeuren tijdens maandafsluiting" is nuttig. "Het senior leiderschap kan uitzonderingen maken" is dat niet.
Een eenvoudige test werkt hier goed: geef hetzelfde voorbeeldverzoek aan drie mensen en vraag waar het naartoe moet. Als ze drie verschillende antwoorden geven, zijn de drempels nog te vaag.
Een sterke matrix stopt niet bij de hoofdgoedkeurder. Werk blijft doorgaans doorlopen wanneer iemand op verlof is, ziek is of gewoon niet op tijd reageert. Als je daar niet vroeg voor plant, kan het scherm er netjes uitzien terwijl het proces stilletjes vastloopt.
Begin met het benoemen van de back-up goedkeurder voor elke belangrijke stap. Dit moet een persoon of rol met de juiste context zijn, niet alleen "de volgende manager" als standaard. Als een finance lead uitgaven boven een bepaald bedrag goedkeurt, bepaal wie dan overneemt als die persoon niet beschikbaar is.
Tijdelijke vervangers hebben grenzen nodig. Een vervanger krijgt alleen goedkeuringsrechten voor een beperkte periode, zoals vakantiedata of gepland verlof. Dat houdt de verantwoordelijkheid duidelijk en voorkomt gevallen waarin iemand goedkeuringsrechten behoudt lang nadat dat niet meer hoort.
Een eenvoudige opzet moet vier dingen beantwoorden: wie is de hoofdgoedkeurder, wie is de back-up, hoe lang kan de vervanger handelen, en wanneer schuift het verzoek verder in de keten.
Escalaties moeten gebaseerd zijn op duidelijke triggers, niet op giswerk. Veelvoorkomende triggers zijn tijd, bedrag, risico of ontbrekende informatie. Bijvoorbeeld: als een inkoopverzoek boven $10.000 24 uur onaanraakbaar blijft, kan het escaleren naar het afdelingshoofd.
Houd het escalatiepad kort. Als mensen een ingewikkeld diagram nodig hebben om te begrijpen wie het verzoek als volgende krijgt, is de regel waarschijnlijk te complex. Eén of twee duidelijke stappen zijn meestal voldoende.
Leg elke beslissing ook vast. Bewaar wie goedkeurde, wie verving, wanneer de overdracht plaatsvond en waarom het verzoek escaleerde. Die geschiedenis is belangrijk wanneer iemand later vraagt waarom een verzoek vertraagd of door een vervanger goedgekeurd is.
Nog één regel is belangrijk: voorkom loops. Een verzoek mag nooit terugstuiteren naar iemand die het al heeft goedgekeurd, of naar een vervanger die voor diezelfde persoon handelde. Controleer de matrix op circulaire paden voordat je applogica bouwt.
Stel je een klein bedrijf voor dat dagelijkse artikelen koopt. Een medewerker dient één inkoopverzoek in met het artikel, bedrag, reden en gewenste datum. De routering wordt bepaald door de regels, niet door wie er toevallig online is.
Als het verzoek $420 is, gaat het direct naar de teamleider. Dat houdt kleine aankopen in beweging. Een verzoek van $3.200 slaat de teamleider over en gaat naar de afdelingsmanager omdat de budgetimpact groter is.
Neem nu een verzoek van $7.800 voor nieuwe apparatuur. De afdelingsmanager beoordeelt het nog steeds, maar dat is niet voldoende. Omdat het bedrag boven $5.000 ligt, moet ook financiën meekijken. Daar helpt een duidelijke matrix: hogere bedragen voegen controle toe zonder giswerk.
Afwezigheden zijn hier ook van belang. Als de afdelingsmanager met verlof is, mag het verzoek niet in limbo blijven. Een benoemde vervanger ontvangt het automatisch en kan in die beperkte periode handelen.
Tijdslimieten moeten even helder zijn. Als niemand binnen twee dagen handelt, escaleert het verzoek naar operations. Operations kan opvolgen, het opnieuw toewijzen of zorgen dat het geen werk blokkeert.
In dit voorbeeld beantwoordt de matrix een paar simpele maar belangrijke vragen: hoeveel wordt er gevraagd, welke rol keurt er op elk bedrag, wanneer wordt financiën erbij gehaald, wie dekt afwezigheden en wat gebeurt er bij gemiste deadlines.
Zodra die antwoorden zijn vastgelegd, wordt het schermontwerp eenvoudig. Het formulier heeft alleen de juiste gegevens nodig en de aanvraagpagina hoeft alleen de huidige goedkeurder, eventuele vervanger en of de escalatieklok loopt te tonen.
Het meeste herwerk start voordat er één scherm is ontworpen. Teams raden het goedkeuringspad, en proberen vervolgens de UI passend te maken voor regels die nooit echt zijn afgesproken.
Een veelvoorkomende fout is het kopiëren van de organisatiestructuur en dat een workflow noemen. Dat oogt misschien netjes, maar echte verzoeken bewegen vaak op basis van bedrag, risico, locatie of type verzoek. Als de matrix dat negeert, hebben schermen later extra velden, extra statussen en onhandige uitzonderingen nodig.
Een ander probleem is het vergeten van speciale gevallen. Dringende verzoeken, gereguleerde aankopen of cross-team verzoeken hebben vaak een andere route nodig. Als die uitzonderingen niet vroeg in kaart zijn gebracht, vragen mensen om handmatige oplossingen en raakt de interface vol met eenmalige opties die iedereen verwarren.
Teams creëren ook problemen wanneer ze twee mensen precies dezelfde rol geven zonder beslissingsregel. Als beiden kunnen goedkeuren, wie doet het dan eerst? Als ze het oneens zijn, wiens beslissing geldt? Zonder dat antwoord stuiteren verzoeken rond en verliest de gebruiker vertrouwen.
Vervangingsregels zijn een ander zwak punt. Een vervanger moet een afwezigheid opvangen, niet stilletjes een tweede eigenaar worden voor altijd. Wanneer tijdelijke dekking en permanente eigendom door elkaar lopen, raken rapporten rommelig en verdwijnt aansprakelijkheid.
Formulieren ontwerpen voordat de routering is vastgesteld leidt tot nog een ronde herwerk. Een formulier kan af lijken, maar zodra de goedkeuringsregels zijn afgerond, ontdek je vaak ontbrekende velden zoals bedragscategorie, afdeling, urgentie of beleidsvlag. Dan moeten lay-out, validatie en meldingen allemaal veranderen.
Een korte realitycheck helpt dit vroeg te ontdekken:
Als één van die antwoorden onduidelijk is, stop dan. Fix de matrix voordat je de schermen afwerkt.
Voordat je een formulier of statusbadge schetst, test je de logica in gewone woorden. Een goede goedkeuringsmatrix moet makkelijk uit te leggen zijn zonder een diagram te openen. Als een manager, finance lead of operations-collega de route niet in ongeveer een minuut kan beschrijven, is het proces nog te vaag voor UI-werk.
Doe een snelle review met echte voorbeelden. Vraag één persoon de volledige route van verzoek tot definitieve beslissing uit te leggen. Controleer dat elke waarschijnlijke uitkomst een benoemde volgende goedkeurder heeft, niet alleen het gelukkige pad. Herschrijf vage drempels als exacte regels zoals "$1.000 en minder" of "meer dan 10% korting." Bevestig dat back-up- en escalatieregels duidelijke tijdslimieten gebruiken zoals "na 24 uur" of "na 2 werkdagen."
Test daarna traceerbaarheid. Later zal iemand vragen waarom een verzoek vertraagd was, wie een uitzondering goedkeurde of wanneer een vervanger insprong. Je proces moet die vragen al kunnen beantwoorden. Tijdstempels, beslissingsgeschiedenis en duidelijke statuswijzigingen zijn geen extra's. Ze maken deel uit van de regels.
Een eenvoudig scenario legt vaak zwakke plekken bloot. Stel je een inkoopverzoek van $4.800 voor dat op vrijdagmiddag binnenkomt terwijl de gebruikelijke goedkeurder afwezig is. Wie krijgt het dan? Hoe lang wacht het systeem voordat het beweegt? Wat gebeurt er als de back-up ook niets doet? Als die antwoorden niet zijn opgeschreven, verbergt de UI verwarring in plaats van die op te lossen.
Als deze checks slagen, wordt schermontwerp veel eenvoudiger. Je raadt niet meer wat de interface moet tonen; je geeft duidelijke regels een passende vorm.
Zodra de regels helder zijn, bouw je het proces voordat je de schermen verfijnt. Begin met de logica, de gegevensvelden en de goedkeuringsstatussen. Als de routering werkt, wordt de interface veel eenvoudiger te ontwerpen. Als de routering nog steeds verandert, verbergen aantrekkelijke schermen alleen de problemen.
Een praktische eerste versie bevat meestal de basis: verzoektype, bedrag, afdeling, huidige goedkeurder, definitieve status en een duidelijke geschiedenis van elke beslissing. Voeg daarna de regels toe die een verzoek verder sturen, naar een back-up goedkeurder sturen of een escalatie triggeren wanneer iemand niet op tijd reageert.
Houd de eerste schermen eenvoudig. Een aanvrager moet kunnen indienen, de status controleren en reageren op vervolgvragen. Een goedkeurder moet kunnen beoordelen, goedkeuren, afwijzen of opnieuw toewijzen. Dat is genoeg om te testen of de workflow in het dagelijks gebruik werkt.
Een logische bouwvolgorde is:
Die gedeelde bron van waarheid blijkt belangrijker dan veel teams verwachten. Als mobiel een andere status toont dan het webpaneel en de backend weer andere drempels volgt, verdwijnt vertrouwen snel.
Als je dit in AppMaster bouwt, maakt een duidelijke matrix de setup veel eenvoudiger. Je kunt eerst de data, bedrijfslogica en goedkeuringsflow modelleren en daarna hetzelfde proces over backend, web en mobiel dragen zonder de regels in verschillende tools te herschrijven.
Gebruik één echt geval voor de eerste test. Voer een daadwerkelijk inkoopverzoek uit met een drempel, een vervangende goedkeurder en een achterstallige escalatie. Let erop waar mensen aarzelen, welke gegevens ze missen en welke statusteksten verwarren.
Verbeter daarna woordkeuze en lay-out. Als het proces met een echt verzoek werkt, zijn de schermen makkelijker te ontwerpen en veel minder geneigd om een week later opnieuw gebouwd te worden.
07 mrt 2026
9 min
07 mrt 20269 min
03 mrt 20268 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
