Éjjeli eszkalációs fa: kinek szóljunk és hogyan?

Éjszaka a support nem “kevesebb emberrel nappali működés”. Éjszaka külön szabályrendszer kell, mert a legnagyobb veszteség nem az, hogy lassabb a válasz, hanem az, hogy rossz emberhez, rossz időben, rossz információval eszkalálsz. Ettől lesz pingpong, csúszás, ideges ügyfél, és végül CSAT-esés.

A jó éjjeli eszkalációs fa (escalation tree) három dolgot ad:

  1. Döntési logika (mi P0, mi P1, mi parkolható)
  2. Útvonal (kinek szólsz, milyen sorrendben)
  3. Csomagolt információ (mit kell elküldeni, hogy azonnal lehessen dönteni)


1) Miért bukik el az eszkaláció éjjel?

Az eszkaláció tipikusan 4 okból rohad el:

1.1 Nincs egységes “mi számít vésznek” definíció

Mindenki mást gondol P0-nak → vagy minden P0 (zaj), vagy semmi (késés).

1.2 Rossz csatorna

Emailben riasztanak P0-t. Vagy csak chat, amit az on-call nem néz.

1.3 Nincs csomag (context)

“Valami gond van” jellegű üzenetek → az on-call visszakérdez → csúszás.

1.4 Nincs timebox

L1 túl sokáig próbálkozik, mire eszkalál – addig az ügyfél már felrobbant.


2) Az éjjeli eszkalációs fa alapmodellje (3 szint)

A legegyszerűbb, de profi struktúra:

  • L1 (Frontline/Anchor): triázs, containment, alap megoldások
  • L2 (Specialist on-call): technikai/logisztikai/pénzügyi szakmegoldás
  • Supervisor on-call: döntés, kompenzáció, krízis, “final call”

Plusz opcionálisan:

  • Security on-call (ha van külön)
  • IT on-call (SaaS, webshop, infra)

A lényeg: L1 ne maradjon döntési jog nélkül.


3) P0/P1/P2 éjszakára – hogy legyen közös nyelv

P0 – Kritikus (azonnal)

  • adatvédelmi incidens gyanú / PII kiszivárgás
  • fraud / account takeover / ismeretlen terhelés
  • rendszerleállás (sok ügyfelet érint)
  • fizetés teljesen down (konverzió stop)
  • fizikai biztonsági kockázat (termék, szolgáltatás)

Cél: MTTA (time to acknowledge) 10–15 perc.

P1 – Magas (üzlet/reputáció)

  • checkout hiba egyedi ügyfélnél (menthető)
  • nyilvános social krízis (pörgő komment)
  • B2B ügyfél “nem tud dolgozni”
  • kritikus logisztikai elakadás (pl. expressz)

Cél: 15–30 perc reakció.

P2 – Normál (parkolható)

  • számlázás
  • refund kivizsgálás
  • admin / tájékoztatás

Cél: ticket + ETA.


4) A fa: kinek szólsz és hogyan? (lépésről lépésre)

4.1 L1 döntési lépések (minden ügyre)

  1. Azonosítás + adatminimalizálás (rendelés ID, email)
  2. Triázs besorolás (P0/P1/P2)
  3. Megoldási kísérlet timeboxszal
  4. Eszkaláció (ha kell)
  5. Dokumentálás (incident log / ticket)

Timebox irányadó

  • P0: 0–5 perc L1 próbálkozás (inkább containment), utána eszkaláció
  • P1: 10–15 perc L1 próbálkozás, utána L2
  • P2: nincs eszkaláció, ticket

4.2 P0 útvonal (példa)

L1 → (azonnal) Security/IT on-call → Supervisor on-call (ha döntés kell)

Riasztási csatorna:

  • elsődleges: telefon/SMS/pager jellegű riasztás
  • másodlagos: Teams/Slack “P0” csatorna
  • tiltott: email (P0-ra)

4.3 P1 útvonal (példa)

L1 → L2 on-call → Supervisor (ha kompenzáció/krízis)

Riasztási csatorna:

  • Teams/Slack + fallback telefon, ha 10 percen belül nincs reakció.

4.4 P2 útvonal

Ticket + ETA + reggeli handover
Nincs éjjeli ébresztgetés admin ügyek miatt.


5) “Hogyan szóljunk?” – a csomagolt eszkalációs üzenet (template)

