Destek Talep Sistemi (Helpdesk) Nasıl Kurulur?

Destek talep sistemi (helpdesk), müşteriden hangi kanaldan gelirse gelsin her isteği numaralanmış tek bir kayda — yani bir talebe, İngilizcesiyle ticket’a — çeviren ve o kaydın sahibini, önceliğini ve süresini takip eden yazılımdır. Tek işi vardır: hiçbir talebin cevapsız kalmamasını ve her talebin ne kadar sürede kapandığının ölçülebilmesini sağlamak. Üç yolla kurulur: hazır bir bulut helpdesk’e abone olmak, hâlihazırda kullandığınız CRM’in destek modülünü açmak ya da kendi sürecinize göre özel bir talep sistemi geliştirmek. Doğru seçim günlük talep sayısına, kanal çeşidine ve talebin şirket içinde kaç kişiye dokunduğuna bağlıdır. Aşağıda paylaşımlı e-posta kutusunun tam olarak nerede tıkandığını, bir talebin yaşam döngüsünü, iş saatine göre çalışan bir SLA hesabını, üç satın alma yolunu ve projeyi bozan beş hatayı bulacaksınız.

Destek talep sistemi ne işe yarar?

Bir helpdesk’in ürettiği asıl şey cevap değil, hesap verebilirliktir. Gelen her istek bir numara alır; o numaranın bir sahibi, bir durumu, bir önceliği ve bir hedef süresi olur. Bu dört alan olmadığında destek süreci “kim baktı acaba” sorusuyla yönetilir ve ölçülemez. Sistem ayrıca üç yan çıktı üretir: müşteri kendi talebinin durumunu görebilir, tekrar eden konular sayılabilir hâle gelir ve bir çalışan işten ayrıldığında yazışma geçmişi şirkette kalır — kişisel posta kutusunda değil.

Paylaşımlı e-posta kutusu nerede tıkanır?

destek@sirket.com adresi belirli bir ölçeğe kadar doğru araçtır; sorun, talep sayısı arttığında kutunun kendisinin bir işe dönüşmesidir. Tıkanma her zaman aynı beş yerde görünür:

• Çift cevap ve sıfır cevap bir arada olur. İki kişi aynı e-postaya yanıt yazar, bir başkası kimsenin okumadığını varsayarak hiç yazmaz. Sahiplik alanı olmayan bir kutuda bu kaçınılmazdır.
• Süre ölçülemez. “Ortalama ne kadar sürede dönüyoruz” sorusunun cevabı yoktur; kutuda tarih vardır ama ilk yanıt ile çözüm arasındaki ayrım yoktur.
• Konu geçmişi dağılır. Aynı müşterinin üç ayrı sorunu tek bir e-posta zincirine karışır; altı ay sonra “bu sorun daha önce yaşandı mı” sorusu cevaplanamaz.
• Kanal başına ayrı bir kuyruk doğar. Telefonla gelen istek bir deftere, WhatsApp’tan geleni bir telefona, formdan geleni bir e-postaya düşer. Üçü aynı müşterinin aynı sorunu olabilir.
• Devir teslim yapılamaz. İzne çıkan kişinin kutusundaki yarım kalmış konuşmaları kimse devralamaz; müşteri aynı şeyi ikinci kez anlatmak zorunda kalır.

Kritik eşik şudur: günde 15-20 talebi geçtiyseniz ya da destek işi ikiden fazla kişiye yayıldıysa, sorun ekibin özeni değil, kuyruk yapısının olmamasıdır. Aynı eşik satış tarafında CRM ihtiyacını doğurur; ikisinin nerede ayrıldığını CRM nedir, faydaları neler yazımızda anlattık.

Bir talebin yaşam döngüsü

Yazılımı seçmeden önce kendi sürecinizi bu altı adımda yazmanız gerekir; hazır araçlar da özel geliştirme de bu iskelet üzerine kurulur:

