escalation

Structure and package support escalations for engineering, product, or leadership with full context, reproduction steps, and business impact. Use when an issue needs to go beyond support, when writing an escalation brief, or when assessing whether an issue warrants escalation.

1. Oceń, czy problem powinien być eskalowany. Sprawdź, czy ma udokumentowane rozwiązanie lub znany workaround — jeśli tak, rozwiąż na poziomie supportu. Eskaluj gdy: potwierdzisz błąd wymagający poprawki kodu, problem wymaga dostępu poza możliwości supportu, dotyczy wielu klientów lub systemu produkcyjnego, grozi naruszeniem SLA, lub zgłaszało go 3+ klientów.
2. Zbierz wszystkie niezbędne informacje: podsumowanie zgłoszenia, kroki już podjęte, kontekst klienta, dokładne kroki reprodukcji problemu, oraz oszacowanie wpływu biznesowego (liczba dotkniętych klientów, ryzyko dla danych, znaczenie dla przychodu).
3. Określ właściwy poziom eskalacji. Dla problemów wymagających głębszej analizy i specjalistycznej wiedzy użyj L2 (senior support). Dla kwestii wymagających zmian kodu, dostępu infrastrukturalnego lub zaangażowania kierownictwa użyj L3 (engineering, product, leadership).
4. Strukturyzuj brief eskalacyjny zawierający: jasne podsumowanie problemu, pełne kroki reprodukcji, dotychczasowe próby rozwiązania, kontekst klienta (typ, wartość, SLA), oraz konkretny wpływ biznesowy i techniczny.
5. Przekaż brief odpowiedniemu zespołowi z całym kontekstem, aby mogli działać szybko bez dodatkowych pytań. Śledzenie eskalacji do rozwiązania pozostaje Twoją odpowiedzialnością.