Yardım Masası Yazılımı: Ticket ve SLA Rehberi

Destek talepleri e-posta, form ve telefonla dağılmaya başladığında sorun, sohbet penceresinin eksikliği değil; talebin kimde olduğu, ne kadar sürdüğü ve aynı sorunun kaç kez tekrarlandığının bilinmemesidir. Bu noktada yardım masası yazılımı, canlı sohbet arayüzünden farklı olarak ticket yaşam döngüsü, SLA, kategori, varlık kaydı ve bilgi bankası etrafında bir hizmet masası kurmanızı sağlar. Bu rehber, KOBİ, e-ticaret ve kurumsal ekiplerin iç destek ile müşteri destek kuyruklarını ayırarak doğru kapsamı tanımlamasına yardımcı olur.

Yardım masası yazılımı canlı destekten nasıl ayrılır?

Canlı destek, anlık mesajlaşmayı ve hızlı yanıtı öne çıkarır. Yardım masası ise işi kayda alır, sınıflandırır, birine atar, süre taahhüdü koyar ve kapanışa kadar izler. İkisini aynı panelde toplayan ürünler vardır; yine de satın alma kararını verirken soracağınız soru şudur: “Asıl ihtiyacım anlık sohbet mi, yoksa izlenebilir iş emri mi?”

Pratik ayrım şöyle düşünülebilir. Canlı kanal, “siparişim nerede?” gibi dakikalar içinde çözülebilen sorular için uygundur. Yardım masası kanalı, “sisteme giriş alamıyorum”, “pos cihazı fiş basmıyor”, “iade faturası hatalı” gibi birden fazla adım, onay veya teknik inceleme gerektiren işler içindir. Canlı sohbet ekibinizi kurduysanız ve hâlâ e-postalar kayboluyorsa, eksik parça genellikle ticket düzenidir. Canlı sohbet tarafını ayrıca değerlendirmek isterseniz canlı destek yazılımı seçimi rehberi bu ayrımı netleştirir.

İç destek ile müşteri destek kuyruklarını aynı listede tutmak sık yapılan bir hatadır. IT birimi bilgisayar arızasını, satış sonrası ekibi kargo gecikmesini, muhasebe ekibi fatura itirazını aynı öncelik setiyle yönetemez. İyi bir yardım masası yazılımı, en azından ayrı kuyruk, ayrı kategori ağacı ve ayrı SLA politikası tanımlamanıza izin vermelidir.

Ticket yaşam döngüsü ve SLA nasıl kurgulanır?

Ticket, talebin dijital kimliğidir. Sağlam bir yaşam döngüsü genelde şu aşamalardan geçer: açılış, sınıflandırma, atama, çalışma, bekleme (müşteri veya üçüncü taraf), çözüm, kapanış ve gerekirse yeniden açılış. Yazılım bu durumları serbest metinle değil, tanımlı durum alanlarıyla yönetmelidir; aksi halde raporlar anlamsızlaşır.

SLA’yı gerçekçi tutun

SLA (hizmet seviyesi anlaşması) iki temel süreyi ölçer: ilk yanıt süresi ve çözüm süresi. KOBİ’lerde sık görülen hata, her kategoriye aynı “4 saat yanıt, 24 saat çözüm” kuralını koymaktır. Bunun yerine talebi iş etkisine göre ayırın:

• Kritik: Tüm satış kanalı veya üretim durduysa (ör. ödeme altyapısı çalışmıyor).
• Yüksek: Tek şube veya tek ekip etkileniyorsa.
• Normal: İş kesintisi yok, planlı destek yeterliyse.
• Düşük: İyileştirme, eğitim veya bilgi talebiyse.

SLA saatlerini takvim saatine mi, iş saatine mi bağlayacağınızı yazılımda net seçin. Cumartesi açılan talep için “8 saat çözüm” vaadi, ekibiniz hafta sonu çalışmıyorsa güven kaybettirir. Ayrıca “müşteri yanıtı bekleniyor” durumunda SLA’nın durup durmayacağını baştan kararlaştırın; aksi halde raporlar ekibi haksız yere kötü gösterir.

Ticket kapanış disiplini

Çözüm notu olmadan kapatılan ticket, bilgi bankası üretmez. Kapanışta en az şu alanlar zorunlu olsun: kök neden (kısa), yapılan işlem, tekrar etmemesi için öneri. Bu disiplin, aynı sorunun üç ayda beş kez açılmasını azaltır.

Kategori, öncelik, atama ve eskalasyon kuralları

