Ticketing ve Helpdesk Mimarisi: Bakım Sürecini Standardize Etmek

Ticketing; destek taleplerini tekilleştiren, sınıflandıran ve takip eden sistemdir. Support queue yönetimi yaklaşımıyla önemli olan “hangi aracı kullandığınız” değil; aracın içine koyduğunuz süreç mimarisidir. Çünkü aynı araç, doğru kurulmazsa yine WhatsApp’a döner.

Ne çözer?

• •“Kim bakıyor?” belirsizliğini azaltır (owner/assignee netleşir)
• •Öncelik kavgasını azaltır (P1–P4 tanımı)
• •“Bitti mi?” tartışmasını azaltır (resolved/closed kriteri)
• •SLA raporlama ile hizmet kalitesini ölçülebilir yapar

Soru : Ticketing sistemi nedir, bakım süreçlerinde neden önemlidir?

Cevap: Ticketing sistemi; bakım/destek taleplerini tek kanalda toplayıp kategori–öncelik–SLA alanlarıyla standardize eden, lifecycle içinde izlenebilir hale getiren yapıdır. Özellikle çağrı merkezi destek talepleri ve rezervasyon destek akışlarıyla birleştiğinde kaçan talebi azaltır; ayrıca SLA modelini bakım planına bağlamak için response/resolution sürelerini ölçmeyi sağlar.

☑ Mini Check

• •Taleplerin tek giriş kanalı var mı?
• •“P1 nedir?” herkes aynı şeyi mi anlıyor?
• •SLA raporu üretiliyor mu, yoksa “hissedilen hız” mı konuşuluyor?

Ticketing’in omurgası iki şeydir: kategori taksonomisi ve queue (kuyruk) mimarisi. Kategori, talebin “ne” olduğunu; queue ise “kim/hangi ekip”e gideceğini söyler. İyi tasarımın hedefi: minimum kategori ile maksimum netlik.

Ticket türleri (type): incident / request / change / question

• •Incident: hizmet kesintisi/bozulma
• •Request: istek (küçük geliştirme/ayar)
• •Change: planlı değişiklik (deploy/config)
• •Question: soru/danışma (bilgi talebi)

Bu ayrım, raporlamayı da temizler: “incident oranı artıyor mu?”, “change’ler incident’a mı dönüyor?” gibi sorular cevaplanır ve bakım ticket lifecycle içinde request ile release planı gerektiren değişiklikleri ayırmayı kolaylaştırır.

Örnek kategori seti (otel)

• •Website & CMS
• •Rezervasyon funnel’i
• •PMS/OTA entegrasyonları
• •Performans & CWV
• •Güvenlik & erişimler
• •Analytics/etiketleme

Örnek kategori seti (B2B)

• •Portal/UI
• •API & entegrasyon
• •Auth/permissions
• •Ödeme/checkout
• •Raporlama/veri
• •Performans/altyapı

Etiket (label) yaklaşımı: “kategori yerine etiketle”

Kategori sayısını şişirmek yerine; küçük ama anlamlı etiket seti kullanın: “season”, “payment”, “integration”, “seo”, “urgent-campaign” gibi. Bu yapı, otel dijital pazarlama taleplerinin ticket olarak yönetilmesi için kampanya ve landing page işlerini ayrı kuyrukta izlemeyi kolaylaştırır.

☑ Mini Check

• •Kategori sayısı 8–12 bandında mı (çok az/çok çok değil)?
• •Kategori ile queue birbirine karışıyor mu?
• •Etiketler raporlanabilir mi (çok serbest metin değil)?

Ticketing’in “operasyon motoru” burada başlar: P1–P4 + SLA. Bu helpdesk kategori öncelik yapısı, talebin iş etkisini önceliğe; response/resolution hedefini de ölçülebilir SLA kuralına dönüştürür.

P1–P4: iş etkisi odaklı kısa tanım

• •P1: Tam kesinti / gelir akışı durdu (otel: rezervasyon; B2B: ödeme/lead)
• •P2: Kritik degrade / ciddi iş kaybı riski (fiyat gelmiyor, CRM’e düşmüyor)
• •P3: Workaround var / orta seviye hata
• •P4: Düşük öncelik / kozmetik / planlı istek

Soru : Kategori ve öncelik yapısını nasıl kurmalıyım?

Cevap: Önce kategori (konu) setini belirleyip queue (ekip) eşlemesi yapın; sonra önceliği iş etkisiyle tanımlayın (P1–P4). Helpdesk’te type + category + priority + SLA alanlarını zorunlu yaparak standardı koruyun.

SLA alanları (minimum)

• •Response hedefi
• •Resolution hedefi
• •Mesai içi/dışı kuralı
• •SLA ihlal bayrağı (breach)
• •Escalation seviyesi (P1/P2 için)

☑ Mini Check

