SLA-Fristen-Rechner (Arbeitstage, Wochenenden und gesetzliche Feiertage)

Wenn „drei Tage“ eine Diskussion startet

Jemand meldet ein Ticket um 16:59 am Donnerstag. Der Vertrag sagt „Antwort innerhalb von drei Arbeitstagen“.
Die Hälfte zählt ab Freitag. Jemand anderes beginnt nach dem Wochenende. Eine dritte Person bringt einen Feiertag ins Spiel, den niemand im Kalender hatte.

Niemand ist faul. Die Formulierung hat den echten Kalender einfach nie getroffen.

Genau diese Lücke wollten wir mit dem SLA-Fristen-Rechner schließen - kein weiterer Datums-Picker, sondern ein gemeinsames Regelwerk: Land wählen (und Region, wenn nötig), wählen wie Ihr Team wirklich arbeitet, und das Tool läuft in Arbeitstagen vorwärts, während Wochenenden und Feiertage automatisch ausfallen.

Was Verträge oft stillschweigend offen lassen

Die meisten SLAs sind in Arbeitstagen formuliert, weil sie Kapazität messen wollen, nicht reine Kalenderzeit. Das Problem: „Arbeitstag“ sagt nichts über:

• ob die Uhr am Eingangstag startet oder am nächsten Arbeitstag
• welche Wochenenddefinition gilt (Fr-So vs. regionale Normen)
• welche Feiertagsliste gilt, wenn Menschen an unterschiedlichen Orten sitzen
• was passiert, wenn der „Start“ selbst auf einen Nicht-Arbeitstag fällt

Solange das nicht festgelegt ist, ist jede Tabelle eine private Meinung.

Das HolidayDB-Modell entspricht dem Rechner: Sie wählen einen Arbeitsplan (z. B. Mo-Fr, Mo-Sa, So-Do oder Sieben-Tage-Betrieb, der trotzdem Feiertage überspringt) und wo die Arbeit verankert ist, damit Feiertage nicht aus dem Gedächtnis erraten werden.

„Tag null“ - wo Teams leise auseinanderlaufen

Eine subtile Abweichung: Zählt das Eingangsdatum als erster Tag oder als Tag null vor dem Zählen?

Unser Rechner behandelt das Startdatum als Tag 0 und schreitet dann N Arbeitstage entlang gültiger Arbeitstage vor. Eine SLA von einem Arbeitstag ab einem arbeitenden Donnerstag landet meist am Freitag - nicht „Donnerstag überspringen und Montag treffen“, es sei denn, Donnerstag ist in Ihrer Konfiguration kein Arbeitstag.

Das ist nicht die einzige Konvention draußen - aber sie ist konsistent zwischen Rechner-Oberfläche und dem Endpoint GET /api/sla-deadline - und das zählt mehr, als es klingt. Wenn Support, Legal und Engineering dieselbe Ausgabe lesen, verbringen Sie weniger Zeit mit Tool-Abgleich.

Regionen zählen, auch wenn das Land gleich heißt

Nationale Feiertage sind nur ein Teil. Regeln auf Subdivisionsebene - Bundesländer, Kantone, Provinzen - können zwei Schreibtische im „gleichen“ Land in derselben Woche unterschiedliche Arbeitswochen haben.

Wenn Ihre SLA an den Ort der Arbeit oder des Kunden gebunden ist, gehört das von Anfang an in die Berechnung. Sonst liefern Sie eine „globale“ Richtlinie, die still eine Büro-Kalenderlogik bevorzugt.

Wenn Copy-Paste nicht mehr reicht

Das Tool auf der Seite ist für Menschen, die schnell eine Antwort brauchen. Wenn dieselben Regeln in Abrechnung, Ticketing oder Compliance laufen sollen, binden Sie GET /api/sla-deadline ein (siehe Dokumentation: SLA-Frist) mit denselben Parametern wie interaktiv - Land, optionale Subdivision, Startdatum, SLA-Länge in Arbeitstagen, Plan und Sprache, wo unterstützt.

Feiertagskalender bleiben mit GET /api/holidays synchron - keine CSVs, die jedes Budgetjahr veralten.

Ausprobieren

Öffnen Sie den SLA-Fristen-Rechner und testen Sie Szenarien, über die Sie in Meetings wirklich gestritten haben - Freitags-Starts, lange Wochenenden, „dieselbe“ SLA in zwei Regionen. Stimmen die Ergebnisse mit dem überein, wie Ihr Team die SLA gemeint hat, haben Sie eine Baseline, auf die Sie verweisen können. Wenn nicht, haben Sie eine Mehrdeutigkeit gefunden, die sich lohnt, im Vertrag zu klären, bevor die nächste Eskalation kommt.