ilert ist die Incident-Management-Lösung, die von Grund auf als Single-Application konzipiert wurde und den gesamten Lebenszyklus der Reaktion auf Vorfälle abdeckt.
Ihr smarter Assistent für die Dienstplan-Erstellung
Geben Sie Ihre Anforderungen einfach in eine Chat-ähnliche Benutzeroberfläche ein. Fügen Sie Teammitglieder, Rotationsregeln und Zeiträume hinzu – und Sie erhalten im Handumdrehen einen sofort einsatzbereiten Dienstplan, auf den alle zugreifen können.
Lassen Sie die KI den Anruf entgegennehmen
Der KI-gestützte ilert Sprachagent ist Ihr erster Kontakt für eingehende Anrufe. Er begrüßt Anrufer, erfasst alle Informationen und übergibt den Incident mit klaren Details an den zuständigen Techniker.
Sekundenschnelle Status-Updates
Die ilert-KI versteht Ihre Systeme sowie die verschiedenen Incident-Arten und erstellt klare, zeitnahe Statusmeldungen. Während Sie die Störung beheben, formuliert sie professionelle Mitteilungen für die jeweiligen Empfänger.
ilert Responder – Ihr Incident-Berater in Echtzeit
Der ilert Responder ist ein intelligenter Agent, der Incidents in Echtzeit analysiert. Er kann mit Ihrem Observability-Stack verbunden werden, Alarmierungen systemübergreifend analysieren und umsetzbare Erkenntnisse liefern – wobei Ihr Team die volle Kontrolle behält.
Funktionen
Automatische Analyse von Protokollen, Metriken und letzten Änderungen
Erkennung von Ursachen und ähnlichen Incidents in der Vergangenheit
Vorschlagen von passenden Respondern, Rollback-Optionen oder betroffenen Diensten
Beantwortung von Fragen in natürlicher Sprache mit fundierten, nachvollziehbaren Ergebnissen
Integrationen
Starten Sie sofort mit unseren Integrationen
ilert stellt mithilfe unserer vorgefertigten Integrationen oder per E-Mail eine nahtlose Verbindung zu Ihren Tools her. Ilert lässt sich in Überwachungs-, Ticketing-, Chat- und Kollaborationstools integrieren.
So erreichen führende Unternehmen mit ilert eine Uptime von 99,9 %
Unternehmen weltweit vertrauen auf ilert, um ihr Incident-Management zu optimieren, die Zuverlässigkeit zu steigern und Ausfallzeiten zu minimieren. Lesen Sie, was unsere Kunden über ihre Erfahrungen mit unserer Plattform sagen.
Stellen Sie sich folgendes Szenario vor: Es ist 2 Uhr morgens, ein kritisches System bricht ohne Vorwarnung zusammen. Der völlig übermüdete diensthabende Techniker hetzt los, stellt den Service wieder her und schützt Ihre Kunden vor einem massiven Ausfall, der Ihre nächste Service Level Objective (SLO)-Überprüfung gefährden könnte. Am nächsten Morgen findet wie so oft eine hitzige Diskussion über die faire Bezahlung von Rufbereitschaften statt: Was ist eigentlich eine "angemessene" Vergütung für schlaflose Nächte, unberechenbare Benachrichtigungen und eine umgehende Incident-Response?
Was zählt als Rufbereitschaft?
Rufbereitschaft ist eine besondere Arbeitszeitregelung im Arbeitsrecht. Sie tritt in Kraft, wenn der Arbeitnehmer verpflichtet ist, mindestens telefonisch erreichbar zu sein, damit er im Notfall seine Arbeit aufnehmen kann. Rufbereitschaft wird in der Regel als Zeit gezählt, die speziell für Arbeitszwecke vorgesehen ist.
Praktisch heißt das: Während der Rufbereitschaft dürfen Mitarbeiter in der Regel keiner anderen Arbeit nachgehen. Es gibt jedoch Ausnahmen. Ist der Mitarbeiter über ein Dienstgerät erreichbar, kann er diese Zeit auch im Home-Office verbringen.
Was ist der Unterschied zwischen Rufbereitschaft und Bereitschaftsdienst?
Beide Modelle unterscheiden sich sowohl in der zeitlichen als auch in der örtlichen Komponente:
Rufbereitschaft - Der Mitarbeiter ist per Telefon, Pager oder On-Call-App erreichbar und kann sich von überall einloggen, sobald eine Alarmierung eintrifft.
Bereitschaftsdienst - Der Mitarbeiter muss vor Ort anwesend sein und sofort handeln können. Das deutsche Arbeitsrecht stuft diesen Bereitschaftsdienst vollständig als Arbeitszeit ein und regelt die Vergütung entsprechend
Im IT-Betrieb setzt man meist auf Remote-Dienstbereitschaft, weil sich die meisten Incidents (Code-Rollbacks, Config-Tweaks) bequem über VPN lösen lassen. Für latenzkritische Umgebungen bleibt der Bereitschaftsdienst jedoch unverzichtbar, etwa bei Trading-Plattformen oder industriellen Steueranlagen, wo Techniker die Hardware überwachen und innerhalb von Sekunden eingreifen müssen, um strenge Service-Level-Agreements einzuhalten.
Zählt Rufbereitschaft als Arbeitszeit?
Ob Rufbereitschaft als Arbeitszeit zählt, ist nicht so eindeutig festgelegt, wie man denken könnte. Nach den meisten arbeitsrechtlichen Regelwerken, darunter auch die Vorgaben zur Arbeitssicherheit und das US-amerikanische FLSA Fact Sheet #22, gilt passive Rufbereitschaft als Ruhezeit, solange keine Alarmierung eingeht.
Sobald der Mitarbeiter jedoch eine Alarmierung erhält und mit der Problemlösung beginnt, wird diese Zeit zur aktiven Arbeitszeit.
Auch bei der Bezahlung gibt es keine einheitliche Regel. Viele Arbeitgeber behandeln Rufbereitschaft als vergütete Arbeitszeit und zahlen entsprechend. Andere stufen passive Erreichbarkeit hingegen als unbezahlten Bereitschaftsdienst ein. Wenn Ihr Unternehmen dieses Modell anwendet, gilt: Erreichbarkeit ohne aktiven Einsatz wird nicht vergütet.
Fazit: Rufbereitschaft gilt nicht automatisch als Arbeitszeit, entscheidend ist die Vergütungspolitik des Arbeitgebers. Große Technologieunternehmen wie Airbnb, Apple oder Netflix zahlen nicht für passive Rufbereitschaft, während viele europäische IT-Unternehmen es anders handhaben.
Zeiten der Rufbereitschaft
Rufbereitschaft wird in der Regel auf bestimmte Nächte oder Wochenenden beschränkt, die vorab vereinbart und im Arbeitsvertrag festgehalten sind. Da zu diesen Zeiten weniger Personal vor Ort ist, ist eine verlässliche Abdeckung während der Nacht und am Wochenende wichtig.
In Deutschland empfiehlt der IT-Branchenverband Bitkom, Rufbereitschaft auf maximal 56 Tage pro Kalenderjahr zu begrenzen und pro Schicht mindestens 8 Stunden ununterbrochene Ruhezeit zu garantieren (Bitkom-Leitfaden “Rufbereitschaft im IT-Betrieb”). Da Rufbereitschaft grundsätzlich als arbeitsfreie Zeit gilt, greift die gesetzlich vorgeschriebene Ruhepause von 11 Stunden nach §5 (1) des Arbeitszeitgesetzes erst dann, wenn der Techniker tatsächlich an einem Incident arbeitet.
Wie wird Rufbereitschaft in IT-Unternehmen vergütet?
In den meisten Unternehmen gilt Rufbereitschaft als bezahlte Arbeitszeit, aber wie genau abgerechnet wird, variiert stark. Die Vergütung ist im Arbeitsvertrag oder in internen Vergütungsrichtlinien geregelt.
Einige große Technologieunternehmen, darunter Airbnb und Apple, zahlen angeblich nicht für passive Rufbereitschaft und verweisen darauf, dass ihre Techniker ohnehin am oberen Ende der Gehaltsskala liegen. Viele europäische Scale-ups hingegen zahlen entweder einen Zuschlag oder bieten Freizeitausgleich an.
In Deutschland gibt es keinen gesetzlich geregelten Fixbetrag – das Bundesarbeitsministerium stellt klar: Die Höhe der Vergütung liegt im Ermessen des Arbeitgebers.
In der Praxis dominieren zwei Modelle:
Zuschlag auf den Stundenlohn Ein prozentualer Aufschlag auf den regulären Stundenlohn für jede geplante Rufbereitschaftsstunde.
Freizeitausgleich Acht Stunden Rufbereitschaft ergeben vier Stunden bezahlten Urlaub.
Wichtig: Nur die Minuten, in denen tatsächlich gearbeitet wird, gelten rechtlich klar als Arbeitszeit. Die reine Erreichbarkeit bleibt unbezahlt, es sei denn, das Unternehmen hat es anders geregelt.
Wie werden Bereitschaftsdienste in IT-Unternehmen vergütet?
Die Bezahlung variiert weiterhin je nach Unternehmensgröße, Branche und Risikoprofil. Der Tarifvertrag für den öffentlichen Dienst (TVöD) legt in § 8 Abs. 3 folgende Zuschläge fest:
Bereitschaftsdienste ab 12 Stunden
Wochentage (Mo – Fr): Vergütung mit dem 2-fachen des Stundenlohns für den gesamten Tag.
Wochenenden und Feiertage: Vergütung mit dem 4-fachen des Stundenlohns für den gesamten Tag.
Kürzere Bereitschaftsfenster (unter 12 Stunden)
Hier fallen zusätzlich 12,5 % des Stundenlohns pro Stunde Rufbereitschaft an.
In großen Konzernen oder erfolgreichen Start-ups können Arbeitnehmer mit etwa 1.000 € pro Woche für Rufbereitschaft rechnen. Bei Zalando liegt die Vergütung bei rund 1.050 €, bei dem Start-up HelloFresh bei 1.000 €, und bei Amazon Deutschland etwa bei 800 €.
Aktuelle Beiträge aus Engineer-Foren und Communities liefern weitere Vergleichswerte:
Google - SRE-Rotation Tier 1 (fünf Minuten Reaktionszeit): Vergütung für 40 Minuten jeder On-Call-Stunde außerhalb der Bürozeiten (66 % des Basisstundenlohns). Tier 2 (30 Minuten Reaktionszeit): 20 Minuten pro Stunde (33 %).
AWS - (EU-Tier-0-Services): 25 % des Basisgehalts pro On-Call-Stunde außerhalb der regulären Arbeitszeit, plus einen halben Tag bezahlten Urlaub für jede nächtliche oder samstägliche Alarmierung.
Mehr als Bezahlung: Mitarbeitergesundheit schützen
Geld ist nicht alles. Rufbereitschaft stört den Schlafrhythmus und beeinträchtigt das Privatleben, deshalb ist der Schutz der Mitarbeitergesundheit entscheidend. Diese fünf Punkte sind für Zufriedenheit und Wohlbefinden von IT-Teams wichtig:
Erwartungen klar definieren: Reaktionszeiten und Eskalationspfade müssen klar definiert sein.
Fair rotieren: Schichten gerecht verteilen, mit Primär- und Sekundär-Rollen. Ein automatisierter Bereitschaftsplan sorgt für Transparenz.
Workload im Blick behalten: Zeiten je Techniker tracken, nächtliche Bereitschaftsdienste begrenzen. Mit den ilert-Berichten können zum Beispiel Muster erkannt werden.
Tools richtig nutzen: Deduplizierung von Alarmierungen und smarte Eskalationen reduzieren dank ilert die Alarmflut und verkürzen die Time-to-Sleep.
Training & Support anbieten: Vierteljährliche Notfallübungen oder Übungstage halten das Team einsatzbereit und sicher im Umgang mit kritischen Störungen.
Zusammenfassung
Rufbereitschaft im IT-Bereich bedeutet, außerhalb der regulären Arbeitszeiten für eventuelle Notfälle erreichbar zu sein, meist remote. Sie unterscheidet sich vom Bereitschaftsdienst, der die Anwesenheit vor Ort erfordert und immer als Arbeitszeit gilt. Im Gesetz gibt es keine Regelung, dass Rufbereitschaft automatisch vergütet wird, nur die aktive Reaktion auf Incidents zählt eindeutig als Arbeitszeit.
Die Bezahlung für Rufbereitschaft variiert: Manche Unternehmen zahlen einen Zuschlag auf den Stundenlohn oder bieten Freizeitausgleich an, andere – etwa Apple oder Airbnb – vergüten passive Rufbereitschaft gar nicht. Bitkom empfiehlt in Deutschland maximal 56 Einsatztage pro Jahr mit mindestens 8 Stunden Ruhezeit pro Schicht.
Wöchentliche Pauschalen liegen bei Firmen wie Zalando, HelloFresh und SumUp zwischen 800 € und 1.050 €. Best Practices zum Schutz der Mitarbeiter umfassen eine faire Regelung für Rotationen, klare Eskalationspfade, Tools zur Verringerung von Alarmflut und regelmäßige Trainings.
Stellen Sie sich vor, Incidents ließen sich durch Erkenntnisse statt durch manuelle Intervention lösen.
Stellen Sie sich weiter ein Incident-Management der Zukunft vor, in dem Sie bei kritischen Alarmierungen nie allein sind – Ihr bester Techniker würde stets für Sie da sein, Probleme unermüdlich untersuchen, Logs analysieren, Metriken korrelieren, kürzlich vorgenommene Code-Änderungen prüfen und sofort umsetzbare Erkenntnisse liefern. Diesen Schritt in die Zukunft gehen wir mit unserem ersten intelligenten Agenten: dem ilert Responder.
Warum AI-first?
Incident-Management entwickelt sich rasant weiter. Systeme werden komplexer, die Anzahl von Alarmierungen steigt sprunghaft an, der Druck auf die Teams nimmt zu. SREs sind häufig von Alarmflut überwältigt und müssen unter Zeitdruck Logs, Metriken und Dashboards analysieren, um Root-Causes aufzudecken.
Bei ilert setzen wir seit über drei Jahren auf KI im Incident-Management – mit intelligenter Gruppierung von Alarmierungen, automatisierter Postmortem-Erstellung und darüber hinaus. Der ilert Responder ist kein Anfang, sondern ein Quantensprung. Er baut auf jahrelanger Erfahrung, Grundlagenarbeit und Kundenfeedback auf.
Unser Fokus liegt kompromisslos darauf, die Mean Time to Resolution (MTTR) deutlich zu senken. Jede Entscheidung, jedes Feature bewerten wir gemäß der Frage: Wie trägt es dazu bei, die MTTR zu verringern? In GenAI und agentischen Systemen sehen wir transformatives Potenzial, genau dieses Ziel zu erreichen. Wir setzen auf eine Zukunft, in der Sie nur noch dann angepiept werden, wenn die KI einen Incident nicht autonom beheben kann. Keine Anrufe mehr um 3 Uhr nachts, nur um einen Dienst neu zu starten oder ein Deployment zurückzurollen.
Darum verpflichten wir uns, eine AI-first-Plattform zu werden und künstliche Intelligenz in den Kern all unserer Aktivitäten zu integrieren. Der ilert Responder ist mehr als ein weiteres KI-Feature; es ist die fundamentale Neugestaltung der Incident-Response.
Lernen Sie den ilert Responder kennen: Ihren 24/7-Incident-Co-Piloten
Der ilert Responder ist Ihr zuverlässiger Teamkollege und direkt in die ilert-Plattform integriert. Er
lässt sich nahtlos mit Ihrem Observability-Stack, Ihrer Cloud-Infrastruktur und Ihrem Code-Repository verbinden,
analysiert Incidents in Echtzeit anhand verschiedener Datenquellen und identifiziert Root-Causes,
liefert klare, priorisierte Empfehlungen zur Behebung von Störungen.
Interagieren Sie über eine Chat-Schnittstelle: Stellen Sie Fragen, teilen Sie Kontext und erhalten Sie genau dann Rat, wenn Sie ihn brauchen. Jede Erkenntnis des ilert Responders ist klar, umsetzbar und durch Daten belegt – selbst unter Hochdruck.
Im Kern nutzen wir das MCP (Model-Context Protocol), um den ilert Responder-Agenten mit Ihren Tools und Ihrer Infrastruktur zu verbinden. MCP ist für KI, was HTTP für das Web ist – ein Standardprotokoll, das LLM-basierte Agenten mit den Systemen verbindet, in denen reale Daten liegen. Es löst zwei grundlegende Herausforderungen: das begrenzte und veraltete Wissen von LLMs sowie die Komplexität individueller Integrationsschichten zwischen KI-Apps und externen Datenquellen.
Dank MCP kann der ilert Responder sicher und kontextbezogen mit Tools wie Grafana, Prometheus, GitHub und Kubernetes interagieren – und dort Logs, Metriken, Deployment-Daten, Code-Änderungen und mehr in Echtzeit abrufen. Wir haben eine skalierbare Multi-Tenant-Architektur um MCP herum aufgebaut, mit der wir neue Datenquellen (MCP-Server) einfach hinzufügen können und so die Analysefähigkeiten des Responders mit jeder Integration erweitern.
Sehen Sie sich den ilert Responder in Aktion an
Einführung von Agentic Incident Management
Der ilert Responder bedeutet den Beginn dessen, was wir Agentic Incident Management nennen. Hier:
schlussfolgern und untersuchen intelligente Agenten wie erfahrene Techniker,
lernen aus jeder Interaktion und werden stetig klüger,
arbeiten transparent Seite an Seite mit Menschen – wobei stets eine klare Übersicht gewährleistet ist.
Standardmäßig arbeitet der neue ilert Responder im Read-only-Modus und unterbreitet Empfehlungen für eine schnellere Lösung. Er ersetzt Ihr Bereitschafts-Team nicht, sondern ergänzt es.
Nehmen Sie am Beta-Programm für ilert Agentic Incident Response teil
Wir laden innovative Teams ein, an unserem Beta-Programm teilzunehmen und frühen Zugang zum ilert Responder zu erhalten. Als Beta-Tester
gestalten Sie zukünftige Funktionen direkt mit,
genießen frühe Vorteile und Wettbewerbsvorsprung,
führen Ihre Branche in das Zeitalter des KI-gestützten Incident-Managements.
Interesse? Schreiben Sie an support@ilert.com und gehören Sie zu den Ersten bei der AI-first-Incident-Response-Revolution.
AI-first-Incident-Management – für alle
KI-Features sind seit einigen Jahren integraler Bestandteil von ilert. Mit diesem nächsten Schritt sind KI-Funktionen nicht länger Premium-Plänen oder Add-ons vorbehalten; sie sind grundlegend.
Wir haben bereits bedeutende Änderungen an unserer Preisgestaltung vorgenommen. Während der Beta-Phase steht der ilert AI Responder ohne zusätzliche Kosten zur Verfügung. Doch das ist nicht alles: Wir stellen unser AIOps-Add-on ein und machen KI-Funktionen wie intelligentes Alert-Grouping im Scale-Tarif verfügbar. Selbst Kunden in unserem Free-Tarif haben jetzt Zugriff auf KI-Features.
Bald erhalten alle ilert-Kunden flexible AI-Credits, um erweiterte Funktionen freizuschalten – vom ilert Responder bis zum ilert Postmortem-Creator. Details zu unserem transparenten Preismodell mit Credits folgen in Kürze. Halten Sie sich über unseren Blog und Newsletter auf dem Laufenden.
Privacy-first, immer
Der Schutz und die Sicherheit Ihrer Daten haben bei uns höchste Priorität. Wir treiben AI-first voran, um die Incident-Behebung zu beschleunigen, und verankern zugleich Privacy-first mit Datensouveränität, End-to-End-Verschlüsselung, regionsspezifischer KI-Verarbeitung und DSGVO-Konformität. Wir entwickeln von Grund auf intelligente Systeme, die Datenschutz ebenso gewährleisten wie sie Innovation ermöglichen. Der ilert AI Responder basiert auf diesem Fundament.
Für die ilert KI nutzen wir Foundation-Modelle, die je nach Standort bei AWS, Microsoft Azure oder OpenAI gehostet werden. Für Kunden in der EU findet die gesamte KI-Verarbeitung innerhalb Europas auf AWS- oder Microsoft-Infrastruktur statt – es verlassen keine Daten die EU, und es werden keine personenbezogenen oder sensiblen Informationen an OpenAI-Endpunkte außerhalb der EU gesendet. Kunden außerhalb der EU können OpenAI oder AWS nutzen, stets unter strengen Zugriffskontrollen sowie Verschlüsselung bei Speicherung und Übertragung.
Darüber hinaus verwenden wir ausschließlich Daten, die Alarmierungen und Incidents betreffen, und teilen keine personenbezogenen Performancedaten mit externen KI-Modellen. Wir nutzen Ihre Daten nicht zum Training von Modellen und haben bei allen LLM-Anbietern ein Opt-out für Training aktiviert.
Erfahren Sie mehr über unser Engagement für Sicherheit und Datenschutz im Q&A-Bereich.
Wir beginnen eine neue Ära der Incident-Response – eine Ära, in der künstliche Intelligenz SREs nicht ersetzt, sondern sie auf eine neue Stufe bringt. Der ilert Responder ist erst der Anfang – die Zukunft ist kollaborativ, intelligent und menschenzentriert. Lassen Sie sie uns gemeinsam gestalten!
Die ilert Mobile App wird hauptsächlich von Responder:innen genutzt, um Benachrichtigungen über kritische Alarme zu empfangen, unterwegs darauf zu reagieren und den aktuellen On-Call-Status einzusehen. Sie bietet verschiedene Funktionen, darunter kritische Push-Benachrichtigungen, Schnellaktionen für Alerts und individuelle Einstellungen für kritische Benachrichtigungen. Mit der App können Responder:innen ihre aktuellen On-Call-Schichten und Eskalationsregeln einsehen, Schichten von Kolleg:innen übernehmen oder Vertretungsanfragen erstellen, um Kolleg:innen um eine Übernahme der On-Call-Schicht zu bitten. Letzteres ist eine neue Funktion von ilert, die sich als besonders hilfreich für die Kommunikation zwischen Nutzer:innen erwiesen hat. In diesem Beitrag werfen wir einen genaueren Blick auf die Entwicklung dieser Funktion und die Herausforderungen, die dabei zu bewältigen waren.
Warum wurden Vertretungsanfragen eingeführt?
Seit der Einführung der On-Call-Schedules können Nutzer:innen sogenannte Overrides erstellen – also spezielle Schichten, die Vorrang vor regulären Schichten haben. Ein Override erlaubt es, eine andere Person für eine ganze oder teilweise Schicht als On-Call-Verantwortliche:n einzutragen. Overrides müssen nicht an bestehende Schichten gebunden sein – sie können für beliebige Zeiträume erstellt werden, auch außerhalb definierter Schichten.
Später wurde die Funktion „Take On-Call“ eingeführt, also die Möglichkeit, eine fremde Schicht zu übernehmen. Beide Methoden erzeugen technisch gesehen einen Override, doch keine stellt sicher, dass die jeweils andere Person über diese Änderung informiert wird. Das führte in der Praxis dazu, dass Personen plötzlich für Schichten verantwortlich waren, ohne davon zu wissen – was im Ernstfall kritisch sein kann.
Die Lösung war ein neuer Flow: Nutzer:innen sollten die Möglichkeit bekommen, gezielt eine andere Person um die Übernahme einzelner On-Call-Zeiträume zu bitten – mit klarer Kommunikation und Rückmeldung. Daraus entstand das Konzept der Vertretungsanfragen.
Design der REST API für Vertretungsanfragen
Der typische Ablauf einer Vertretungsanfrage ist:
Nutzer:in A erstellt eine Vertretungsanfrage und bittet Nutzer:in B, eine oder mehrere Schichten ganz oder teilweise zu übernehmen.
Nutzer:in B erhält eine Benachrichtigung und kann die Anfrage annehmen oder ablehnen.
Nutzer:in A wird über die Entscheidung informiert.
Die Vertretungsanfragen-API basiert auf einem eigenen Entity-Typ mit mindestens folgenden Feldern:
sender
receiver
shifts
Zusätzlich haben wir ein Nachrichtenfeld (message) eingeführt, damit Nutzer:innen zusätzliche Informationen zur Anfrage übermitteln können. Für die UI haben wir außerdem den aktuellen Status (state) und das Erstellungsdatum (createdAt) als Read-only-Attribute bereitgestellt. Bei einer Ablehnung kann optional ein Kommentar mit der Begründung (declineComment) übermittelt werden. Zur Anzeige mehrerer Anfragen in der Listenansicht und für sinnvolle Filter wurde das Feld state in Kombination mit einem im Frontend berechneten Status expired genutzt. Eine Vertretungsanfrage gilt als abgelaufen, wenn die letzte enthaltene Schicht beendet ist.
Neben klassischen Create- und Read-Operationen wurden eigene Endpunkte fürs Akzeptieren, Ablehnen und Zurückziehen eingeführt. Update- und Delete-Operationen gehören aktuell nicht zum Flow und sind nicht geplant.
Vom Mockup zur finalen UI
Zwischen Mockup und finaler Version der Ansicht zur Erstellung einer Vertretungsanfrage gibt es keine großen Unterschiede. Lediglich das Styling wurde angepasst, und es wurde ein zusätzliches Infofeld zur Zeitzone eingeführt. Die finalen Versionen der Listen- und Detailansicht sehen folgendermaßen aus:
Kommunikation ist der Schlüssel
Ein zentrales Ziel dieser Funktion ist es, Nutzer:innen dazu zu motivieren, frühzeitig auf Vertretungsanfragen zu reagieren – da On-Call-Schichten zeitgebunden und oft kurzfristig sind. Außerdem sollen alle relevanten Kommunikationsprozesse in der ilert Mobile App stattfinden, sodass ein Toolwechsel überflüssig wird. Dafür wurden mehrere Kommunikationswege implementiert:
Push-Benachrichtigungen
Sobald eine Aktion bei einer Vertretungsanfrage erfolgt, wird eine Push-Benachrichtigung an die jeweils betroffene Person gesendet:
Vertretungsanfrage erstellt → Empfänger:in wird benachrichtigt
Anfrage angenommen/abgelehnt → Absender:in wird benachrichtigt
Anfrage storniert → Empfänger:in wird benachrichtigt
Aber was passiert, wenn die empfangende Person die Mobile-App nicht nutzt?
E-Mail
ilert prüft, ob die relevanten Nutzer:innen über mindestens ein registriertes Push-Token (ein eindeutiger Geräte-Identifikator) verfügen. Falls nicht, wird automatisch eine E-Mail an die primäre Adresse mit den Details zur Vertretungsanfrage gesendet.
In-App Badge
Da Push-Benachrichtigungen versehentlich übersehen oder weggeswiped werden können – auch bei zeitkritischen Anfragen – wurde in der Listenansicht ein roter Kreis (Badge) oben links am Menü-Icon eingeführt. Dieser zeigt an, ob ungelesene Vertretungsanfragen vorhanden sind. Zusätzlich zeigt der Menüpunkt eine Zählung aller offenen Anfragen an.
Filter bereitstellen, aber UI schlank halten
Eine Filtermöglichkeit für Vertretungsanfragen in der Listenansicht ist notwendig – beispielsweise für empfangene und gesendete Anfragen. Ein weiterer, komplexerer Filter betrifft nur relevante Anfragen, also solche, die noch nicht abgelaufen oder beantwortet sind.
Da bereits ein Toggle für „Erhalten / Gesendet“ existiert, hätte ein zusätzlicher „Aktuell / Alle“-Toggle die Oberfläche überladen.
Ein Vorschlag war eine Filterleiste wie bei der Alert-Liste – diese Idee wurde jedoch verworfen, da sie zum Releasezeitpunkt nur einen Filter enthalten hätte, was nicht stimmig gewirkt hätte. Die finale Lösung: standardmäßig werden nur offene Anfragen (Status Pending) angezeigt, alle weiteren sind über einen Button zugänglich. Diese Lösung bietet die beste Balance zwischen Übersichtlichkeit und Funktionalität.
Alltag bringt Details ans Licht
Nach dem Release begann das ilert-Team selbst mit der Nutzung der Funktion – und stieß schnell auf eine Schwäche: Nach dem Ausführen einer Aktion (Accept, Decline, Cancel) verschwand die betreffende Anfrage sofort aus der Liste, ohne dass der veränderte Status ersichtlich war.
Zwei Verbesserungen wurden daraufhin umgesetzt:
Nach einer Aktion bleibt man in der Detailansicht, um den aktualisierten Status direkt zu sehen.
Relevante Anfragen bleiben 24 Stunden nach einer Aktion weiterhin in der Liste sichtbar.
Zuvor verschwand eine Anfrage sofort nach der Statusänderung aus der Liste, da diese auf dem state-Feld basierte. Um auch kürzlich bearbeitete Anfragen anzuzeigen, wurde ein zusätzlicher Query-Parameter in der API eingeführt. Damit kann das Frontend eine createdAt-Zeitgrenze definieren. Die Antwort enthält dann alle Vertretungsanfragen – unabhängig vom Status – ab diesem Zeitpunkt bis jetzt. So können Nutzer:innen alle offenen sowie kürzlich bearbeiteten (innerhalb der letzten 24 Stunden) Anfragen einsehen.
Haben Sie die ilert App noch nicht installiert? Probieren Sie sie gerne aus – jetzt für Android oder iOS herunterladen.
Hoppla! Beim Absenden des Formulars ist etwas schief gelaufen.
Unsere Cookie-Richtlinie
Wir verwenden Cookies, um Ihre Erfahrung zu verbessern, den Seitenverkehr zu verbessern und für Marketingzwecke. Erfahren Sie mehr in unserem Datenschutzrichtlinie.
.png)
.png)
.png)
.png)
.png)
.png)
.png)