• •Priority seçimi serbest mi, yoksa kurallı mı (kriter/örnek var mı)?
• •SLA otomatik hesaplanıyor mu (takvim/iş saatleri) ?
• •P1/P2 için escalation zinciri ve iletişim kanalı tanımlı mı?

1 örnek (kısa)

• •Type: Incident | Category: Rezervasyon Funnel’i | Priority: P1 | SLA: response/resolution | Kanıt: hata ekranı + log | Resolved: workaround | Closed: preventive aksiyon

Kontrol listesi

• •Type/category/priority/SLA zorunlu alanlar set edildi
• •Queue eşlemesi tamamlandı
• •P1/P2 escalation kuralı yazıldı
• •Resolved/Closed kapı kriterleri tanımlandı
• •Aylık rapor metrikleri seçildi (SLA ihlal, backlog yaşı)

Deliverables

• •Field set dokümanı
• •kategori/queue matrisi
• •SLA hedef tablosu
• •lifecycle kuralı
• •rapor dashboard taslağı

Ticket lifecycle, “açıldı–bitti” arasında kaybolmayı engeller. Özellikle çok tedarikçili bakım koordinasyonu gereken yapılarda basit ama net bir lifecycle, sahiplik ve yönlendirme karmaşasını ciddi biçimde azaltır.

Temel lifecycle: Open → In Progress → Resolved → Closed

• •Open: Ticket açıldı, triage bekliyor
• •In Progress: Atandı, müdahale başladı
• •Resolved: Çözüm uygulandı, doğrulama bekliyor
• •Closed: Doğrulandı, raporlandı, gerekiyorsa iyileştirme aksiyonu çıkarıldı

Otel örneği: PMS/rezervasyon/website akışı

• •Open (P1): “Rezervasyon motoru hata”
• •In Progress: IT + ajans + tedarikçi koordinasyonu
• •Resolved: geçici çözüm (workaround) + doğrulama (mobil + çok dilli)
• •Closed: RCA kısa not + preventive aksiyon (izleme/alert, release gate)

B2B örneği: portal/API/entegrasyon akışı

• •Open (P2): “CRM entegrasyonu düşmüyor”
• •In Progress: log/queue inceleme
• •Resolved: mapping düzeltme
• •Closed: test senaryosu ekleme + monitor ekleme

Soru : Otel ve B2B projelerinde ticket lifecycle nasıl olmalı?

Cevap: Minimum lifecycle; Open→In Progress→Resolved→Closed olmalı. Resolved aşaması doğrulama (re-test) kapısı içerir; Closed ise raporlama, gerekirse RCA ve preventive aksiyon ekleme adımıyla kapanır.

☑ Mini Check

• •“Resolved” için doğrulama kriteri var mı?
• •“Closed” için raporlama/etiket şartı var mı?
• •P1/P2 ticket’larında postmortem tetikleniyor mu?

Ticketing’in değeri, raporda başlar. Destek kuyruğu performans raporlaması kurulmadığında raporlar sadece “ne kadar iş yaptık” seviyesinde kalır; oysa asıl hedef “neden böyle oldu, nasıl azalır?” sorusuna cevap vermektir.

İzlenecek temel metrikler

• •Ticket hacmi (kategori bazlı)
• •P1/P2 oranı
• •Ortalama response/resolution (SLA’ya göre)
• •SLA ihlal sayısı ve tekrar eden ihlal sınıfları
• •Backlog yaşı (aging) ve “unassigned” ticket sayısı
• •En çok tekrar eden 3 kök neden (etiket/RCA ile)

Key Statistics / Data Point (yumuşatılmış): Ticketing süreçleri oturan ekiplerde P1/P2 olaylara yanıt ve çözüm süreleri genelde düşer; “kaybolan/gözden kaçan talep” sayısı da belirgin şekilde azalır.

☑ Mini Check

• •Haftalık triage toplantısı var mı?
• •Aylık SLA raporu üretiliyor mu?
• •Tekrarlayan kategori/etiketler preventive aksiyon backlog’una dönüşüyor mu?

Piyasadaki içeriklerin çoğu “hangi aracı seçelim?” sorusunda kalır. Bu rehberin farkı; aracı değil, kategori/öncelik/SLA seviyesinde süreç mimarisini vermesidir: measurable operations, queue-based maintenance, standard field set. Böylece ekip büyüdüğünde de sistem çalışır.

Sonuç (özet)

Ticketing; talepleri kayıpsız toplar, kategori–queue ile yönlendirir, P1–P4 ve SLA ile ölçülebilir hale getirir, lifecycle ile kapanış standardı getirir. Raporlar da sürekli iyileştirme döngüsüne bağlanırsa, bakım süreci gerçek anlamda standardize olur. Bakım ve Destek hizmetiyle support queue yönetimini standartlaştırın ve uygulama detayları için Bakım ve Destek hakkında sık sorulan sorular sayfasına geçin.