• Açılış — talep kanaldan düşer, numara alır ve müşteriye otomatik bir alındı bildirimi gider. Bu bildirim nezaket değil, “kayboldu mu” telefonlarını kesen tek mekanizmadır.
• Sınıflandırma — kategori ve öncelik atanır. Öncelik keyfî olmasın: “hizmet tamamen durdu”, “bir işlev çalışmıyor”, “soru/talep” gibi üç dört seviyelik yazılı bir tanım yeterlidir.
• Atama — bir kişiye ya da bir ekibe düşer. Sahipsiz talep, cevapsız talep demektir; atama kuralı otomatik olmalıdır.
• Çalışma — yazışma, iç notlar ve gerekiyorsa başka bir birime aktarma. İç not ile müşteriye giden yanıtın ayrı olması şarttır; bu ayrımı olmayan sistemler er ya da geç iç notu müşteriye gönderir.
• Çözüm — yapılan işin özeti yazılır ve talep çözüldü durumuna geçer. Kapanış hemen değil, belirli bir süre sonra otomatik yapılır.
• Yeniden açılma — müşteri aynı konuda döndüğünde eski kayıt yeniden açılır, yeni bir numara üretilmez. Bu tek kural, çözüm kalitesini ölçmenizi mümkün kılan şeydir.

Çok kanallı giriş: her şey aynı kuyruğa düşmeli

Bugün müşteri size dört yerden ulaşıyor: e-posta, web sitesindeki form, WhatsApp ve telefon. Helpdesk’in değeri, bu dördünü tek kuyrukta birleştirmesinde. Pratikte e-posta ve form bağlantısı standarttır; WhatsApp resmî bir kurumsal hesap ve arayüz gerektirir, kurulumunu WhatsApp Business API entegrasyonu yazımızda ayrıntılandırdık. Telefon çoğu zaman entegre edilmez, temsilci görüşme sonunda talebi elle açar — bu kabul edilebilir bir çözümdür, yeter ki açılması zorunlu tutulsun.

Sık gelen basit soruları (kargom nerede, faturamı nasıl alırım, çalışma saatleri) kuyruğa hiç düşürmemek de bir seçenektir: bir yapay zekâ asistanı bunları karşılayıp yalnızca çözemediğini temsilciye devredebilir. Nasıl kurulduğunu yapay zekâ chatbot nasıl yapılır yazımızda anlattık. Kritik detay devir noktasıdır: asistan çözemediğinde konuşma geçmişiyle birlikte talep açmalı, müşteriyi baştan anlatmaya zorlamamalı.

SLA: hedef süre nasıl hesaplanır?

SLA (hizmet seviyesi taahhüdü) iki ayrı süredir ve karıştırılmaları en yaygın hatadır: ilk yanıt süresi ile çözüm süresi. İlk yanıt taahhüdü kolay tutulur ve müşteri memnuniyetinin büyük kısmını o taşır; çözüm süresi ise sorunun kendisine bağlıdır. İkisinin de tek bir teknik şartı vardır: sayaç takvim saatiyle değil iş saatiyle işlemeli. Cuma 17.30’da açılan bir talebin dört saatlik ilk yanıt hedefi, cuma 21.30 değil pazartesi öğlendir.

// İlk yanıt SLA hedefi. Sayaç takvim saatini değil MESAİ saatini sayar:
// cuma 17.30'da açılan talebin 4 saatlik hedefi pazartesi 12.30'dur.
const MESAI_BASLANGIC = 9;
const MESAI_BITIS = 18;
const BIR_GUN = 24 * 60 * 60 * 1000;

// Tatil takvimi dışarıdan verilir: hafta sonu, resmî tatil, idari izin.
type CalismaGunuMu = (tarih: Date) => boolean;

const saatBasi = (t: Date, saat: number): Date => {
  const d = new Date(t);
  d.setHours(saat, 0, 0, 0);
  return d;
};

