Az ügyelet (on-call) bevezetése KKV-ként nem “nagyvállalati projekt”. Akkor működik, ha egyszerű, betartható, és az első naptól mérhető. A rossz ügyelet vagy túl bonyolult (senki nem követi), vagy túl laza (mindenki azt csinál, amit gondol). A jó ügyelet ezzel szemben egy kontrollált rendszer: pontosan tudjuk, mi számít vésznek, ki felel érte, mennyi időn belül kell reagálni, hogyan dokumentálunk, és mikor eszkalálunk.

A cél nem az, hogy “mindig legyen ember”. A cél az, hogy amikor tényleg baj van, ne legyen káosz. És ne legyen olyan, hogy reggel derül ki: éjjel fél órán át állt a fizetés, vagy elment egy VIP ügyfél, vagy egy incidensből PR-botrány lett.

A Telex Center Kft. akkor tud stabil ügyeleti üzemet adni KKV-knak, ha az ügyeletet nem különálló “készenléti telefonnak” kezeljük, hanem a support működés részének: triázs, priorok, eszkaláció, riasztási higiénia, script, ticket és posztmortem. Ez a cikk egy 30 napos, lépésről lépésre checklist, amit egy KKV is végig tud vinni.

1) Mielőtt elkezded: 5 alapdöntés (különben borulni fog)

1. Milyen időt fed le az ügyelet?
   • csak 18–08?
   • hétvége is?
   • ünnepnap is?
2. Mi számít P0/P1/P2-nek?
   • mi ébreszt fel, mi nem?
3. Ki az ügyeletes szerepkör szerint?
   • L1, L2, supervisor?
4. Milyen csatornán jön riasztás?
   • telefon/SMS csak P0-ra?
5. Hol és hogyan logolsz mindent?
   • ticket + incident log, másnap kézbe vehetően

Ha ez nincs tisztán kimondva, az ügyelet “szokásjog” lesz. A szokásjog pedig szétesik.

---

30 napos ügyelet bevezetési checklist (napi bontásban)

1. hét (Nap 1–7): alapok és szabályok

Nap 1: Éjjeli valóság feltérképezése

• Mely csatornákon jönnek éjjel kontaktok? (chat, email, telefon, social)
• Melyik 10 ügytípus a leggyakoribb munkaidőn túl?
• Melyik 5 ügytípus a legnagyobb üzleti kockázat?

Nap 2: Priorok rögzítése (P0/P1/P2/P3)

• P0 definíció 10 példával (max 10, ne több)
• P1 definíció 10 példával
• P2/P3 definíció, és kimondva: P2/P3 nem ébreszt
• “Piros gomb” lista (adatvédelem, payment down, fraud hullám)

Nap 3: SLA célok (ack és containment)

• P0 ack cél (pl. 10–15 perc)
• P0 containment cél (pl. 30–60 perc)
• P1 ack cél (pl. 15–30 perc)
• P1 containment cél (pl. 60–120 perc)
• Mit jelent containment nálatok? (workaround/status/parkolás+ETA)

Nap 4: Szerepkörök és felelősségek (L1/L2/Supervisor)

• L1 feladatlista: triázs, adatbekérés, ticket, alap workaround
• L2 feladatlista: technikai lépések, hozzáférés, workaround/rollback
• Supervisor feladatlista: döntés, kompenzáció, kommunikáció, posztmortem
• Ki az Incident Commander P0 esetén? (1 név, nem “valaki”)

Nap 5: Riasztási csatornák és mátrix

• P0 csatorna: telefon/SMS + chat + ticket
• P1 csatorna: chat + fallback telefon (ha nincs reakció X perc)
• P2 csatorna: ticket/email
• Dedupe szabály (ugyanarra 30 perc alatt 1 ébresztés)
• Flapping szabály (csak ha 3–5 percig fennáll)

Nap 6: Eskalációs csomag sablon (copy-paste)

• Prior (P0/P1)
• Impact (hány ügyfél / bevétel / reputáció)
• Tünet 2 mondatban
• Azonosítók (ticket, order, log link)
• Mit próbáltunk (max 3)
• Mit kérünk (döntés/hozzáférés/workaround)
• ETA/next update időpont

Nap 7: Incident log + posztmortem minimum

• Incident log formátum (timeline + döntések + kommunikáció)
• Posztmortem sablon (mi történt, miért, mit teszünk, határidő, owner)
• Reggelei handover rutin (ki, mikor, hogyan kapja meg)

---

2. hét (Nap 8–14): tudásbázis, scriptek, és “night mode” keretek

Nap 8: Top 10 runbook (1 oldal / eset)