Kategori ağacı, raporlamanın omurgasıdır. Çok ince ağaç (50+ alt kategori) ajanın seçim yorgunluğunu artırır; çok kaba ağaç (3 kategori) ise “diğer” kutusunu şişirir. Başlangıç için 6–12 ana kategori yeterlidir. Örnek iç IT seti: erişim ve hesap, donanım, yazılım/uygulama, ağ ve altyapı, e-posta, yeni talep (değişiklik). Müşteri destek seti: sipariş, ödeme, kargo, iade, ürün bilgisi, fatura.

Öncelik ve atama

Öncelik, “en çok bağıran müşteri”ye göre değil, etki × aciliyet matrisine göre seçilmelidir. Atama modeli ise üç yaygın yoldan biridir: manuel (takım lideri dağıtır), round-robin (sırayla), beceri tabanlı (kategoriye göre ekip). Küçük ekiplerde round-robin sade ve işe yarar; uzmanlık gerektiren konular (ödeme, entegrasyon, güvenlik) beceri tabanlı kurala bağlanmalıdır.

Eskalasyon örnekleri

Eskalasyon, “üst yöneticiye her şeyi iletmek” değildir. Kural örnekleri şöyle olabilir:

1. İlk yanıt SLA’sının yüzde 80’i dolduysa sorumlu ajan ve takım liderine bildirim.
2. Çözüm SLA’sı aşıldıysa ticket otomatik “eskalasyon” etiketine alınsın ve ikinci seviye kuyruğa geçsin.
3. Aynı müşteri/varlık için 7 günde 3 ticket açıldıysa “tekrarlayan arıza” olarak işaretlensin.
4. Güvenlik veya veri erişimi kategorisinde her ticket, onaylı bir gruba kopyalansın.

Bu kurallar, e-posta hatırlatmalarından daha izlenebilir bir otomasyon ister. Onay ve kural zincirlerini daha geniş düşünmek için iş akışı otomasyonu rehberi ile süreç tasarımınızı hizalayabilirsiniz.

Bilgi bankası ve self-servis bağlantısı

Yardım masası yazılımının asıl kaldıraç etkisi, ticket’ı kapatmak değil; aynı ticket’ın bir daha açılmamasıdır. Bilgi bankası bu yüzden “blog” gibi değil, destek sürecinin parçası gibi kurgulanmalıdır. Her kapalı ve tekrar eden ticket için kısa bir makale taslağı üretin: belirti, kontrol listesi, çözüm, ne zaman destek açılmalı.

Self-servis başarısı, arama kutusunun güzelliğinden çok içerik eşlemesine bağlıdır. Formda kategori seçildiğinde ilgili makaleler önerilsin. Ajan ticket çözerken “bilgi bankasına bağla” alanını doldursun. Böylece bir sonraki müşteri aynı soruyu yazdığında çözüm yolu zaten listelenir. E-ticaret operasyonlarında iade, kargo ve ödeme konularını ayrı makale gruplarında tutmak, ajanın yanlış şablonu göndermesini de azaltır.

Entegrasyonlar: e-posta, AD/SSO ve varlık kaydı

Seçim listesinde özellik sayısı kadar entegrasyon kalitesi de kritiktir. Aşağıdaki üç başlık çoğu işletmede “olmazsa olmaz” seviyesindedir.

E-posta ile ticket üretimi

Destek@ veya it@ adresi yazılımın gelen kutusuna yönlenmeli; konu, gövde ve ekler ticket’a dönüşmelidir. Yanıtlar aynı ticket kimliğiyle gitmeli ki müşteri her e-postada yeni kayıt açmasın. İmza, otomatik yanıt ve “dışarıdayım” mesajlarının yeni ticket üretmemesi için filtre kuralları test edilmelidir.

AD/SSO ve yetki

Kurumsal ve büyüyen KOBİ’lerde ajanların ayrı şifre hatırlaması güvenlik riskidir. Active Directory veya SSO ile oturum açma, rol bazlı yetki (ajan, takım lideri, salt okunur denetçi) ve ayrılan personelin erişiminin hızlı kapatılması beklenir. Müşteri portalı kullanıyorsanız, şirket dışı kullanıcı ile iç personel rollerini net ayırın.

Varlık (asset) kaydı

IT helpdesk tarafında ticket “Ahmet’in bilgisayarı” diye kalmamalıdır. Cihaz kimliği, marka/model, işletim sistemi, atandığı kişi, garanti bitişi ve son müdahale notu ticket’a bağlanabilirse tekrarlayan arızalar görünür hale gelir. E-ticarette ise “varlık” bazen fiziksel cihaz değil; mağaza paneli, ödeme entegratörü hesabı veya kargo API bağlantısı gibi dijital bileşenlerdir. Bunları envantere almak, “hangi entegrasyon yine düştü?” sorusuna hız kazandırır.