export function slaHedefi(
  acilis: Date,
  hedefDakika: number,
  calismaGunuMu: CalismaGunuMu,
): Date {
  let kalan = hedefDakika;
  let imlec = new Date(acilis);

  while (kalan > 0) {
    const mesaiBitis = saatBasi(imlec, MESAI_BITIS);

    // Kapalı gün ya da mesai bitmiş: sonraki günün açılışına atla.
    if (!calismaGunuMu(imlec) || imlec >= mesaiBitis) {
      imlec = saatBasi(new Date(imlec.getTime() + BIR_GUN), MESAI_BASLANGIC);
      continue;
    }

    // Mesai öncesi gelen talebin sayacı açılışta başlar.
    const mesaiBaslangic = saatBasi(imlec, MESAI_BASLANGIC);
    if (imlec < mesaiBaslangic) imlec = mesaiBaslangic;

    const bugunKalanDakika = (mesaiBitis.getTime() - imlec.getTime()) / 60000;
    if (bugunKalanDakika >= kalan) {
      return new Date(imlec.getTime() + kalan * 60000);
    }

    kalan -= bugunKalanDakika;
    imlec = saatBasi(new Date(mesaiBitis.getTime() + BIR_GUN), MESAI_BASLANGIC);
  }

  return imlec;
}

İki ayrıntı bu hesabı üretime dayanıklı kılar. Birincisi tatil takviminin dışarıdan verilmesi: hafta sonu kuralını koda gömen sistemler resmî tatilde ve yarım günde yanlış hedef üretir, ekip de bir süre sonra SLA raporuna bakmayı bırakır. İkincisi sayacın müşteri beklerken duruyor olması — talep “müşteri yanıtı bekleniyor” durumuna geçtiğinde SLA saati durmalı, aksi hâlde sizin ihlal etmediğiniz bir süre ihlal olarak raporlanır.

Destek sisteminin başarı ölçüsü kapatılan talep sayısı değildir; aynı konunun tekrar gelme oranıdır. Kapanan talep sayısını hedefe bağlayan ekipler talebi hızla kapatmayı öğrenir, sorunu çözmeyi değil. Ölçülecek doğru sayı iki tanedir: yeniden açılma oranı ve aynı kategoriden gelen talep adedi — ikincisi düşmüyorsa destek değil, ürün ya da süreç sorunu vardır.

Hazır bulut helpdesk mi, CRM modülü mü, özel yazılım mı?

• Hazır bulut helpdesk — Kurulum günler sürer, kanal bağlantıları ve raporlar hazır gelir. Ücretlendirme neredeyse her zaman temsilci başına aylıktır; ekip büyüdükçe maliyet doğrusal artar. Standart bir müşteri desteği için en verimli yol budur ve çoğu şirket burada kalmalıdır.
• Mevcut CRM ya da ERP’nin destek modülü — Müşteri kartı, sipariş ve fatura verisi zaten içeride olduğu için temsilci tek ekranda çalışır; ek entegrasyon gerekmez. Sınırı esnekliktir: modülün sunmadığı bir akışı (örneğin saha ekibine iş emri açmak) çoğu zaman üretemezsiniz.
• Özel geliştirilen talep sistemi — Talep akışınız sektörünüze özgüyse, kayıt bir sonraki adımda başka bir sisteme iş emri düşürüyorsa ya da sistemi kendi müşterinize bir portal olarak açacaksanız gereklidir. Temsilci başına lisans yoktur; maliyet baştan geliştirmeye ödenir.

Karar kuralı basit: talep kaydı destek ekibinin içinde başlayıp bitiyorsa hazır araç; kayıt üretime, sahaya, muhasebeye ya da bayiye iş düşürüyorsa özel sistem ya da güçlü bir entegrasyon. İkinci durumda asıl iş helpdesk değil, sistemler arası bağlantıdır; nasıl kurulduğunu API entegrasyonu nedir yazımızda anlattık. Şirket içi talepleri (BT arızası, İK isteği, satın alma onayı) de aynı iskeletle yönetmek mümkündür — o tarafı şirket içi otomasyon yazılımı yazımızda ele aldık.

Ölçülecek beş metrik

