WSKAŹNIK KPI · CZAS ROZWIĄZANIA · HELPDESK
TTR — Time to Resolution, czyli całkowity czas rozwiązania sprawy
Czas od otwarcia zgłoszenia do jego zamknięcia — jeden z fundamentalnych KPI helpdesku. Różni się od FRT (czas pierwszej odpowiedzi) — sprawa może być szybko odebrana, ale długo czekać na rozwiązanie.
Definicja
TTR to całkowity czas od zarejestrowania zgłoszenia w systemie ticketowym do jego ostatecznego zamknięcia, obejmujący wszystkie interakcje, eskalacje i czas oczekiwania.
Jak TTR działa w praktyce
TTR mierzy się w godzinach biznesowych (nie kalendarzowych) — system ticketowy automatycznie odlicza czas tylko w godzinach pracy i pomija weekendy, święta oraz okresy zawieszenia („czekamy na klienta”, „czekamy na dostawcę”). Bez tego mechanizmu TTR rośnie sztucznie dla zgłoszeń otrzymanych w piątek wieczorem.
Średni TTR silnie zależy od kategorii sprawy i powinien być mierzony osobno. Przykładowe benchmarki: zapytania ogólne — 1-4h, błędy software — 1-3 dni, eskalacje produktowe — 5-10 dni, reklamacje regulacyjne — 14-30 dni. Mierzenie jednego średniego TTR dla całego helpdesku to częsty błąd — ukrywa problemy w konkretnych kategoriach.
TTR różni się od TTR-First Response (synonimu FRT). Sprawa może mieć FRT = 15 min ale TTR = 5 dni jeśli wymaga eskalacji do developera. Wysoki TTR przy niskim FRT to typowy sygnał problemów z procesem eskalacji lub uprawnieniami pierwszej linii wsparcia.
Co obniża TTR: knowledge base dostępna agentom (mniej eskalacji), routing oparty na kompetencjach (sprawa od razu do właściwej osoby), uprawnienia decyzyjne agentów (mniej wąskich gardeł u managera), integracje z systemami zewnętrznymi (CRM, ERP — bez przełączania kontekstu).
Benchmark branżowy
| Poziom | Wartość | Komentarz |
|---|---|---|
| Zapytania proste | 1-4h | Zwykłe pytania, status zamówienia, hasła |
| Błędy oprogramowania | 1-3 dni | Wymagają diagnostyki, czasem eskalacji |
| Eskalacje produktowe | 5-10 dni | Złożone wymagające angażowania zespołu R&D |
| Reklamacje regulacyjne | 14-30 dni | RODO, rękojmia, sprawy prawne |
Jak Debesis pomaga skrócić TTR
System ticketowy Debesis automatycznie liczy TTR per kategoria, priorytet i klient — z uwzględnieniem godzin biznesowych. Routing kieruje sprawy do najlepiej wykwalifikowanego agenta przy pierwszym kontakcie, redukując potrzebę eskalacji o 30-40%. Workflow automatyzuje powtarzalne kroki (powiadomienia, status updates, alerty SLA), uwalniając agentów do faktycznej pracy. Klienci raportują redukcję średniego TTR o 25-35% w pierwszych 6 miesiącach.
Zobacz system ticketowy z pomiarem TTR →Najczęstsze pytania
Czy TTR mierzymy w godzinach kalendarzowych czy biznesowych?
Zawsze w biznesowych. Sprawa otwarta w piątek o 17:00 z SLA 4h ma termin nie o 21:00, ale o 11:00 w poniedziałek. System ticketowy musi obsługiwać kalendarz pracy, święta i strefy czasowe. Mierzenie TTR w godzinach kalendarzowych daje zafałszowane wyniki.
Jak liczyć TTR gdy sprawa była zawieszona „czekamy na klienta”?
Czas zawieszenia nie liczy się do TTR. System pauzuje zegar gdy status sprawy zmienia się na „Pending Customer” lub „Pending Vendor” — wznawia gdy klient odpowie. Bez tego TTR rośnie sztucznie i ukrywa problemy operacyjne.
Czy TTR koreluje z CSAT?
Słabiej niż FCR. Klient woli długą sprawę dobrze rozwiązaną (TTR 5 dni, CSAT 5/5) niż szybką źle (TTR 2h, CSAT 2/5). Najsilniejszy predyktor CSAT to nie szybkość, a poczucie progresu — regularne updates statusu utrzymują wysoki CSAT nawet przy długim TTR.