KOBİ için minimum uygulanabilir kurulum adımları

Büyük bir katalogla başlamayın. İki haftalık bir pilot, doğru kapsamı netleştirir. HazırSoft tarafında da kurumsal yazılım seçimlerinde aynı sadeleşme yaklaşımını öneriyoruz: önce kuyruk ve kural, sonra otomasyon ve rapor.

1. Kapsamı yazın: Yalnız iç IT mi, yalnız müşteri destek mi, yoksa ikisi ayrı kuyruklu mu?
2. Kanalları sabitleyin: İlk etapta e-posta + web formu yeterlidir. Telefon kaydını manuel ticket ile bağlayın.
3. Kategori ve önceliği sade tutun: 8 kategori, 4 öncelik seviyesi ile başlayın.
4. SLA politikası tanımlayın: İş saatleri, ilk yanıt ve çözüm sürelerini kategori bazında girin.
5. Atama kuralı seçin: 3 kişiye kadar round-robin; uzman konular için sabit atama.
6. Şablon yanıtlar hazırlayın: En sık 10 konu için onaylı metinler kullanın.
7. Bilgi bankasına 5 makale ekleyin: Gerçekten tekrar eden konularla başlayın.
8. Haftalık metrik bakın: Açık ticket sayısı, SLA aşımı, yeniden açılma, kategori dağılımı.

Pilot bitiminde “hangi alan doldurulmuyor?” sorusunu sorun. Kullanılmayan alanlar ajanı yavaşlatır; zorunlu alan fazlalığı da veri kalitesini düşürür. Gerekmedikçe özel alan eklemeyin.

Seçim kontrol listesi

Demo veya teklif aşamasında şu maddeleri işaretleyin:

• Ayrı kuyruk / marka / departman yönetimi var mı?
• Ticket durumları özelleşiyor ve SLA ile bağlanıyor mu?
• E-postadan ticket, ticket’tan e-posta tutarlı çalışıyor mu?
• Eskalasyon kuralları zamana ve önceliğe göre kurulabiliyor mu?
• Bilgi bankası portalda aranabilir ve ticket’a iliştirilebiliyor mu?
• Varlık veya müşteri geçmişi ticket ekranında görünüyor mu?
• Rol bazlı yetki ve SSO ihtiyacınız karşılanıyor mu?
• Dışa aktarma ve temel raporlar (SLA, ajan yükü, kategori) mevcut mu?
• Veri yedekleme, log ve KVKK kapsamında erişim kayıtları net mi?

Bu liste, “çok özellikli” görünen ama günlük operasyonda yavaş kalan ürünleri elemek için yeterlidir. HazırSoft ekosisteminde yazılım seçerken de benzer kontrol listeleriyle kapsamı daraltmak, gereksiz modül yükünü azaltır; ilgili ürün gruplarına hazır yazılımlar üzerinden göz atabilirsiniz.

Sık yapılan hatalar ve kaçınma yolları

Birinci hata, canlı sohbet ile yardım masasını aynı KPI ile yönetmektir. Sohbette “yanıt süresi saniye”, masada “doğru çözüm ve SLA” ölçülür. İkinci hata, her talebi “acil” yapmaktır; öncelik enflasyonu ekibi körleştirir. Üçüncü hata, bilgi bankasını pazarlama metni gibi yazmaktır; destek makalesi adım adım ve sade olmalıdır. Dördüncü hata, entegrasyonu “ileride bakarız” demektir; e-posta ve kimlik doğrulama ilk günden testi yapılmadan canlıya çıkılmamalıdır.

Doğru kurgulanmış bir yardım masası yazılımı, destek ekibinizi kahraman yapmaz; görünür, ölçülebilir ve paylaşılabilir hale getirir. Kuyrukları ayırın, ticket yaşam döngüsünü sade tutun, SLA’yı iş saatine bağlayın, tekrarlayan konuları bilgi bankasına taşıyın. Bu adımlar tamamlandığında yazılım yatırımı, yalnızca bir paneli değil, hizmet disiplininizi de oturtmuş olur. Kurumsal yazılım ihtiyaçlarınızı bir arada değerlendirmek isterseniz HazırSoft yazılım kataloğu üzerinden kapsamı gözden geçirebilirsiniz.