13. Apr. 2025·8 Min
Wie man eine Web‑App für interne Serviceanfragen baut
Erfahren Sie, wie Sie eine Web‑App planen, entwerfen und bauen, die interne Serviceanfragen sammelt, Genehmigungen routet, SLAs verfolgt und Leistung sicher berichtet.
Erfahren Sie, wie Sie eine Web‑App planen, entwerfen und bauen, die interne Serviceanfragen sammelt, Genehmigungen routet, SLAs verfolgt und Leistung sicher berichtet.
Bevor Sie Bildschirme entwerfen oder einen Tech‑Stack wählen, legen Sie genau fest, welches Problem Ihre interne Service‑Request‑App lösen soll. Die meisten Teams haben bereits ein „System“ — es verteilt sich nur auf E‑Mail‑Threads, Chats, Tabellenkalkulationen und Flurgespräche. Dieses Setup versteckt Arbeit, erzeugt doppelte Anfragen und macht es schwer, eine einfache Frage zu beantworten: „Wer ist verantwortlich und wann ist es erledigt?“
Beginnen Sie mit einer prägnanten Problemstellung und einem V1‑Ziel, z. B.: „Ein zentrales Mitarbeiter‑Portal für IT‑Zugänge und Facility‑Reparaturen mit klarer Zuständigkeit, erforderlichen Genehmigungen und SLA‑Sichtbarkeit.“
Interne Anfragen gruppieren sich meist in ein paar Kategorien:
Sie müssen nicht jeden Edge‑Case am ersten Tag lösen, aber legen Sie einen klaren Startumfang fest (z. B.: „IT‑Zugänge + Facility‑Reparaturen“).
Schreiben Sie die aktuellen Fehlerpunkte in einfachem Wording nieder:
Diese Liste wird Ihr Nordstern dafür, was die App beheben muss.
Definieren Sie Ihre primären Nutzer und deren Bedürfnisse:
Setzen Sie Ziele, die Sie nach dem Launch verfolgen können: kürzere Bearbeitungszeit, weniger Follow‑ups pro Ticket, höhere First‑Response‑Geschwindigkeit und klarere Verantwortlichkeit (z. B. „jede Anfrage hat innerhalb 1 Geschäftsstunde einen Besitzer“). Diese Kennzahlen steuern Produktentscheidungen und helfen zu belegen, dass die App wirkt.
Bevor Sie Bildschirme oder Workflows entwerfen, klären Sie wer die App nutzt und was jede Person darf (und soll). Viele interne Request‑Systeme scheitern, weil Rollen schwammig sind: Niemand weiß, wer den nächsten Schritt übernimmt, und Anfragen werden hin‑ und hergeschoben.
Mitarbeiter (Anfragender)
Mitarbeitende sollten Anfragen in Minuten einreichen können und sicher sein, dass sie nicht verschwinden.
Genehmiger
Genehmiger behalten Ausgaben, Zugriffe und Policy‑Entscheidungen unter Kontrolle.
Agent / Bearbeiter
Agenten sind die Personen, die die Arbeit tatsächlich erledigen und den Fortschritt kommunizieren.
Admin
Admins halten das System organisiert und sicher.
Für jeden Anfragetyp definieren Sie:
Eine einfache RACI‑Tabelle in Ihrer Spezifikation verhindert Verwirrung und erleichtert spätere Workflow‑Entscheidungen.
Eine v1‑Interne‑Request‑Plattform sollte wenige Dinge besonders gut können: Mitarbeitende ermöglichen, klare Anfragen einzureichen, sie schnell an das richtige Team zu bringen und alle bis zum Abschluss informiert zu halten. Wenn Sie versuchen, jeden Edge‑Case am ersten Tag einzubauen, verzögern Sie die Auslieferung und verpassen trotzdem, was Nutzer wirklich brauchen.
Beginnen Sie mit einer kleinen Menge an Kategorien (z. B. IT‑Help, Facilities, HR, Purchasing). Jede Kategorie sollte dynamische Felder unterstützen, damit das Formular nur nach Relevanten fragt.
Enthalten sein sollten:
V1 braucht vorhersehbare Zuweisung: nach Kategorie, Abteilung, Standort oder Schlüsselwortregeln. Fügen Sie Priorität (niedrig/mittel/hoch) und einen einfachen Eskalationspfad hinzu (z. B. „24 Stunden unzugewiesen“ oder „hohe Priorität 4 Stunden inaktiv“). Halten Sie den Regel‑Editor minimal; später kann er flexibler werden.
Unterstützen Sie zunächst Einzelschritt‑Genehmigungen (Manager oder Budgetverantwortlicher). Falls Genehmigungen kritisch sind, fügen Sie bedingte Genehmigungen hinzu (z. B. „über $500 erfordert Finance“). Mehrstufige Ketten können warten, außer sie sind Ihr wichtigster Anfragetyp.
Senden Sie E‑Mail und In‑App‑Benachrichtigungen für: Anfrage eingegangen, zugewiesen, benötigt Infos, genehmigt/abgelehnt, abgeschlossen. Fügen Sie Erinnerungen für Genehmiger und Beauftragte bei überfälligen Items hinzu.
Vor der Einreichung und in der Anfrageliste bieten Sie Suche mit Filtern (Kategorie, Status, Anfragender). Fügen Sie „ähnliche Anfragen“ und Links zu Knowledge‑Seiten hinzu, damit Nutzende gängige Probleme selbst lösen können.
Ein klares Datenmodell für Anfragen erleichtert alles andere: Formulare bleiben konsistent, Workflows lassen sich automatisieren und Reporting wird verlässlich. Entscheiden Sie, was eine „Anfrage“ in Ihrer Organisation ist und welche Details immer erfasst werden müssen.
Halten Sie das initiale Formular schlank, aber so vollständig, dass das aufnehmende Team ohne Rückfragen arbeiten kann. Ein praktisches Minimum:
Kategorien sollten widerspiegeln, wie Arbeit organisiert ist (IT, Facilities, HR, Finanzen), während Unterkategorien wiederkehrende Arbeitstypen abbilden (z. B. IT → „Zugriffsanfrage“, „Hardware“, „Software“). Verwenden Sie benutzerfreundliche Namen und vermeiden Sie Duplikate („Onboarding“ vs. „New Hire Setup“).
Wachsen die Kategorieauswahlen, versionieren Sie sie statt sie stillschweigend umzubenennen — das schützt das Reporting und reduziert Verwirrung.
Nutzen Sie Validierung, um vage Tickets und fehlende Routing‑Details zu verhindern:
Wählen Sie einen einfachen Lifecycle, den Teams nicht unterschiedlich auslegen, und definieren Sie, was jeder Status bedeutet:
Schreiben Sie Übergangsregeln auf (wer kann zu Pending Approval wechseln? wann ist Waiting for Info zulässig?) und speichern Sie eine Audit‑Spur mit Statusänderungen, Zuordnungen, Genehmigungen und wichtigen Änderungen.
Eine Service‑Request‑Webapp lebt davon, wie schnell Mitarbeitende eine Anfrage einreichen und wie einfach Teams sie bearbeiten können. Skizzieren Sie die Kernbildschirme und den „Happy Path“ für jede Rolle: Anfragender, Genehmiger und Bearbeiter.
Behandeln Sie das Formular als geführten Ablauf, nicht als eine abschreckende lange Seite. Nutzen Sie Abschnitts‑Schritte (oder progressive Offenlegung), sodass Mitarbeitende nur das sehen, was für die gewählte Kategorie wichtig ist.
Machen Sie Erwartungen explizit: zeigen Sie, welche Informationen erforderlich sind, typische Antwortzeiten und was nach der Einreichung passiert. Tooltips und Hilfetexte verhindern Nachfragen („Was zählt als ‚dringend‘?“, „Welche Dateien sollte ich anhängen?“).
Personen, die Anfragen bearbeiten, brauchen eine inbox‑ähnliche Liste mit schnellen Sortier‑ und Triagemöglichkeiten. Fügen Sie Filter hinzu, die echte Arbeit abbilden:
Gestalten Sie Zeilen so, dass sie auf einen Blick beantworten: „Was ist das und was ist als Nächstes zu tun?“: Titel, Anfragender, Priorität, aktueller Status, Fälligkeitsdatum/SLA‑Indikator und nächste Aktion.
Die Detailseite ist der Ort der Zusammenarbeit. Sie sollte kombinieren:
Halten Sie primäre Aktionen prominent (genehmigen/ablehnen, zuweisen, Status ändern) und machen Sie sekundäre Aktionen auffindbar, aber nicht ablenkend.
Planen Sie Barrierefreiheit von den ersten Wireframes an: Tastaturnavigation für alle Aktionen, ausreichend Farbkontrast (nicht nur Farbe für Status verwenden) und lesbare Labels, die mit Screenreadern funktionieren.
Workflows verwandeln ein einfaches „Formular + Inbox“ in ein vorhersehbares Serviceerlebnis. Definieren Sie sie früh, damit Anfragen nicht steckenbleiben, Genehmigungen konsistent sind und alle wissen, was „fertig“ bedeutet.
Beginnen Sie mit einem klaren Einreichungsweg, der Rückfragen reduziert:
Triage verhindert, dass das System zur gemeinsamen Mailbox wird.
Genehmigungen sollten policy‑getrieben und konsistent sein:
Eskalation ist kein Bestrafen, sondern ein Sicherheitsnetz.
Gut ausgeführt halten diese Workflows Anfragen in Bewegung und geben Mitarbeitenden vorhersehbare Ergebnisse.
Ein gutes Schema macht Ihre Webapp leichter wartbar, reportbar und erweiterbar. Streben Sie ein sauberes Kern‑Set von Tabellen an und fügen Sie unterstützende Tabellen für Flexibilität und Analytik hinzu.
Beginnen Sie mit Tabellen, die Sie auf fast jedem Bildschirm berühren:
Halten Sie requests.status als kontrollierte Wertemenge und speichern Sie Zeitstempel für Lifecycle‑Reports.
Um verschiedene Anfragetypen zu unterstützen, ohne bei jeder Änderung neue Tabellen zu erstellen:
Für eine Prüfspur erstellen Sie audit_events mit request_id, actor_id, event_type, old_value/new_value (JSON) und created_at. Verfolgen Sie Status‑, Zuordnungs‑ und Genehmigungsänderungen explizit.
Für Reporting können Sie Views (oder dedizierte Tabellen später) anbieten wie:
Indexieren Sie requests(status, created_at), requests(assigned_team_id) und audit_events(request_id, created_at), um häufige Abfragen performant zu halten.
Eine Service‑Request‑App gelingt, wenn sie leicht änderbar ist. Ihre erste Version wird sich entwickeln, wenn Teams neue Anfragetypen, Genehmigungsschritte und SLA‑Regeln hinzufügen — wählen Sie also Technologien, die Ihr Team warten kann, nicht nur das Trendige.
Für die meisten internen Tools gewinnen „langweilige“ Optionen:
Wenn Sie noch schneller voranschreiten wollen (besonders für ein internes Tool), ziehen Sie in Erwägung, mit Koder.ai eine funktionierende Basis zu generieren. Es ist eine „vibe‑coding“ Plattform, bei der Sie das Service‑Portal im Chat beschreiben und Feature‑Iterationen (Formulare, Queues, Genehmigungen, Benachrichtigungen) mit Agenten‑gestützter Arbeitsweise durchführen. Koder.ai zielt häufig auf React im Frontend und Go + PostgreSQL im Backend, unterstützt Source‑Code‑Export, Deployment/Hosting, eigene Domains und Snapshots mit Rollback — nützlich, wenn Sie Workflows schnell verfeinern. Preise reichen von Free, Pro, Business bis Enterprise, sodass Sie pilotieren können, bevor Sie sich festlegen.
/requests, /approvals und /attachments. Ziehen Sie GraphQL nur dann in Betracht, wenn Ihre UI viele verschiedene, flexible Sichten derselben Request‑Daten benötigt (und Sie die zusätzliche Komplexität wollen).Für die Architektur ist ein modularer Monolith oft ideal für v1: eine deploybare App mit klar getrennten Modulen (Requests, Approvals, Notifications, Reporting). Das ist einfacher als Microservices, behält aber saubere Grenzen.
Interne Anfragen enthalten oft Screenshots, PDFs oder HR‑Dokumente.
Containerisierung (Docker) sorgt für konsistente Umgebungen. Für Hosting wählen Sie eine verwaltete Plattform, die Ihre Organisation bereits nutzt (PaaS oder Kubernetes). Achten Sie darauf, dass sie unterstützt:
Wenn Sie Optionen vergleichen, halten Sie die Entscheidungskriterien kurz und dokumentiert — spätere Maintainer werden es Ihnen danken.
Sicherheit ist kein „später“ Thema, auch bei rein interner Nutzung. Die App verarbeitet Identitätsdaten, Anfrageinhalte und teils sensible Anhänge (HR, Finance, IT‑Zugriffe). Ein paar Grundlagen verhindern schmerzhafte Nacharbeiten.
Bevorzugen Sie Single Sign‑On (SSO) via SAML oder OIDC, damit Mitarbeitende ihr bestehendes Firmenkonto nutzen und Sie keine Passwörter speichern müssen. Falls die Organisation Verzeichnisse nutzt (Entra ID/Active Directory/Google Workspace), integrieren Sie diese für automatisierte Joiner/Mover/Leaver‑Updates.
Machen Sie Zugriff explizit mit rollenbasiertem Zugriffskontrollmodell (RBAC): Anfragende, Genehmiger, Agenten und Admins. Ergänzen Sie team‑basierte Sichtbarkeit, sodass Supportgruppen nur ihre zugewiesenen Anfragen sehen, während Mitarbeitende nur die eigenen (oder ggf. die ihrer Abteilung) einsehen können.
Verschlüsseln Sie überall (HTTPS). Für gespeicherte Daten verschlüsseln Sie sensible Felder und Dateien bei Bedarf und halten Sie Zugangsdaten aus dem Code. Nutzen Sie einen Secret‑Manager (Cloud Secrets oder Vault) und rotieren Sie Schlüssel regelmäßig.
Für Genehmigungen, Zugriffsänderungen oder lohnrelevante Anfragen führen Sie eine unveränderliche Audit‑Spur: wer hat wann erstellt, angesehen, bearbeitet und genehmigt. Behandeln Sie Audit‑Logs als Anhänge und beschränken Sie darauf den Zugriff.
Fügen Sie Rate‑Limiting für Login und kritische Endpunkte hinzu, validieren und säubern Sie Eingaben und schützen Sie Datei‑Uploads (Typ‑Checks, Größenlimits, Malware‑Scan falls nötig). Diese Basics halten Ihr Ticketing‑System und die Workflow‑Automatisierung unter Fehlern und Missbrauch stabil.
Eine Service‑Request‑App funktioniert nur, wenn Leute Anfragen sehen und darauf reagieren. Integrationen machen Ihr Portal zum Teil des täglichen Ablaufs statt zu „noch einem Tab“.
Beginnen Sie mit einer kleinen Menge praxisrelevanter Benachrichtigungen:
Halten Sie Nachrichten kurz und mit Deep‑Links zur Anfrage. Wenn Ihr Unternehmen in Slack oder Teams lebt, senden Sie dort Benachrichtigungen, unterstützen Sie aber weiterhin E‑Mail für Nachvollziehbarkeit und Nutzer außerhalb von Chat.
Binden Sie Ihr Organigramm durch Synchronisation mit dem Identity‑Provider (Okta, Azure AD, Google Workspace) an. Das hilft bei:
Führen Sie Sync zeitgesteuert und beim Login aus und bieten Sie einfache Admin‑Override‑Fälle.
Wenn Anfragen Vor‑Ort‑Termine, Interviews oder Equipment‑Übergaben betreffen, fügen Sie Kalender‑Integration hinzu, um Zeiten vorzuschlagen und Events nach Genehmigung zu erstellen. Betrachten Sie Kalendereinträge als Ableitungen aus der Anfrage — die Anfrage bleibt die Quelle der Wahrheit.
Wenn Sie zwischen Bauen und Kaufen abwägen, vergleichen Sie Ihre Integrationsanforderungen mit einem Paketangebot auf /pricing oder lesen Sie Hintergrund im Artikel auf /blog/it-service-desk-basics.
Ohne Messung kann Ihre App sich nicht verbessern. Reporting zeigt Engpässe, begründet Stellenbedarf und belegt Zuverlässigkeit gegenüber dem Business.
Starten Sie mit wenigen, klaren SLA‑Metriken, die alle verstehen.
First response time: Zeit von Einreichung bis zur ersten menschlichen Berührung (Kommentar, Klärungsfrage, Zuweisung oder Statusupdate). Gut für Erwartungen und weniger „wurde das gesehen?“‑Nachfragen.
Resolution time: Zeit von Einreichung bis Abschluss. Reflektiert die End‑to‑End‑Lieferung.
Machen Sie SLA‑Regeln pro Kategorie und Priorität explizit (z. B. „Zugriffsanfragen: erste Antwort innerhalb 4 Arbeitsstunden, Lösung innerhalb 2 Arbeitstagen"). Entscheiden Sie, was die Uhr anhält — z. B. Warten auf Anfragenden, Dritt‑Genehmigungen oder fehlende Informationen.
Reports sollten nicht nur Dashboards sein. Agenten und Teamleads brauchen operative Bildschirme:
Diese Sichten machen SLA‑Tracking zur praktischen Arbeit, nicht zum Monatsbericht.
Nutzen Sie ein leichtes Dashboard für Managementfragen:
Machen Sie Diagramme durchklickbar, damit Führungskräfte zu den zugrunde liegenden Anfragen drillen können.
Bieten Sie CSV‑Exporte für gefilterte Listen (Team, Kategorie, Zeitraum, SLA‑Status), damit Finance, Ops oder Auditoren offline arbeiten können, ohne Admin‑Zugriff zu benötigen.
Ein guter Launch ist weniger großes Tamtam als kontrolliertes Lernen. Behandeln Sie v1 als Produkt, das Sie schnell verbessern, nicht als fertiges System.
Pilotieren Sie in einer Abteilung (oder für einen Anfragetyp) mit sinnvollem Volumen und geringem Risiko — z. B. IT‑Zugänge oder Facility‑Reparaturen. Definieren Sie Erfolgskriterien für den Pilot: Einreichungs‑ bis Lösungszeit, Abschlussrate und wie oft manuelle Korrekturen nötig sind.
Sobald der Pilot stabil ist, erweitern Sie in Wellen: weitere Abteilungen, mehr Formulare, dann mehr Automatisierung. Führen Sie eine einfache „Was hat sich geändert?“-Seite oder Release‑Notes in der App, damit Nutzer nicht überrascht sind.
Konzentrieren Sie Tests auf Pfade, die Vertrauen brechen:
Machen Sie UAT zu einer Checkliste entlang Ihrer Schlüsselworkflows: erstellen, bearbeiten/abbrechen, genehmigen/ablehnen, neu zuweisen, schließen und (falls erlaubt) wieder öffnen.
Wenn Anfragen derzeit in Tabellen oder E‑Mails leben, entscheiden Sie, was importiert werden muss (offene Items, letzte 90 Tage oder vollständige Historie). Importieren Sie mindestens: Anfragender, Kategorie, Zeitstempel, aktuellen Status und relevante Notizen. Kennzeichnen Sie importierte Items klar in der Audit‑Spur.
Fügen Sie eine In‑App‑Umfrage bei geschlossenen Anfragen hinzu („Wurde das gelöst?“ und „Gab es Probleme mit dem Formular?“). Halten Sie wöchentliche kurze Reviews mit Stakeholdern, um Feedback zu triagieren, und priorisieren Sie im Backlog klar: Zuverlässigkeitsfixes zuerst, Usability zweitens, neue Features zuletzt.
Starten Sie mit einem engen, praxisnahen Scope (zum Beispiel IT-Zugangsanforderungen + Facility-Reparaturen). Dokumentieren Sie, was heute schief läuft (versteckte E‑Mails, unklare Zuständigkeiten, keine Prüfspur), definieren Sie die Hauptnutzer (Anfragende, Genehmigende, Bearbeitende, Admins) und setzen Sie messbare Erfolgskennzahlen (z. B. „jede Anfrage hat innerhalb 1 Geschäftsstunde einen Besitzer“).
Die meisten internen Anfragen fallen in wiederkehrende Kategorien:
Beginnen Sie mit den Kategorien, die häufig und schmerzhaft sind, und erweitern Sie die Workflows, sobald sie stabil sind.
Nutzen Sie eine kleine, explizite Rollenauswahl mit klaren Berechtigungen:
Konzentrieren Sie sich darauf, „schlechte“ Anfragen schwer einreichbar zu machen:
Höhere Eingangsqualität reduziert Nachfragen und beschleunigt Routing sowie Genehmigungen.
Machen Sie das Routing in v1 vorhersehbar und minimal:
Halten Sie den Regel‑Editor simpel; Komplexität kann später ergänzt werden, wenn Muster sichtbar werden.
Beginnen Sie mit Einzelschritt‑Genehmigungen (Manager oder Budgetverantwortlicher) und fordern Sie Genehmigungen nur dort, wo die Policy es verlangt.
Für Wachstum:
Vermeiden Sie mehrstufige Ketten, außer sie sind für einen zentralen Anfragetyp notwendig.
Verwenden Sie einen kleinen, gemeinsamen Status‑Lifecycle mit klaren Bedeutungen, z. B.:
Schreiben Sie Übergangsregeln auf (wer darf was ändern) und speichern Sie eine Audit‑Spur für Status‑, Zuordnungs‑ und Genehmigungsänderungen, damit Entscheidungen nachvollziehbar sind.
Konzentrieren Sie sich auf drei Kernbildschirme plus eine starke Detailansicht:
Berücksichtigen Sie Barrierefreiheit früh (Tastaturnavigation, Kontrast, Screenreader‑Labels).
Eine praktische Schemaauswahl umfasst:
Priorisieren Sie unternehmensübliche Basics:
Fügen Sie eine einfache RACI‑Matrix in Ihre Spezifikation, damit Zuständigkeiten und Übergaben eindeutig sind.
users, roles, user_roles, teams, requests, comments, attachmentscategories, form_fields, request_field_valuesapprovals, sla_policiesaudit_eventsIndizieren Sie gängige Abfragen (z. B. requests(status, created_at) und audit_events(request_id, created_at)), damit Queues und Timelines schnell bleiben.
Diese Maßnahmen verhindern Nacharbeit, wenn HR/Finanzen/Security dazukommen.