• Payment hiba
• Rendszerleállás / 5xx spike
• Fraud / gyanús belépés
• Logisztikai csúszás kritikus ügyféllel
• Public social krízis
• (és a saját 5 leggyakoribb P1 eseted)

Nap 9: Döntési fák a runbookok elé

• 3–5 kérdéses döntési fa minden top esetre
• Stop pont PII/fraud esetekre
• Kimenet: megoldás / parkolás+ETA / eszkaláció

Nap 10: Script-makrók csatornánként

• Chat: rövid, kontrollt adó mondatok
• Telefon: 2 kérdéses triázs, rövid lépések
• Email: bulletpoint, ETA, ticket ID
• Social: public válasz + privát terelés sablon

Nap 11: Adatvédelem “night mode”

• Tiltólista (kártyaadat, jelszó, kód, túl sok PII)
• Jogosultságok: L1 csak minimum adatot lát
• Break-glass hozzáférés (időkorlát, indok, log)
• Képernyőkép bekérés szabály (kitakarás kérés)

Nap 12: Alert-higiénia gyors rendbetétel

• Top 20 riasztás audit (melyik a zaj)
• Duplikációk kivágása
• Küszöbök finomhangolása (éjjel/nappal külön)
• P2/P3 átirányítása digestbe

Nap 13: Kompenzáció és ígéret szabály

• Mit ígérhet L1? (ETA sáv, ticket, workaround)
• Kompenzáció csak supervisor jóváhagyással
• Fix dátum tilalom, ha nem biztos
• Standard “status update” szöveg P0-ra

Nap 14: Tréning (rövid, de kötelező)

• 60–90 perces tréning a teljes csapatnak
• 10 kérdéses mini teszt (priorok, tiltólista, eszkaláció)
• 2 szimuláció: payment down + social krízis

---

3. hét (Nap 15–21): pilot üzem és finomhangolás

Nap 15: Pilot indul (kijelölt időablak)

• Ügyeletes roták rögzítése (ki mikor)
• Backup kijelölése (ha nem elérhető az ügyeletes)

Nap 16: KPI panel beállítása

• MTTA (ack)
• Time to contain
• MTTR (ha releváns)
• False P0 arány
• Riasztás darabszám / éj

Nap 17: Első éles nap utáni review (15 perc)

• Mi volt zaj?
• Mi volt félrepriorizált?
• Hol hiányzott runbook/script?

Nap 18: Runbook frissítés (top hibák alapján)

• 2 runbook javítása
• 2 script makró javítása

Nap 19: Eskalációs timebox finomhangolása

• L1 mennyi ideig próbálkozzon P1-nél?
• Mikor kötelező L2?
• Mikor kell supervisor?

Nap 20: Riasztási zaj további csökkentése

• Flapping beállítások
• Dedupe window
• “for X minutes” rögzítése

Nap 21: Pilot összegzés és döntés

• Mi működött?
• Mi nem?
• Melyik 3 módosítás kell a végleges induláshoz?

---

4. hét (Nap 22–30): stabilizálás és végleges indulás

Nap 22: Végleges roták (igazságos, fenntartható)

• Rotaszabály (ne legyen túl sűrű)
• Cserefolyamat (ha valaki kiesik)

Nap 23: Napi handover rend

• Reggeli összegzés sablon
• Ticketek státusza és owner kijelölés
• Nyitott incidentek listája

Nap 24: QA és mintavételezés éjjelre is

• Heti X db ügy ellenőrzése
• Script és tiltólista betartás
• Visszacsatolás 24 órán belül

Nap 25: “Peak/incident” mód aktiválási szabály

• Mikor kapcsolunk war room-ra?
• Ki vezeti?
• Milyen gyakran megy status update?

Nap 26: Kommunikációs sablonok ügyfél felé

• Status üzenet P0-ra
• ETA üzenet P1-re
• Parkolás + reggeli ígéret P2-re
• Social public válasz + privát terelés

Nap 27: Posztmortem rutin élesítése

• P0 után 24–48 órán belül posztmortem
• Action item owner + határidő
• Következő heti ellenőrzés

Nap 28: “Ügyelet egészség” szabályok

• Maximum ébresztések / éj cél
• “Noise budget” rögzítése
• Burnout jelzések és cserefolyamat

Nap 29: Végső próba (szimuláció)

• Payment down szimuláció
• Fraud gyanú szimuláció
• Social krízis szimuláció
• Logolás + eszkaláció ellenőrzése

Nap 30: Go-live

• Ügyelet indul
• KPI panel aktív
• Review időpont 7 nap múlva
• Review időpont 30 nap múlva