• İlk yanıt süresi — müşterinin “duyuldum” hissini belirleyen tek sayı. Medyan değeriyle takip edin; ortalama, birkaç uç kayıt yüzünden yanıltır.
• Çözüm süresi — kategori bazında bakılmalı. Tek bir genel ortalama, gerçekten yavaş olan konu başlığını gizler.
• İlk temasta çözüm oranı — kaç talep tek yanıtla kapandı? Bu oran yükseldikçe hem maliyet düşer hem memnuniyet artar.
• Yeniden açılma oranı — çözüm kalitesinin doğrudan göstergesi. Yüzde onun üstündeyse talepler erken kapatılıyor demektir.
• Kategori dağılımı — en çok gelen üç konu. Bu liste her ay ürün ekibine gitmiyorsa destek, aynı sorunu sonsuza kadar çözmeye devam eder.

Bu beş metriği yöneticinin göreceği bir ekrana taşımak ayrı bir iştir; panelin nasıl kurulduğunu ve neden canlı veritabanına bağlanılmaması gerektiğini iş zekası ve raporlama paneli yazımızda anlattık.

Projeyi bozan beş hata

• Önceliği tanımsız bırakmak. Yazılı bir öncelik tanımı yoksa her talep “acil” olur ve öncelik alanı hiçbir işe yaramaz.
• SLA sayacını takvim saatiyle çalıştırmak. Cuma akşamı gelen talep pazartesi sabahı ihlal edilmiş görünür; ekip raporun kendisine güvenmeyi bırakır.
• Müşteriye durum göstermemek. Talebin durumunu göremeyen müşteri telefonla sorar; destek yükünün önemli bir kısmı “ne oldu” aramalarıdır.
• Her şeyi tek kuyrukta tutmak. Satış öncesi soru, teknik arıza ve fatura talebi aynı kuyrukta bekletildiğinde arıza en yavaş çözülen kalem olur.
• Bilgi bankasını sonraya bırakmak. Aynı yanıtın onuncu kez yazılması bir metin sorunu değil, eksik dokümantasyon sorunudur; kısa bir makale seti hem müşteriyi hem yeni işe başlayan temsilciyi hızlandırır.

Maliyet: neyin parasını ödüyorsunuz?

Bütçe tek bir kalemde değil, beş kalemde oluşur. Teklif isterken bunları ayrı ayrı görmek iki firmayı gerçekten karşılaştırmayı mümkün kılar:

• Abonelik ya da geliştirme — hazır araçta temsilci başına aylık ücret; özel sistemde baştan ödenen geliştirme bedeli.
• Kanal entegrasyonları — e-posta ve form standarttır; WhatsApp, telefon santrali ve mağaza/pazaryeri mesajlarının her biri ayrı bir iştir.
• Veri bağlantıları — temsilcinin müşteri, sipariş ve fatura bilgisini tek ekranda görmesi için CRM/ERP tarafına yazılacak bağlantılar.
• Kurulum ve göç — mevcut e-posta kutusundaki açık konuların taşınması, kategori ağacının kurulması, ekip eğitimi.
• Bakım — kanal arayüzleri sürüm değiştirdiğinde ya da yeni bir akış istendiğinde harcanacak süre. Yıllık bir bakım kalemi ayırmayan sistemler ikinci yılda kanal kaybeder.

Kalemleri adam-gün karşılığıyla istemek tek bir toplam rakamdan çok daha fazlasını gösterir; mantığını özel yazılım maliyeti yazımızda kalem kalem açıkladık. Hazır araçta ise dikkat edilecek nokta lisans modelidir: temsilci başına ücret, destek işine ara sıra giren satış ya da teknik ekip üyeleri yüzünden beklenenin iki katına çıkabilir.

Sonuç

Destek talep sistemi yeni bir müşteri hizmeti kültürü kurmaz; var olan işi görünür ve ölçülebilir kılar. Bu yüzden başarı, seçilen ürünün marka adında değil üç şeyde saklıdır: yazılı bir öncelik ve SLA tanımı, tüm kanalların tek kuyrukta birleşmesi ve tekrar eden konuların her ay ürün tarafına taşınması. Talep kaydınız yalnızca destek ekibinin içinde kalıyorsa hazır bir araçla başlayın; kayıt sahaya, üretime ya da muhasebeye iş düşürüyorsa kurumsal çözümler hizmetimize göz atabilir ya da mevcut kanallarınızı ve günlük talep sayınızı anlatan kısa bir mesajla teklif alabilirsiniz.