Az on-call (ügyelet) igazi értéke nem csak az, hogy “éjjel megfogtuk a bajt”, hanem az, hogy másnap ne ugyanaz történjen meg újra. Ha nincs debrief és posztmortem, az ügyelet csak tűzoltás: megoldotok valamit, továbbmentek, majd ugyanaz visszajön – csak nagyobban, rosszabb időpontban, több kár mellett. A posztmortem pont ezért kell: nem hibást keres, hanem rendszert javít.

A jó posztmortem rövid, tényszerű, és akciókat eredményez. Nem történetmesélés, nem kifogáslista, nem egymásra mutogatás. Cél: egyértelműen rögzíteni mi történt, miért történt, mit csinálunk, hogy ne történjen újra, és ki felel érte, mikorra.

A Telex Center Kft. üzemekben a posztmortem azért működik, mert egyszerű: fix sablon, fix időkeret, fix felelősségek. Így az on-call nem “viszi” az energiát, hanem visszaadja: kevesebb zaj, stabilabb SLA, jobb CSAT, kevesebb eszkaláció.

1) Debrief vs posztmortem: mi a különbség?

Debrief (gyors, 10–15 perc, másnap reggel)

Cél: azonnali tisztázás, hogy:

• mi maradt nyitva,
• mit kell reggel átadni,
• van-e azonnali kockázat,
• kell-e ügyfélkommunikáció.

Posztmortem (strukturált, 30–60 perc, 24–72 órán belül)

Cél: rendszerjavítás.

• gyökérok (root cause)
• folyamat hibák
• monitoring/riasztás hibák
• tudásbázis/script hiány
• akcióterv tulajdonossal

A kettő együtt ad stabil működést.

2) Mikor kötelező posztmortem?

KKV-knál is érdemes küszöböt rögzíteni. Példa:

Kötelező posztmortem, ha:

• P0 volt
• adatvédelmi vagy security gyanú felmerült
• tömeges ügyfélimpact volt
• a containment 60 percnél tovább tartott
• social/public panasz hullám lett
• kompenzációt kellett adni
• ugyanaz a hiba 30 napon belül ismétlődött

Ha mindent posztmortemezel, elinflálódik. Ha semmit, nem tanultok.

3) A posztmortem 7 szabálya (hogy ne legyen cirkusz)

1. Blameless: nem hibást keresünk, rendszert javítunk.
2. Tények: időbélyeges timeline, nem vélemény.
3. Egy owner: valaki felel a dokumentumért és a follow-upért.
4. Action item csak ownerrel és határidővel.
5. Kevesebb, de biztos akció: 3–7 jó akció jobb, mint 30 “majd”.
6. Monitoring és tudásbázis mindig vizsgálat tárgya.
7. Visszamérés: következő review időpont rögzítve.

4) Debrief sablon (10–15 perc, reggeli átadásra)

Debrief – rövid összefoglaló

• Mi történt (1 mondat):
• Prior (P0/P1):
• Jelenlegi állapot:
• Mi van még nyitva:
• Következő lépés:
• Owner reggelre:
• Ügyfélkommunikáció kell? (igen/nem)
  • Ha igen: mit és mikor?

Ezt küldöd reggel a felelősnek / csapatnak, ticket linkekkel.

5) Posztmortem sablon (CTRL+C / CTRL+V használatra)

POSZTMORTEM – [INCIDENT NEVE]

1. Meta

• Dátum:
• Incident ID / Ticket ID:
• Prior: P0 / P1
• Incident Commander:
• Résztvevők:
• Érintett rendszerek / csatornák:

2. Rövid összefoglaló (max 5 sor)

• Mi történt?
• Kit érintett?
• Mekkora volt az impact?
• Mikor lett stabilizálva?

3. Impact (konkrét számok)

• Érintett ügyfelek száma (becslés):
• Érintett rendelések / tranzakciók:
• Bevételkiesés (becslés):
• Reputációs hatás (social, PR):
• Support terhelés (kontaktok száma, queue time):

4. Timeline (időbélyeges, tények)

• HH:MM – Jelzés beérkezett (honnan? monitoring/ügyfél/social)
• HH:MM – Acknowledge (ki?)
• HH:MM – Első intézkedés (mi?)
• HH:MM – Eskaláció (kinek? miért?)
• HH:MM – Workaround / containment lépés
• HH:MM – Status kommunikáció (mit mondtunk?)
• HH:MM – Stabil állapot elérve
• HH:MM – Végleges megoldás (ha volt)
• HH:MM – Lezárás

5. Root cause (gyökérok)

• Mi volt a közvetlen ok?
• Mi volt a mögöttes ok?
• Miért nem fogtuk meg hamarabb? (1–3 mondat)

6. Detection és monitoring

• Mi jelezte először az incidenst? (monitoring/ügyfél/social)
• A riasztás megfelelő priorral jött? (igen/nem)
• Volt zaj/duplikáció/flapping? (igen/nem)
• Mit kell változtatni a riasztásokon?

7. Response és folyamat

• A triázs jó volt? (igen/nem) – Miért?
• Az eszkaláció jó volt? (igen/nem) – Miért?
• A timebox szabályt betartottuk? (igen/nem)
• Volt-e kommunikációs hiba? (igen/nem) – Mi?
• Volt-e adatvédelmi kockázat? (igen/nem) – Mi?

8. Tudásbázis és script

• Volt megfelelő runbook / döntési fa? (igen/nem)
• Ha nem: melyik hiányzott?
• Melyik script/makró kellett volna?
• Mit kell frissíteni a tudásbázisban?

9. Mi ment jól (max 5 pont)

10. Mi ment rosszul / mi volt a szűk keresztmetszet (max 5 pont)

11. Action items (KÖTELEZŐ owner + határidő)

1. Teendő:
   Owner:
   Határidő:
   Mérhető eredmény:
2. Teendő:
   Owner:
   Határidő:
   Mérhető eredmény:
3. Teendő:
   Owner:
   Határidő:
   Mérhető eredmény:

(ideális: 3–7 akció)

12. Kompenzáció / ügyfélkezelés (ha volt)

• Mit adtunk?
• Kinek?
• Mi volt a döntési alap?
• Kell-e utókövetés?

13. Visszamérés (következő kontroll)

• Review időpont:
• Ki ellenőrzi?
• Milyen KPI-t nézünk? (MTTA, containment idő, false P0, repeat incident, CSAT)

14. Lezárás

• Posztmortem készítő:
• Jóváhagyó:
• Dátum:

6) Tipikus “posztmortem hibák” (amit kerülj)

• túl hosszú narratíva, kevés tény
• nincs szám (impact becslés nélkül üres)
• nincs owner és határidő
• túl sok akció, senki nem csinálja meg
• nincs monitoring javítás (pedig majdnem mindig kell)
• nincs tudásbázis frissítés (pedig a frontline ebből tanul)

7) Hogyan legyen ebből rendszer?

Heti 1 fix időpont 30 perc:

• nyitott action itemek státusza
• repeat incidentek
• riasztási zaj alakulása
• tudásbázis frissítések

Így a posztmortem nem “papír”, hanem javulás.