Aktives Arbeitsintervall
300 Min.Das Beispiel umfasst fünf Stunden innerhalb des konfigurierten Supportfensters.
Verfolgen Sie Erstreaktions- und Lösungsziele für internen Support einschließlich Arbeitszeiten, zulässiger Wartezeiten und auffälliger Tickets.
Mit Beispieldaten erkunden. Felder, Ansichten und Workflows anpassen.
Berechnungsbeispiel, keine Aussage zur Kundenleistung.
Das Beispiel umfasst fünf Stunden innerhalb des konfigurierten Supportfensters.
Zwei zulässige Wartezeiten von 30 und 15 Minuten werden von der Lösungszeit abgezogen.
Die Beispielrichtlinie pausiert nicht bei Lieferantenabhängigkeiten.
300 − 45. Dies ist weder Arbeitsaufwand noch Erstreaktionszeit.
| Messgröße | Intervall | Berechnungsregel |
|---|---|---|
| Erste Reaktion | Meldezeitpunkt → erste dokumentierte Antwort | Arbeitsminuten; spätere Fortschrittsnotizen setzen die Erstreaktion nicht zurück. |
| Lösung | Aktueller aktiver Zyklus plus frühere aktive Zyklen | Ziehen Sie nur die laut erfasster Richtlinie zulässigen Wartegründe ab. |
| Geschlossenes Intervall | Lösung → Wiedereröffnung | Addieren Sie die geschlossene Lücke nicht zum neuen aktiven Zyklus. |
| Supportkalender | Montag–Freitag, ein tägliches Zeitfenster | Konfigurierte Schließtage ausschließen und erfassten UTC-Versatz verwenden. |
Wird die zweite zulässige Wartezeit von 15 auf 5 Minuten geändert, beträgt die Gesamtdauer desselben Beispiels 265 Minuten. Die Korrektur ändert die verknüpfte Ticketberechnung statt einen veralteten kopierten Wert zu hinterlassen.
Weitere 60 Arbeitsminuten nach der Wiedereröffnung werden zu den bisherigen 265 addiert und ergeben 325 Minuten. Das geschlossene Nachtintervall zählt nicht als aktive Lösungszeit.
Zielstatus und verknüpfte Eskalation zeigen, welche Zusage Aufmerksamkeit benötigt. Dokumentieren Sie die Maßnahme des Verantwortlichen; ein farbiger Status allein ist keine Reaktion.
Pflegen Sie eindeutige Schließtage. Das Beispiel unterstützt einen festen UTC-Versatz und ein Arbeitsfenster Montag–Freitag, nicht rotierende Schichten oder automatische Sommerzeitwechsel.
Aktive Tickets werden nach konfigurierbarem Zeitplan erneut geprüft; im Beispiel alle 15 Minuten. Dies ist keine Echtzeitüberwachung. Geplante und datensatzgesteuerte Prüfungen verbrauchen Automatisierungsläufe. Stimmen Sie Intervall und Tarif auf die Zahl aktiver Tickets ab.
Nein. Das Alter kann Nächte, Wochenenden, geschlossene Intervalle und zulässige Wartezeiten enthalten. Die Lösungsuhr folgt Arbeitskalender und Pausenregeln. Tatsächlicher Technikeraufwand wird getrennt protokolliert.
Das Beispiel erfasst eine ausdrückliche Aktivität „Erste Reaktion“. Ihre Richtlinie sollte definieren, was als aussagekräftige Antwort gilt, und einen automatischen Eingang nicht stillschweigend als menschliche Antwort werten.
Pflegen Sie Schließtage im Servicekalender. Die Arbeitszeitberechnung schließt übereinstimmende Daten aus. Prüfen Sie Kalender und festen UTC-Versatz vor vertraglicher Berichterstattung.
Nein. Es verwendet ein Arbeitsfenster Montag–Freitag und einen festen UTC-Versatz. Mehrere tägliche Schichten, Rotation, automatische Sommerzeit und komplexe Vertragskalender brauchen zusätzliches Design oder ein Spezialtool.
Datensatzänderungen lösen Neuberechnungen aus; aktive Tickets werden zusätzlich planmäßig geprüft, im Beispiel alle 15 Minuten. Die Erkennung kann bis zur nächsten Prüfung dauern und ist keine Echtzeit-Ausfallüberwachung.
Nein. Automatisierungsläufe und Datennutzung sind begrenzt. Multiplizieren Sie aktive Tickets mit geplanten Prüfungen und berücksichtigen Sie ereignisgesteuerte Automatisierungen, bevor Sie Intervall und Tarif wählen.
Prüfen Sie Berechnung und Wartehistorie und passen Sie Ziele, Arbeitszeiten und Eskalationsverantwortung an eine tragfähige Richtlinie an.