Az eszkaláció akkor gyors, ha ugyanazt a 7 mezőt mindig elküldöd.

P0/P1 eszkalációs üzenet sablon (copy-paste)

  • Szint: P0 / P1
  • Ügytípus: (fraud / checkout / rendszer / social / logisztika)
  • Impact: hány ügyfél, mekkora kár / reputáció kockázat
  • Azonosítók: rendelés ID / ügyfél ID / csatorna link
  • Mi történt: 2 mondat
  • Mit próbáltunk: checklist (max 3 pont)
  • Mit kérünk: döntés / hozzáférés / workaround / jóváhagyás

Példa (P1 checkout):

  • Szint: P1
  • Ügytípus: Checkout/payment error
  • Impact: 1 ügyfél, magas kosár (≈ 85.000 Ft), konverzióvesztés kockázat
  • Azonosítók: Order draft #— / email — / chat link
  • Mi történt: Fizetésnél “payment failed” hiba, 2 külön kártyával is
  • Mit próbáltunk: böngészőváltás, új fizetési link, cache törlés
  • Mit kérünk: Payment provider status + javasolt workaround / manuális link

Ettől az on-call azonnal tud lépni.


6) Riasztási csatornák: mivel érdemes dolgozni éjjel?

Nem az eszköz a lényeg, hanem a redundancia.

6.1 Minimum csatorna-készlet

  • Chat csatorna (Teams/Slack): kontext, log, linkek
  • Telefon/SMS: “felébresztés” P0-ra
  • Ticketing: nyomkövetés és handover

6.2 Fallback szabály

Ha L2 nem reagál X percen belül:

  • P0: 10 perc → Supervisor/2. on-call személy
  • P1: 15 perc → Supervisor

Így nincs “láttam, de nem értem rá”.


7) Incident log és postmortem: éjszaka kötelező (különben ismétlődik)

7.1 Incident log minimum

  • timestamp
  • P-szint
  • impact
  • eszkalációk (ki, mikor)
  • megtett lépések
  • ügyfélkommunikáció (mit ígértünk)
  • next step reggelre

7.2 Postmortem “light” hétfőn (10 perc)

  • mi volt az ok?
  • mi az 1 megelőző változtatás?
  • ki a felelős + határidő

A Telex Center Kft. jellegű profi üzemeknél ez adja a folyamatos javulást.


8) Zajcsökkentés: ne égess ki mindenkit eszkalációval

Az eszkalációs fa akkor jó, ha nem generál felesleges riasztásokat.

8.1 Escalation hygiene szabályok

  • P2 soha nem ébreszt
  • P1 csak timebox után
  • P0 mindig csomagolt üzenettel
  • “érzés” helyett trigger lista

8.2 “One escalation owner”

Egy ügynek egyszerre csak egy gazdája van, különben párhuzamos rángatás lesz.


9) KPI-k az eszkalációra: honnan tudod, hogy működik?

9.1 Sebesség

  • MTTA: time to acknowledge (észlelték-e időben)
  • MTTR: time to resolve (vagy stabilizálás)

9.2 Minőség

  • eszkaláció pontosság (jó P-szint?)
  • re-escalation arány (átpasszolták-e)
  • ügyfél visszajelzés (CSAT P0/P1 után)

9.3 Zaj

  • riasztások száma / éj
  • false positive P0 arány

10) 21 napos bevezetés: éjjeli eszkalációs fa élesítés

1. hét: definíciók és lista

  • P0/P1/P2 definíció
  • trigger lista (fraud, payment, social, incident)

2. hét: csatornák és sablonok

  • riasztási csatornák + fallback
  • eszkalációs message template
  • incident log

3. hét: pilot + QA

  • 2–3 éjszaka pilot
  • KPI-k mérése (MTTA/MTTR)
  • finomhangolás (timebox, trigger-ek)

A Telex Center Kft. ebben partner: eszkalációs fa testreszabása, on-call rend, tréning, QA és riport.


11) Zárás: éjjel az eszkaláció legyen rövid, egyértelmű, csomagolt

A jó éjjeli eszkaláció nem több üzenet.
Hanem: jó besorolás + jó csatorna + jó csomag + timebox.

Ha szeretnél egy cégedre szabott éjjeli eszkalációs fát (P0/P1/P2, on-call rend, sablonok, KPI-k), ebben a Telex Center Kft. partner.

Ajánlatért keressen minket: https://telexcenter.hu/kapcsolat/