SLA und Performance
Sie koennen nicht verbessern, was Sie nicht messen. Levy Service erfasst SLA-Treue, MTTR (Mean Time to Resolve), Tech-Auslastung und Kosten pro Fahrzeug, damit Sie die Muster erkennen, die diese Metriken bewegen.
Wie SLAs berechnet werden
Jeder Task bekommt beim Erstellen einen sla_due_at-Zeitstempel. Die Rechnung lautet:
sla_due_at = created_at + DEFAULT_SLA_SECONDS[priority]
Default-SLAs pro Priority (in Sekunden):
| Priority | Default SLA |
|---|---|
critical | 4 Stunden (14400s) |
high | 24 Stunden (86400s) |
medium | 72 Stunden (259200s) |
low | 7 Tage (604800s) |
Diese Defaults liegen in src/lib/tasks/sla.ts als DEFAULT_SLA_SECONDS. Pro Regel ueberschreibbar, indem Sie sla_seconds in der Regel-Zeile setzen.
Der Breach-Detection-Cron
Der Cron /api/cron/task-sla-check laeuft alle 15 Minuten. Fuer jeden offenen Task, in dem sla_due_at < NOW():
- Schreibe eine Zeile in
task_sla_breaches, falls noch nicht verstossen - Setze
tasks.sla_breached_at = NOW() - Push-Notify den Assignee und den
ops_manager - Slack-Webhook des Verstosses, falls eine Webhook-URL konfiguriert ist
- (Phase 4) Auto-Eskalation an einen Vendor, falls die Regel das vorsieht
Ein Task kann nur einmal verstossen. Die Breach-Zeile ist der Audit-Datensatz.
Die Analytics-Seite lesen
Die Analytics-Seite unter /dashboard/tasks/analytics hat drei Hauptflaechen:
MTTR im Zeitverlauf
Ein Liniendiagramm mit der Mean Time to Resolve, aufgeschluesselt nach Task-Type, ueber die letzten 90 Tage. Die Ziellinie ist die SLA-Schwelle. Liegt Ihre Linie konstant unter der Schwelle, sind Ihre SLAs zu locker. Liegt sie konstant darueber, ist Ihr Team ueberlastet oder Ihre SLAs zu eng.
Bezogen aus GET /api/tasks/analytics/mttr.
Tech Leaderboard
Eine sortierbare Tabelle mit einer Zeile pro Tech, zeigt:
- Abgeschlossene Tasks (letzte 90 Tage)
- Durchschnittliche Resolve-Zeit
- Anzahl SLA-Verstoesse
- Gesamtkosten (Parts + Labor)
- Auslastung (% der erfassten Stunden mit aktivem Task)
Aus der materialisierten View technician_performance bezogen, naechtlich um 03:30 durch /api/cron/refresh-tech-performance aktualisiert. Das Leaderboard ist also bis zu ~24 Stunden alt - gut fuer Trendanalysen, nicht fuer Echtzeit-Personalplanung.
Cost-per-Vehicle Heatmap
Ein Heatmap-Grid, in dem jede Zelle ein Fahrzeug ist und die Farbintensitaet die Lifetime Maintenance Cost zeigt. Sortieren Sie nach Zone, Modell oder Fahrzeugalter, um Muster zu finden. Dunkelrote Zellen sind die Zitronen, die ausgemustert werden sollten.
Aus GET /api/tasks/analytics/cost-per-vehicle bezogen.
Die KPIs aus der Spec
| Metrik | Ziel | Quelle |
|---|---|---|
| MTTR - critical tasks | < 24h | tasks.closed_at - tasks.created_at where priority='critical' |
| MTTR - scheduled maintenance | < 72h | dieselbe |
% Fahrzeuge in maintenance zu einem Zeitpunkt | < 8% der aktiven Flotte | vehicles.status Rollup |
| Tech-Auslastung | > 60% der erfassten Stunden mit aktivem Task | task_assignments × Schichtlogs |
| Pro Tech-Tag abgeschlossene Tasks | > 6 | tasks group by assignee_id, day |
| % Tasks auto-erstellt durch Rule Engine | > 50% | tasks.created_by_rule_id IS NOT NULL |
| SLA-Breach-Rate | < 5% | task_sla_breaches Count / tasks Count |
| % Tasks mit Before+After Photos | > 90% | task_photos Join |
Sind Sie bei mehr als zwei davon ueber dem Ziel, sprechen Sie mit Ihrem Levy CSM - meist gibt es eine Konfig-Anpassung, die die Luecke schliesst.
SLAs pro Flotte anpassen
Die Default-SLAs gelten fuer alle Flotten, koennen aber pro Subaccount ueber die Seite Settings -> SLA Config ueberschrieben werden (Phase 5). Bis diese Seite ausgeliefert ist, setzen Sie eigene SLAs, indem Sie Regel-Zeilen direkt editieren:
- Oeffnen Sie die Regel unter
/dashboard/task-rules/[id] - Setzen Sie
sla_secondsauf den gewuenschten Wert - Speichern
Das neue SLA gilt fuer Tasks, die diese Regel kuenftig erzeugt - nicht rueckwirkend.
Notification-Muedigkeit
Wenn Sie 50 kritische Tasks gleichzeitig im SLA-Verstoss haben (es war ein schlechter Tag), batchen Expo-Pushes die Benachrichtigungen zu einem Digest, statt 50 einzelne Pushes zu spammen. Die Schwelle liegt bei 5 Verstoessen in 10 Minuten - darueber bekommen Sie einen Push, der sagt "12 SLA-Verstoesse in den letzten 10 Minuten, tippen fuer Details".
Slack-Benachrichtigungen werden nicht gebatcht; jeder Verstoss ist ein separater Webhook. Wird das laut, setzen Sie fuer Regeln niedriger Prioritaet action_config.notify_slack: false.
Langsame MTTR diagnostizieren
Drei haeufige Ursachen, wenn MTTR steigt:
- Tech-Mangel - Auslastung ueber 80%. Einstellen oder outsourcen.
- Schlechte Triage - zu viele Tasks sind
critical, obwohl siemediumsein sollten. Tunen Sie Ihre Regel-Prioritaeten. - Stuck
blockedTasks - Techs tippen auf Block, niemand unblockt. Filtern Sie das Kanban taeglich aufblocked.
Die Zielgroesse, die zaehlt
MTTR fuer kritische Tasks unter 24 Stunden. Jede andere Metrik folgt daraus. Wenn Sie das halten, ist Ihre Flotte gesund.