Das Design von Ausnahmepfaden hilft Teams, abgelehnte Anträge, fehlende Dokumente und Teilgenehmigungen zu bearbeiten, bevor Nacharbeit den gesamten Prozess verlangsamt.
Die meisten Teams beginnen mit der sauberen Version eines Workflows. Ein Antrag kommt rein, jemand prüft ihn und er wird genehmigt. Das wirkt effizient, aber es verdeckt, wo die eigentliche Arbeit passiert.
Der ideale Ablauf ist normalerweise der kürzeste Weg. Das Formular ist vollständig, die Anhänge sind da und die prüfende Person weiß genau, was zu tun ist. In der Praxis verursacht das selten Verzögerungen.
Verzögerungen beginnen, wenn etwas fehlt, unklar ist, zu spät ist oder nur teilweise akzeptabel ist. Ein Manager kann das Budget genehmigen, aber einen Posten ablehnen. Die Buchhaltung braucht vielleicht ein Steuerdokument, das nie hochgeladen wurde. Ein Support-Leiter schickt den Antrag zurück, weil das Feld für die Begründung zu vage ist. Jeder dieser Momente erzeugt zusätzliche Schritte, zusätzliche Nachrichten und zusätzliches Warten.
Wer diese Situationen nicht früh plant, lässt Leute ad hoc entscheiden. Ein Prüfer sendet eine E-Mail. Ein anderer hinterlässt einen Kommentar im Tool. Ein dritter lehnt den Antrag ohne Erklärung ab. Der Antragstellende bleibt ratlos: Soll er den Fehler beheben, neu anfangen oder jemanden um Hilfe bitten?
Diese Verwirrung hat Kosten. Sie verlangsamt die Person, die den Antrag eingereicht hat, die prüfende Person und alle, die zur Klärung hinzugezogen werden. Ein Workflow, der auf dem Whiteboard einfach aussah, verwandelt sich in Nachgespräche, doppelte Einreichungen und manuelle Übergaben.
Ein einfaches Genehmigungsdiagramm ist leicht zu skizzieren:
Die reale Version ist komplizierter. Was, wenn ein Dokument fehlt? Was, wenn nur ein Teil des Antrags genehmigt wird? Was, wenn der Prüfer ablehnt, der Nutzer aber den Fehler beheben kann? Das sind keine ungewöhnlichen Fälle. Für viele Teams sind sie die Normalität.
Darum verdient das Design von Ausnahmepfaden Aufmerksamkeit, bevor Bildschirme gezeichnet und Status benannt werden. Der Ausnahmepfad definiert, was passiert, wenn die Realität den Plan unterbricht — und die Realität tut das oft.
Wenn du eine interne Genehmigungs-App baust, auch in einer No-Code-Plattform wie AppMaster, brauchen abgelehnte und unvollständige Fälle genauso viel Sorgfalt wie der genehmigte Fall. Sie bestimmen die Nachrichten, die Menschen sehen, die Aktionen, die sie als Nächstes ausführen können, und ob der Workflow Menschen helfen kann, wieder auf Kurs zu kommen, oder sie stecken lässt.
Ein idealer Ablauf zeigt die Absicht. Ausnahmepfade zeigen, ob der Prozess im echten Betrieb überlebt.
Ein Ausnahmepfad ist das, was passiert, wenn ein Antrag nicht auf normalem Weg weiterkommt. Es ist kein seltener Randfall. Es ist der Teil des Prozesses, der die reale Unordnung handhabt: ein Antrag wird abgelehnt, ein Formular ist unvollständig, ein Teil ist genehmigt, ein anderer nicht, oder die Arbeit bleibt einfach stecken.
Ein klarer Ausnahmepfad verwendet einfache Sprache. Statt eines vagen Status wie „Fehlgeschlagen“ sage, was passiert ist: „Abgelehnt, weil das Budget überschritten ist“ oder „Wartet auf Ausweisdokument“. Die Leute sollten wissen, was falsch ist, wer handeln muss und was als Nächstes passiert.
Die meisten Workflows scheitern auf einige vorhersehbare Arten:
Fehlende Informationen sind eines der häufigsten Probleme. Stell dir ein Lieferanten-Onboarding-Formular vor, das ein Steuerdokument und eine Kontonummer braucht. Wenn eines davon fehlt, sollte das System nicht einfach stoppen. Es sollte den Antrag als unvollständig markieren, genau zeigen, was fehlt, und ihn an die richtige Person zurücksenden.
Teilgenehmigungen sind genauso wichtig. Denk an eine Reiseanfrage für Flug, Hotel und Verpflegung. Der Manager genehmigt Flug und Hotel, kürzt aber das Verpflegungsbudget. Der Prozess braucht jetzt Regeln. Akzeptiert der Mitarbeitende die Änderung, aktualisiert er den Antrag oder storniert er die Reise?
Stillstand ist ebenfalls relevant. Ein Antrag kann unbeachtet liegen, weil der zugewiesene Prüfer das Unternehmen verlassen hat, das Team keinen Stellvertreter gesetzt hat oder der Prozess an einen Schritt kommt, der keinen nächsten Besitzer hat. Technisch ist nichts kaputt, aber der Antrag kann trotzdem nicht weiter.
Wenn du diese Pfade nicht früh entwirfst, handhaben Leute sie per E-Mail, Chat oder Notizen in Tabellen. Bald weiß niemand mehr, welche Version final ist.
Nimm eine Reiseanfrage eines Vertriebsleiters für eine zweitägige Konferenz. Auf dem Papier sieht der Ablauf einfach aus: der Mitarbeitende trägt Reisedaten, geschätzte Kosten und Reisezweck ein. Der Manager genehmigt, die Buchhaltung bestätigt das Budget und die Reise geht zur Buchung.
Dieser Ablauf ist sauber, aber auch unvollständig.
Jetzt brich denselben Antrag: Der Mitarbeitende lädt die Flugkostenschätzung und das Konferenzticket hoch, vergisst aber das Hotelangebot. Wenn das System nur „eingereicht“ und „genehmigt“ kennt, bleiben die Leute schnell hängen. Die Buchhaltung sieht möglicherweise einen unvollständigen Antrag, der Manager denkt, er sei fertig, und der Mitarbeitende weiß nicht, was fehlt.
Ein besserer Ablauf gibt diesem Antrag einen eigenen Status, wie „Wartet auf Dokument“ oder „Benötigt Aktualisierung“. Der Mitarbeitende sollte eine klare Nachricht sehen: „Füge das Hotelangebot hinzu, bevor dieser Antrag an die Buchhaltung gehen kann.“ Der Manager müsste nicht den gesamten Antrag ablehnen, nur weil eine Datei fehlt.
Fügen wir ein zweites Problem hinzu. Der Manager ist grundsätzlich dafür, dass die Reise stattfindet, aber nicht zum vollen Betrag. Er genehmigt Flug und eine Hotelnacht, lehnt aber die Workshop-Gebühr und die zweite Hotelnacht ab.
Hier merken viele Teams, dass sie keinen Partially-Approval-Prozess haben.
Wenn der Workflow nicht nur Teile eines Antrags genehmigen kann, greifen Menschen zu Workarounds. Sie lehnen vielleicht den ganzen Antrag ab und bitten den Mitarbeitenden, ihn neu einzureichen. Oder die Buchhaltung genehmigt aus Versehen den vollen Betrag, weil das System nur eine Ja-Nein-Entscheidung speichert.
Ein klareres Modell verfolgt jede Kostenposition oder zumindest den genehmigten Gesamtbetrag. Ein Antrag könnte anzeigen:
Dieses eine Beispiel zeigt, warum Fehler im Genehmigungs-Workflow oft aus fehlenden Regeln entstehen und nicht aus Nachlässigkeit. Definiert man diese Regeln, bevor man Bildschirme entwirft, wird der Rest des Workflows viel vertrauenswürdiger.
Eine einfache Möglichkeit, einen Workflow zu verbessern, ist anzunehmen, dass der Antrag nicht sauber durchläuft. Diese eine Änderung hebt die Qualität des Designs schnell.
Beginne mit den unordentlichen Fällen: das Formular ist unvollständig, die Richtline ist unklar, der Entscheider fehlt oder nur ein Teil des Antrags soll weiterlaufen. Die meisten Teams können diese in drei Muster zusammenfassen:
Das hält die Arbeit überschaubar. Anstatt für jeden Randfall eine neue Lösung zu erfinden, definierst du eine kleine Menge von Mustern und wendest sie auf jeden Antragstyp an.
Arbeite in dieser Reihenfolge.
Listen zuerst jeden Punkt auf, an dem der Antrag stoppen kann. Denke an fehlende Dokumente, ungültige Werte, Policy-Verstöße, abgelaufene Fristen, doppelte Einreichungen und manuelle Prüfungen. Wenn ein Antrag warten, fehlschlagen oder zum Absender zurückgehen kann, schreib es auf.
Als Nächstes entscheide, was in jedem Fall passiert. Beantworte für jede Ausnahme vier einfache Fragen:
Zum Beispiel: Ein Mitarbeitender reicht eine Reisekostenabrechnung über $600 ein. Der Hotelbeleg fehlt und eine Mahlzeit überschreitet die Richtlinie. Wenn du nur den idealen Ablauf entwirfst, bleibt der Antrag entweder stecken oder wird pauschal abgelehnt. Entwirfst du die Ausnahmen zuerst, kann das System die Abrechnung für den fehlenden Beleg pausieren, den Mitarbeitenden mit einer klaren Nachricht benachrichtigen und erlauben, die bereits zulässigen Posten bedingt zu genehmigen.
Hier werden Teilgenehmigungsregeln wichtig. Du musst entscheiden, ob der genehmigte Betrag jetzt weiterverarbeitet werden darf, ob der Rest in Halteposition bleibt und ob der Antragsteller nur den strittigen Teil bearbeiten darf oder den gesamten Antrag neu einreichen muss.
Wenn du den Prozess in AppMaster baust, ist das der Punkt, an dem du diese Verzweigungen in der Geschäftslogik abbildest, bevor du die UI polierst. Es ist viel einfacher, einem Workflow zu vertrauen, wenn Ablehnen, Zurück zur Bearbeitung und Bedingt genehmigen als getrennte Pfade behandelt werden, statt hinter einem vagen Status zu verstecken.
Teste abschließend ein echtes Szenario von Anfang bis Ende. Nutze reale Zahlen, eine echte Dokumentlücke und eine Policy-Ausnahme. Wenn eine Person den Ablauf nicht in unter einer Minute erklären kann, ist das Design noch zu vage.
Bildschirme wirken konkret, deshalb fangen Teams oft dort an. Sie skizzieren Buttons, Formulare und Dashboards, bevor sie sich auf Regeln geeinigt haben. Das erzeugt später meist Probleme, weil die Oberfläche Entscheidungen verdeckt, die niemand wirklich getroffen hat.
Eine bessere Reihenfolge ist simpel: definiere die Zustände, Übergaben, Fristen und Nachweise, die zum Weiterkommen nötig sind. Baue dann die Bildschirme darum herum.
Das Design von Ausnahmepfaden wird viel einfacher, wenn der Regelkatalog klein und klar ist. Wenn ein Antrag genehmigt, abgelehnt, zur Überarbeitung zurückgeschickt oder teilweise genehmigt werden kann, brauchen diese Zustände eindeutige Namen, die nur eine Bedeutung haben. Vermeide nahe Duplikate wie „Zurückgesandt“, „Wieder geöffnet“ und „Benötigt Änderungen“, außer sie verhalten sich wirklich unterschiedlich.
Nimm einen Beschaffungsantrag. Ein Manager öffnet ihn und bemerkt, dass das Angebot fehlt. Hat das Team nicht entschieden, was dann passiert, improvisieren die Leute. Der eine Manager lehnt ab. Ein anderer lässt ihn offen. Der dritte sendet eine Chat-Nachricht und ändert nichts im System. Bald vertraut niemand mehr dem Status.
Schreib zuerst die Regel. Wenn ein Angebot fehlt, geht der Antrag auf „Benötigt Dokumente“. Der Antragstellende ist für den nächsten Schritt verantwortlich. Der Antrag bleibt dort fünf Werktage. Kommt nichts, wechselt er zu „Abgelaufen“ und eine neue Einreichung ist nötig.
Diese eine Regel prägt das Produkt mehr als ein Mockup. Jetzt weißt du, was der Nutzer sehen soll, welche Erinnerung zu senden ist und welche Historie zu speichern ist.
Ein praktischer Regelkatalog beantwortet vier Fragen:
Teilgenehmigungen brauchen die gleiche Sorgfalt. Wenn die Reise genehmigt ist, aber die Hotelkosten nicht, bearbeitet der Antragsteller denselben Eintrag oder erstellt er einen neuen? Prüft die Buchhaltung nur den geänderten Teil oder alles erneut? Ist das nicht früh entschieden, wirkt der Screen aufgeräumt, während der Prozess dahinter chaotisch bleibt.
Wenn Teams die Regeln zuerst festlegen, wird die Oberfläche einfacher. Wichtiger: Nutzer wissen genau, was als Nächstes zu tun ist, auch wenn die Antwort „noch nicht genehmigt“ lautet.
Eine schlechte Ausnahme-Nachricht verlangsamt alles. Menschen müssen nicht nur wissen, dass etwas fehlgeschlagen ist. Sie müssen wissen, was passiert ist, was betroffen ist und was als Nächstes zu tun ist.
Hier wird das Design für Anwender wirklich sichtbar. Deine internen Regeln mögen klar sein, aber sagt der Bildschirm nur „Fehler“ oder „In Prüfung“, raten die Leute, senden falsche Dateien erneut oder fragen den Support.
Nimm ein Lieferantenfreigabe-Beispiel. Ein Nutzer reicht ein Formular mit Steuerdokument, Bankdaten und Versicherungsnachweis ein. Die Bankdaten sind in Ordnung, das Steuerdokument veraltet und der Versicherungsnachweis fehlt. Zeigt das System nur „Antrag nicht genehmigt“, hat der Nutzer keinen klaren nächsten Schritt.
Eine bessere Nachricht lautet: „Ihre Bankdaten wurden genehmigt. Wir benötigen noch ein aktuelles Steuerdokument und den Versicherungsnachweis, bevor die endgültige Genehmigung erfolgen kann.“ Dieser Satz spart Zeit, weil er trennt, was erledigt ist, von dem, was noch fehlt.
Gute Nachrichten beantworten meist vier kleine Fragen:
Letzteres ist wichtig. Menschen erledigen Aufgaben eher, wenn der nächste Schritt offensichtlich ist. „Lade die fehlende Datei hoch und reiche erneut ein“ ist viel besser als „Handlung erforderlich“.
Vage Labels erzeugen zudem Unsicherheit. „In Prüfung“ kann bedeuten, dass auf eine Person gewartet wird, Daten fehlen oder eine interne Prüfung läuft. Wenn du den Grund kennst, sag ihn klar: „Wartet auf Manager-Genehmigung“ und „Wartet auf Adressnachweis“ sind verschiedene Situationen und sollten nicht gleich aussehen.
Erlaubt der Prozess Teilgenehmigungen, zeige das klar im Status selbst. Eine kurze Aufschlüsselung funktioniert oft besser als ein einzelnes Label:
So kann der Nutzer nur das beheben, was wichtig ist. Ein kompletter Neustart ist nicht nötig.
Auch das erneute Einreichen sollte leicht zu finden sein. Platziere die nächste Aktion in der Nähe der Nachricht, nicht auf einem separaten Bildschirm. Wenn du den Flow in AppMaster baust, hilft es, den benutzerseitigen Statustext an die tatsächlichen Geschäftsprozesszustände anzupassen, sodass die App genau sagt, was der Workflow gerade tut.
Gute Nachrichten reduzieren Support-Tickets, beschleunigen Genehmigungen und lassen den Prozess fair wirken. Menschen akzeptieren eine Ablehnung eher, wenn sie sie verstehen.
Die meisten Nacharbeiten beginnen mit einer falschen Annahme: der normale Pfad ist das Hauptaugenmerk. Teams kartieren Antrag eingereicht, genehmigt, abgeschlossen und stoppen dort. Dann kommt die Realität: eine Datei fehlt, ein Manager will Änderungen oder nur ein Teil des Antrags kann weiter.
Diese Lücke erzeugt schnell zusätzliche Arbeit. Leute erfinden manuelle Lösungen, senden Neben-Nachrichten und benennen Status nach Gutdünken um. Nach wenigen Wochen vertraut niemand mehr dem Workflow, weil jede Ausnahme wie ein Spezialfall behandelt wird.
Ein häufiger Fehler ist, den idealen Ablauf als Produkt zu betrachten und alles andere als Aufräumarbeit. Stell dir eine Spesenabrechnung vor, die einen Beleg, die Abteilungsfreigabe und die Buchhaltungsprüfung braucht. Fehlt der Beleg, pausiert der Antrag, geht er an den Mitarbeitenden zurück oder wird er abgelehnt? Wenn diese Regel nicht von Anfang an klar ist, patcht das Team später mit E-Mails und Kommentaren.
Verwirrende Statusnamen verursachen weitere Nacharbeit. Labels wie „In Prüfung 2“ oder „Handlung erforderlich“ klingen harmlos, zwingen aber die Menschen zu raten, was als Nächstes passiert. Klare Namen reduzieren Fehler, weil sie das Problem, den Besitzer, das Ergebnis oder den nächsten Schritt zeigen.
Verantwortung ist ein weiterer Knackpunkt. Ein Antrag sollte nie in einem Status liegen, der niemandem gehört. Wenn ein Fall wartet, muss jemand verantwortlich sein, ihn voranzutreiben, mehr Informationen anzufordern oder ihn zu schließen. Ansonsten häufen sich stille Verzögerungen und Nutzer nehmen an, das System habe ihren Antrag verloren.
Teilgenehmigungen werden oft schlecht gehandhabt. Teams behandeln sie wie eine volle Ablehnung, weil das einfacher erscheint. Diese Ergebnisse bedeuten aber etwas anderes. Wenn eine Reiseanfrage Flug, Hotel und Verpflegung verlangt und die Buchhaltung Flug und Hotel genehmigt, Mahlzeiten aber ablehnt, braucht dieser Fall einen eigenen Pfad, eigene Nachrichten und oft eigene Folgeaktionen.
Wird die Teilgenehmigung mit der Ablehnung zusammengeworfen, reichen Menschen den ganzen Antrag neu ein, laden Dokumente doppelt hoch und starten Prüfungen, die schon erledigt waren. Das ist reine Nacharbeit.
Ein einfacher Test hilft: Lies jeden Nicht-Ideal-Status und frage: „Wer besitzt das, was sieht der Nutzer und was passiert als Nächstes?“ Ist die Antwort vage, wird der Prozess wahrscheinlich später an derselben Stelle scheitern.
Bevor du Bildschirme baust oder etwas automatisierst, mach einen letzten Durchgang für die unordentlichen Fälle. Gutes Ausnahmepfad-Design sind oft nur ein paar klare Entscheidungen, die früh getroffen werden, bevor Verwirrung in Nacharbeit umschlägt.
Wenn ein Antrag abgelehnt, pausiert oder nur teilweise genehmigt wird, sollte immer klar sein, was als Nächstes passiert, wer es macht und welche Informationen noch fehlen.
Nutze diesen Schnellcheck für jede Ausnahme im Prozess:
Dann führe einen einfachen Test durch. Gib den Prozess an jemanden, der nicht am Design beteiligt war. Gib ihm einen abgelehnten Antrag und einen Antrag mit einem fehlenden Dokument. Kann die Person in unter einer Minute nicht sagen, was zu tun ist, ist der Prozess noch zu vage.
Ein kleines Beispiel verdeutlicht den Punkt. Ein Manager genehmigt eine Software, lehnt den Hardware-Teil aber ab. Steht dort nur „Teilweise genehmigt“, kann der Mitarbeitende annehmen, dass alles weiterläuft. Ein besserer Status sagt genau, was genehmigt wurde, was abgelehnt wurde und ob der Mitarbeitende den fehlenden Teil erneut einreichen kann.
Willst du diese Regeln in eine funktionierende interne App überführen, mappe zuerst die Ausnahmezustände und baue dann den idealen Ablauf. In AppMaster heißt das, Status, Geschäftsregeln und Pflichtfelder zu definieren, bevor du dich um polierte Bildschirme kümmerst. Das ist ein praktischer Weg, No-Code-Anwendungen zu bauen, die echte Arbeit bewältigen, nicht nur die ideale Version davon.
Der nächste Schritt ist einfach: Liste deine fünf wichtigsten Ausnahmen, weise jedem eine verantwortliche Person zu und schreibe die Nachricht, die der Nutzer sehen soll. Sind diese drei Punkte klar, wird der Build meist deutlich einfacher.
Warum reicht der ideale Ablauf nicht für einen Genehmigungs-Workflow?Weil reale Verzögerungen meist dann entstehen, wenn etwas fehlt, unklar ist, zu spät kommt oder nur teilweise genehmigt wird. Gestaltest du nur den sauberen Ablauf, lösen die Teams Probleme später über Chat, E-Mail und manuelle Workarounds.
Welche Ausnahmepfade sollte ich zuerst entwerfen?Fange mit den Fällen an, die am häufigsten vorkommen: Ablehnung, fehlende Informationen und Teilgenehmigung. Ergänze dann auch Blockaden wie Anträge ohne Verantwortlichen oder ohne definierten nächsten Schritt.
Welche Status sollte eine Genehmigungs-App haben?Nutze eine kleine Menge klarer Zustände, die jeweils nur eine Bedeutung haben. Ein praktikables Set ist: genehmigt, abgelehnt, benötigt Dokumente, benötigt Änderungen, teilweise genehmigt und abgelaufen (bei Fristen).
Wie sollte der Prozess fehlende Dokumente behandeln?Der Nutzer sollte genau sehen, was fehlt und was als Nächstes zu tun ist. Verschiebe den Antrag in einen Status wie „Benötigt Dokumente“, nenne die fehlenden Elemente klar und sende ihn an die richtige Person, statt den ganzen Antrag abzulehnen.
Wie handhabe ich Teilgenehmigungen, ohne Nacharbeit zu erzeugen?Behandle Teilgenehmigungen als eigenen Pfad, nicht als vollständige Ablehnung. Zeige, was genehmigt und was abgelehnt wurde, den neuen genehmigten Gesamtbetrag falls relevant, und ob die anfragende Person die Änderung akzeptieren, den Antrag bearbeiten oder nur den strittigen Teil erneut einreichen kann.
Was sollte passieren, wenn ein Antrag ohne Aktion stecken bleibt?Jeder wartende Status braucht einen Besitzer und eine zeitliche Regel. Wenn ein Prüfer abwesend ist oder ein Antrag zu lange liegt, sollte der Workflow eskalieren, neu zuweisen oder verfallen, statt stecken zu bleiben.
Was macht eine Ausnahme-Nachricht wirklich nützlich?Kurz und konkret: Sag dem Nutzer, welcher Teil abgelehnt oder fehlt, was bereits akzeptiert wurde, was er hochladen, ändern oder bestätigen muss, und was nach dem Resubmit passiert.
Sollte ich zuerst die Bildschirme oder die Workflow-Regeln entwerfen?Die Regeln zuerst. Einigt euch auf Status, Besitzer, Fristen, erforderliche Dateien und nächste Aktionen, bevor ihr Buttons oder Dashboards skizziert. Die Oberfläche sollte Entscheidungen widerspiegeln, die bereits getroffen wurden.
Wie kann ich testen, ob mein Ausnahmepfad klar genug ist?Teste ein echtes Szenario von Anfang bis Ende mit realen Zahlen und einem oder zwei Problemen, z. B. einer fehlenden Datei oder einem Policy-Verstoß. Kann eine unbeteiligte Person nicht in unter einer Minute sagen, was als Nächstes passiert, ist der Ablauf noch zu vage.
Wie würde ich so einen Workflow in AppMaster bauen?Lege die Ausnahmezustände zuerst in deiner Geschäftslogik fest und poliere dann das UI. In AppMaster bedeutet das, Status, Pflichtfelder, Ownership und Verzweigungen wie Ablehnen, Zurück zur Bearbeitung und Bedingt genehmigen zuerst zu definieren.
10. März 2026
6 Min
08. März 20269 Min
07. März 20266 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
