Het ontwerp van uitzonderingspaden helpt teams om afgewezen verzoeken, ontbrekende documenten en gedeeltelijke goedkeuringen af te handelen voordat herstelwerk het hele proces vertraagt.
De meeste teams beginnen met de schone versie van een workflow. Er komt een verzoek binnen, iemand beoordeelt het en het wordt goedgekeurd. Het lijkt efficiënt, maar het verbergt waar het echte werk gebeurt.
Het happy path is meestal de kortste route. Het formulier is compleet, de bijlagen zijn aanwezig en de beoordelaar weet precies wat te doen. In de praktijk veroorzaakt dat zelden de vertragingen.
Vertragingen beginnen wanneer iets ontbreekt, onduidelijk is, te laat is of slechts deels acceptabel is. Een manager kan het budget goedkeuren maar één post weigeren. De financiële afdeling kan een belastingdocument nodig hebben dat nooit is geüpload. Een supportlead kan een verzoek terugsturen omdat het redenveld te vaag is. Elk van die momenten creëert extra stappen, extra berichten en extra wachttijd.
Als die situaties niet vroeg worden gepland, nemen mensen ad-hoc beslissingen. De ene beoordelaar stuurt een e-mail. De ander laat een opmerking achter in het systeem. Een derde wijst het verzoek af zonder verklaring. De aanvrager blijft raden: moeten ze het probleem verhelpen, opnieuw beginnen of iemand om hulp vragen?
Die verwarring heeft een kostprijs. Het vertraagt de persoon die het verzoek indiende, de beoordelaar en iedereen die erbij betrokken wordt om uit te leggen wat er gebeurde. Een workflow die op een whiteboard eenvoudig leek, verandert in vervolgchats, dubbele inzendingen en handmatige overdrachten.
Een basisgoedkeuringsstroom is makkelijk te schetsen:
De echte versie is lastiger. Wat als een document ontbreekt? Wat als slechts een deel van het verzoek wordt goedgekeurd? Wat als de beoordelaar het afwijst maar de gebruiker het kan herstellen? Dit zijn geen ongewone gevallen. Voor veel teams zijn het de normale gevallen.
Daarom verdient ontwerp van uitzonderingspaden aandacht voordat schermen worden getekend en statussen worden benoemd. Het uitzonderingspad bepaalt wat er gebeurt wanneer de realiteit het plan onderbreekt — en dat gebeurt vaak.
Als je een interne goedkeuringsapp bouwt, ook in een no-code platform zoals AppMaster, verdienen afgewezen en onvolledige gevallen net zoveel zorg als de goedgekeurde cases. Ze bepalen welke berichten mensen zien, welke acties ze kunnen ondernemen en of de workflow mensen helpt herstellen of vast laat zitten.
Een happy path laat intentie zien. Uitzonderingspaden laten zien of het proces bestand is tegen echt gebruik.
Een uitzonderingspad is wat er gebeurt wanneer een verzoek niet op de normale manier verder kan. Het is geen zeldzaam randgeval. Het is het deel van het proces dat omgaat met rommel uit de echte wereld: een verzoek wordt geweigerd, een formulier is onvolledig, één onderdeel is goedgekeurd maar een ander niet, of het werk blijft simpelweg vastzitten.
Een duidelijk uitzonderingspad gebruikt eenvoudige taal. In plaats van een vage status als "Failed", zeg wat er gebeurde: "Afgewezen omdat het budget de limiet overschrijdt" of "Wachten op ID-document." Mensen moeten weten wat er mis is, wie moet handelen en wat er daarna gebeurt.
De meeste workflows haperen op een paar voorspelbare manieren:
Ontbrekende informatie is een van de meest voorkomende problemen. Stel je een leveranciersaanmeldingsformulier voor dat een belastingdocument en een bankrekeningnummer nodig heeft. Als een van beide ontbreekt, zou het systeem niet simpelweg moeten stoppen. Het zou het verzoek als onvolledig moeten markeren, precies moeten tonen wat ontbreekt en het terug moeten sturen naar de juiste persoon.
Gedeeltelijke goedkeuringen zijn net zo belangrijk. Denk aan een reisaanvraag voor vlucht, hotel en dagvergoeding. De manager keurt vlucht en hotel goed maar vermindert het dagbudget. Het proces heeft dan regels nodig. Accepteert de werknemer de wijziging, wijzigt hij het verzoek of annuleert hij de reis?
Stagnaties zijn ook van belang. Een verzoek kan onbeheerd blijven omdat de toegewezen beoordelaar het bedrijf heeft verlaten, het team geen back-upapprover heeft ingesteld, of het proces een stap bereikt zonder volgende eigenaar. Technisch is er niets kapot, maar het verzoek kan toch niet bewegen.
Als je deze paden niet vroeg ontwerpt, handelen mensen ze af via e-mail, chat of spreadsheetnotities. Al snel weet niemand meer welke versie definitief is.
Neem een reisaanvraag van een salesmanager die naar een tweedaagse conferentie wil. Op papier lijkt de flow eenvoudig: de werknemer vult de reisdata, geschatte kosten en reden in. De manager keurt het goed, financiën bevestigt het budget en de reis gaat naar boeking.
Die flow is netjes, maar ook onvolledig.
Breek nu hetzelfde verzoek. De werknemer uploadt de vluchtinschatting en het conferentieticket maar vergeet de hotelofferte. Als het systeem alleen "submitted" en "approved" kent, raken mensen snel vast. Financiën ziet mogelijk een onvolledig verzoek, de manager denkt dat het klaar is en de werknemer weet niet wat er ontbreekt.
Een betere flow geeft dat verzoek een eigen status, zoals "Waiting for document" of "Needs update." De werknemer ziet een duidelijke boodschap: "Voeg hotelofferte toe voordat dit verzoek naar financiën kan." De manager hoeft niet het hele reisverzoek te weigeren alleen om één bestand op te vragen.
Voeg nu een tweede probleem toe. De manager gaat akkoord dat de werknemer mag reizen, maar niet voor het volledige bedrag. Ze keuren de vlucht en één hotelovernachting goed, maar wijzen de extra workshopkosten en de tweede hotelnacht af.
Hier ontdekken veel teams dat ze geen gedeeltelijk goedkeuringsproces hebben.
Als de workflow niet toestaat slechts een deel van het verzoek goed te keuren, beginnen mensen workarounds te gebruiken. Ze wijzen het hele verzoek af en vragen de werknemer het opnieuw in te dienen. Of financiën keurt per ongeluk het volledige bedrag goed omdat het systeem slechts één ja-of-nee-beslissing opslaat.
Een helderder model houdt elk kostenitem bij, of op z’n minst het goedgekeurde totaal. Een verzoek kan bijvoorbeeld tonen:
Dat enige voorbeeld laat zien waarom fouten in goedkeuringsworkflows vaak voortkomen uit ontbrekende regels, niet uit onoplettendheid. Als je die regels vóór het ontwerpen van schermen bepaalt, wordt de rest van de workflow veel betrouwbaarder.
Een goede manier om een workflow te verbeteren is te veronderstellen dat het verzoek niet zonder problemen doorloopt. Die ene verschuiving verbetert de kwaliteit van het ontwerp snel.
Begin met de rommelige gevallen: het formulier is onvolledig, het beleid is onduidelijk, de goedkeurder is afwezig, of slechts een deel van het verzoek moet verder worden verwerkt. De meeste teams kunnen deze groeperen in drie hoofdpatronen:
Dat houdt het werk beheersbaar. In plaats van voor elk randgeval een nieuw antwoord te verzinnen, definieer je een kleine set patronen en pas je die op elk type verzoek toe.
Werk in deze volgorde.
Eerst: lijst elk punt waar het verzoek kan stoppen. Denk aan ontbrekende documenten, ongeldige waarden, beleidsinbreuken, verlopen deadlines, dubbele inzendingen en handmatige beoordelingen. Als het verzoek kan wachten, falen of terugkeren naar de afzender, noteer het.
Vervolgens: beslis wat er in elk geval gebeurt. Beantwoord voor elke uitzondering vier eenvoudige vragen:
Bijvoorbeeld: stel dat een werknemer een onkostendeclaratie van $600 indient. De hotelbon ontbreekt en één maaltijd overschrijdt het beleid. Als je alleen het happy path ontwerpt, zit het verzoek ofwel vast of wordt het als één groot blok afgewezen. Als je uitzonderingen eerst ontwerpt, kan het systeem de claim pauzeren voor de ontbrekende bon, de werknemer informeren met een duidelijke boodschap en de toegestane items voorwaardelijk goedkeuren.
Daarom zijn regels voor gedeeltelijke goedkeuring belangrijk. Je moet beslissen of het goedgekeurde bedrag nu kan doorstromen, of de rest in de wacht blijft en of de aanvrager alleen het betwiste deel mag bewerken of de hele claim opnieuw moet indienen.
Als je het proces in AppMaster bouwt, is dit het punt om die vertakkingen in de businesslogica in kaart te brengen voordat je de UI afwerkt. Het is veel makkelijker om vertrouwen in een workflow te hebben wanneer reject, return-for-edits en approve-with-conditions als aparte paden worden behandeld in plaats van verborgen achter één vage status.
Test tenslotte één echt scenario van begin tot eind. Gebruik echte bedragen, één concreet documentgat en één beleidsafwijking. Als iemand die de flow leest niet binnen een minuut kan zeggen wat er daarna gebeurt, is het ontwerp nog te vaag.
Schermen voelen concreet aan, dus teams beginnen vaak daarmee. Ze schetsen knoppen, formulieren en dashboards voordat ze het eens zijn over de regels. Dat veroorzaakt meestal later problemen, omdat de interface beslissingen verbergt die niemand eigenlijk heeft genomen.
Een betere volgorde is simpel: definieer de statussen, overdrachten, deadlines en bewijsstukken die nodig zijn om verder te gaan. Bouw dan de schermen daaromheen.
Uitzonderingspadontwerp wordt veel eenvoudiger wanneer de regels klein en duidelijk zijn. Als een verzoek kan worden goedgekeurd, afgewezen, teruggestuurd voor aanpassingen of deels goedgekeurd, moeten die statussen eenvoudige namen krijgen die maar één ding betekenen. Vermijd bijna-duplicaten zoals "returned", "reopened" en "needs changes" tenzij ze echt anders werken.
Neem een aankoopverzoek. Een manager opent het en merkt dat de offerte ontbreekt. Als het team niet heeft besloten wat er daarna gebeurt, improviseren mensen. De ene manager wijst het af. Een ander laat het in afwachting staan. Een derde stuurt een chatbericht en verandert niets in het systeem. Al snel vertrouwt niemand de status meer.
Schrijf de regel eerst op. Als een offerte ontbreekt, gaat het verzoek naar "Needs documents." De aanvrager is verantwoordelijk voor de volgende stap. Het verzoek blijft daar vijf werkdagen staan. Als er niets binnenkomt, verandert het in "Expired" en is een nieuwe inzending vereist.
Die ene regel bepaalt het product beter dan een mockup kan. Nu weet je wat de gebruiker moet zien, welke herinnering je moet sturen en welke historie je moet bewaren.
Een praktische set regels moet vier vragen beantwoorden:
Gedeeltelijke goedkeuringen hebben dezelfde zorg nodig. Als reizen is goedgekeurd maar hotelkosten niet, bewerkt de aanvrager dan hetzelfde record of maakt hij een nieuw verzoek? Beoordeelt financiën alleen het gewijzigde onderdeel of alles opnieuw? Als dat niet vroeg wordt besloten, ziet het scherm er misschien netjes uit terwijl het proces erachter rommelig blijft.
Wanneer teams eerst de regels vastleggen, wordt de interface eenvoudiger. Belangrijker: gebruikers weten precies wat ze daarna moeten doen, zelfs als het antwoord is "nog niet goedgekeurd."
Een slecht uitzonderingsbericht vertraagt alles. Mensen moeten niet alleen weten dat iets misging. Ze moeten weten wat er gebeurde, wat het beïnvloedt en wat de volgende stap is.
Hier wordt het ontwerp echt relevant voor gebruikers. Je interne regels kunnen duidelijk zijn, maar als het scherm alleen "Error" of "Pending review" zegt, gaan mensen gissen, sturen ze de verkeerde bestanden opnieuw of vragen ze support om hulp.
Neem een voorbeeld van leveranciersgoedkeuring. Een gebruiker dient een formulier in met een belastingdocument, bankgegevens en verzekeringsbewijs. De bankgegevens zijn in orde, het belastingdocument is verouderd en het verzekeringsbewijs ontbreekt. Als het systeem alleen "Request not approved" toont, heeft de gebruiker geen duidelijke vervolgactie.
Een beter bericht luidt: "Uw bankgegevens zijn goedgekeurd. We hebben nog een bijgewerkt belastingdocument en verzekeringsbewijs nodig voordat de definitieve goedkeuring kan plaatsvinden." Die ene zin bespaart tijd omdat het onderscheid maakt tussen wat klaar is en wat nog moet gebeuren.
Goede berichten beantwoorden meestal vier kleine vragen:
Dat laatste deel is belangrijk. Mensen maken de taak sneller af wanneer de volgende stap duidelijk is. "Upload het ontbrekende bestand en dien opnieuw in" is veel beter dan "Action required."
Vage labels zorgen ook voor onzekerheid. "Pending review" kan wachten op een persoon, op ontbrekende data of op een interne controle betekenen. Als je de reden kent, zeg het dan duidelijk. "Waiting for manager approval" en "Waiting for proof of address" zijn totaal verschillende situaties en mogen er niet hetzelfde uitzien.
Als een proces gedeeltelijke goedkeuring toestaat, toon dat dan duidelijk in de status zelf. Een korte uitsplitsing werkt vaak beter dan één label:
Nu kan de gebruiker alleen repareren wat nodig is. Ze hoeven niet opnieuw te beginnen.
Dit is ook het punt waar het opnieuw indienen makkelijk vindbaar moet zijn. Zet de volgende actie dichtbij het bericht, niet op een ander scherm. Als je de flow in AppMaster bouwt, helpt het om de zichtbare statustekst precies aan de businessprocessen te koppelen zodat de app zegt wat de workflow daadwerkelijk doet.
Goede berichten verminderen supporttickets, versnellen goedkeuringen en laten het proces eerlijk aanvoelen. Mensen accepteren een afwijzing eerder als ze het begrijpen.
De meeste dubbelingen beginnen met één verkeerde aanname: het normale pad is het belangrijkste om te ontwerpen. Teams tekenen "verzoek ingediend, goedgekeurd, voltooid" en stoppen daar. Dan verschijnt de realiteit: een bestand ontbreekt, een manager wil wijzigingen, of slechts een deel van het verzoek kan doorgaan.
Die kloof creëert snel extra werk. Mensen verzinnen handmatige fixes, sturen zijberichten en hernoemen statussen onderweg. Een paar weken later vertrouwt niemand de workflow omdat elke uitzondering als speciaal geval wordt behandeld.
Een veelgemaakte fout is het ideale pad als product behandelen en alles daarbuiten als schoonmaak. Stel je een onkostendeclaratie voor die een bon, afdelingsgoedkeuring en financiële controle nodig heeft. Als de bon ontbreekt, pauzeert het verzoek dan, gaat het terug naar de medewerker of wordt het afgewezen? Als die regel niet duidelijk is vanaf het begin, plakt het team later vaak oplossingen aan elkaar met e-mails en opmerkingen.
Verwarrende statusteksten leiden tot nog meer werk. Labels als "In review 2" of "Pending action" klinken onschuldig, maar ze dwingen mensen te raden wat er daarna gebeurt. Duidelijke namen verminderen fouten omdat ze het probleem, de eigenaar, de uitkomst of de volgende stap tonen.
Eigenaarschap is nog zo'n plek waar workflows breken. Een verzoek mag nooit in een status blijven die bij niemand hoort. Als een zaak wacht, moet iemand verantwoordelijk zijn om het vooruit te helpen, meer informatie te vragen of het te sluiten. Anders stapelen stille vertragingen zich op en denken gebruikers dat het systeem hun verzoek heeft verloren.
Gedeeltelijke goedkeuring wordt vaak slecht afgehandeld. Teams behandelen het als een volledige afwijzing omdat dat eenvoudiger lijkt. Maar die uitkomsten betekenen iets anders. Als een reisverzoek vlucht, hotel en maaltijden vraagt, kan financiën vlucht en hotel goedkeuren maar maaltijden weigeren. Die situatie heeft een eigen pad, eigen bericht en vaak een eigen vervolgactie nodig.
Wanneer gedeeltelijke goedkeuringen samen met afwijzingen worden gevoegd, dienen mensen het hele verzoek opnieuw in, dupliceren documenten en starten reviews opnieuw die al gedaan waren. Dat is pure dubbeling.
Een eenvoudige test helpt: lees elke non-happy-path status en vraag jezelf af "Wie is eigenaar, wat ziet de gebruiker en wat gebeurt daarna?" Als het antwoord vaag is, zal het proces waarschijnlijk op diezelfde plek breken.
Voordat je schermen bouwt of iets automatiseert, doe nog één ronde over de rommelige gevallen. Goed uitzonderingspadontwerp is vaak slechts een paar duidelijke beslissingen die vroeg genomen worden, voordat verwarring in dubbel werk verandert.
Als een verzoek wordt afgewezen, gepauzeerd of slechts deels goedgekeurd, moet altijd duidelijk zijn wie weet wat er daarna gebeurt, wie het doet en welke informatie nog ontbreekt.
Gebruik deze snelle controle voor elke uitzondering in je proces:
Voer dan één eenvoudige test uit. Geef het proces aan iemand die niet aan het ontwerp heeft meegewerkt. Geef die persoon een afgewezen verzoek en een verzoek met één ontbrekend document. Als die persoon niet binnen een minuut kan vertellen wat te doen, is het proces nog te vaag.
Een klein voorbeeld maakt het duidelijk. Stel dat een manager een softwareverzoek goedkeurt maar het hardwaredeel afkeurt. Als de status alleen "Partially approved" zegt, kan de werknemer aannemen dat alles kan doorgaan. Een betere status zegt precies wat is goedgekeurd, wat is afgewezen en of de werknemer het ontbrekende deel kan herindienen.
Als je die regels in een werkende interne app wilt omzetten, breng dan eerst de uitzonderingsstatussen in kaart en bouw daarna het happy path. In AppMaster betekent dit het definiëren van statussen, businessregels en verplichte velden voordat je je zorgen maakt over nette schermen. Het is een praktische manier om no-code applicaties te bouwen die echt werk afhandelen, niet alleen de ideale versie daarvan.
De volgende stap is simpel: lijst je vijf belangrijkste uitzonderingen, wijs voor elk een eigenaar toe en schrijf het bericht dat de gebruiker zou moeten zien. Als die drie onderdelen duidelijk zijn, wordt het bouwen meestal veel eenvoudiger.
Why isn't the happy path enough for an approval workflow?Omdat echte vertragingen meestal ontstaan wanneer iets ontbreekt, onduidelijk is, te laat komt of slechts deels wordt goedgekeurd. Als je alleen het schone proces ontwerpt, lossen mensen problemen op via chat, e-mail en handmatige workarounds.
Which exception paths should I design first?Begin met de gevallen die het vaakst voorkomen: afwijzing, ontbrekende informatie en gedeeltelijke goedkeuring. Voeg vervolgens stalls toe, zoals een verzoek zonder eigenaar of zonder een gedefinieerde volgende stap.
What statuses should an approval app have?Gebruik een kleine set duidelijke statussen die elk één ding betekenen. Een praktisch uitgangspunt is: approved, rejected, needs documents, needs changes, partially approved, en expired voor deadlines.
How should the process handle missing documents?De gebruiker moet precies zien wat er ontbreekt en wat de volgende stap is. Een goed uitgangspunt is om het verzoek naar een status als "Needs documents" te verplaatsen, de ontbrekende items duidelijk te benoemen en het terug te sturen naar de juiste persoon in plaats van het volledig af te wijzen.
How do I handle partial approvals without creating rework?Behandel het als een eigen pad, niet als een volledige afwijzing. Laat zien wat is goedgekeurd, wat is afgewezen, het nieuwe goedgekeurde totaalbedrag indien relevant, en of de aanvrager de wijziging kan accepteren, het verzoek kan aanpassen of alleen het betwiste deel kan herindienen.
What should happen when a request gets stuck with no action?Geef elke wachtende status een eigenaar en een tijdsregel. Als een reviewer afwezig is of een verzoek te lang blijft liggen, moet de workflow escaleren, opnieuw toewijzen of verlopen in plaats van vast te blijven zitten.
What makes an exception message actually useful?Houd ze eenvoudig en concreet. Zeg wat er afgewezen of ontbreekt, wat al is geaccepteerd, wat de gebruiker moet doen en wat er gebeurt nadat ze opnieuw indienen.
Should I design the screens first or the workflow rules first?Bepaal eerst de regels. Stem statussen, eigenaren, deadlines, verplichte bestanden en volgende acties af voordat je knoppen of dashboards ontwerpt, want de interface moet beslissingen weerspiegelen die al duidelijk zijn.
How can I test whether my exception path is clear enough?Doorloop één realistisch scenario van begin tot eind met echte cijfers en één of twee problemen, zoals een ontbrekend bestand of een beleidsafwijking. Als iemand die het proces niet kent in minder dan een minuut niet kan zeggen wat te doen, is het proces nog te vaag.
How would I build this kind of workflow in AppMaster?Breng de uitzonderingsstatussen in je businesslogica in kaart voordat je de UI afwerkt. In AppMaster betekent dat het definiëren van statussen, verplichte velden, eigenaars en takken zoals reject, return for edits en approve with conditions eerst.
10 mrt 2026
6 min
08 mrt 202611 min
07 mrt 202610 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
