Bir müşteri e-posta atar, ertesi gün aynı konuyu telefonla sorar, üçüncü kez WhatsApp'tan yazar. Üç mesaj üç farklı kişiye düşer, hiçbirinde önceki yazışma görünmez. Müşteri aynı şeyi üç kez anlatır, ekip aynı işi üç kez yapar, kimse sorunun kimde olduğunu bilmez. Destek talep yönetim sistemi, yani help desk (yardım masası), bu dağınıklığı tek bir kayıt ve tek bir sorumlu etrafında toplayan yazılımdır.
Bu rehberde destek talep yönetim sisteminin ne olduğunu, talebin yaşam döngüsünü, etki ve aciliyetle öncelik belirlemeyi, SLA uyum oranını, kanalların birleştirilmesini, bilgi tabanının talep yükünü nasıl azalttığını, ekip kapasitesinin hesabını, müşteri memnuniyetinin ölçümünü, yatırımın geri dönüşünü ve seçim ölçütlerini anlatıyoruz. Örnek rakamlar temsilîdir; gerçek veri ya da sektör ortalaması iddiası taşımaz.
Destek Talep Yönetim Sistemi Nedir?
Destek talep yönetim sistemi, müşteriden ya da iç kullanıcıdan gelen sorun, soru ve şikâyetlerin her birini bir "talep" kaydına dönüştürüp atama, öncelik, süre hedefi, yanıt geçmişi ve çözüm adımlarıyla izleyen yazılımdır. Yaygın adıyla help desk ya da ticket (bilet) sistemi denir. Müşteri tarafı ile ekip tarafı aynı kaydı görür; kayıt kapanana kadar sahipsiz kalmaz.
Temel parçaları şunlardır: ortak gelen kutusu, talep kaydı, atama ve yönlendirme kuralları, öncelik ve SLA süreleri, hazır yanıt şablonları, bilgi tabanı, iç notlar ve raporlama. Müşteri ilişkilerinin satış tarafını CRM nedir rehberimizde anlattık; destek sistemi, aynı müşterinin satış sonrası yüzünü yönetir ve çoğu zaman CRM kaydıyla bağlanır.
Okumanızı öneririz: CRM yazılımı hizmetimiz ve modüller
Bir Destek Talebi Hangi Aşamalardan Geçer?
Her talep aynı yaşam döngüsünü izlemelidir: yeni, atandı, yanıtlandı, beklemede, çözüldü ve kapandı. Durumlar net olduğunda hangi talebin kimde ve ne kadar süredir beklediği tek bakışta görünür.
| Durum | Anlamı | Süre kuralı |
|---|---|---|
| Yeni | Talep kaydedildi, henüz kimseye atanmadı | Atama için üst süre tanımlanır |
| Atandı | Sorumlu kişi ya da ekip belli | İlk yanıt süresi sayılmaya başlar |
| Yanıtlandı | Müşteriye ilk dönüş yapıldı | Çözüm süresi sayacı sürer |
| Beklemede | Müşteriden bilgi ya da üçüncü taraftan cevap bekleniyor | Sayaç durdurulur, bekleme nedeni yazılır |
| Çözüldü | Çözüm iletildi, müşteri onayı bekleniyor | Belirli süre yanıt gelmezse otomatik kapanır |
| Kapandı | Kayıt tamamlandı, değerlendirme istendi | Yeniden açma süresi sınırlıdır |
"Beklemede" durumu önemlidir: müşteriden cevap beklerken sayaç durmazsa ekip, kendi kusuru olmayan gecikmeden dolayı SLA'yı kaçırmış görünür.
Talebin Önceliği Etki ve Aciliyetle Nasıl Belirlenir?
Her talep "acil" diye gelir; öncelik, ekibin duygusuyla değil kurala göre belirlenmelidir. En yaygın yöntem etkiyi (kaç kişiyi ya da hangi işi etkiliyor) ve aciliyeti (beklemenin maliyeti) üçlü ölçekle puanlayıp çarpmaktır.
| Etki \ Aciliyet | Düşük (1) | Orta (2) | Yüksek (3) |
|---|---|---|---|
| Yüksek (3): birçok kullanıcı ya da kritik süreç | 3 → P3 | 6 → P1 | 9 → P1 |
| Orta (2): bir ekip ya da bir müşteri | 2 → P3 | 4 → P2 | 6 → P1 |
| Düşük (1): tek kullanıcı, çözüm yolu var | 1 → P4 | 2 → P3 | 3 → P3 |
Örneğin tüm bayilerin sipariş veremediği bir hata etki 3, aciliyet 3 ile 9 puanlı P1'dir; tek kullanıcının bir raporun biçimini sorması etki 1, aciliyet 1 ile 1 puanlı P4'tür. Her önceliğe ilk yanıt ve çözüm süresi bağlanır; bu sürelerin sözleşmeye nasıl yazıldığını yazılım bakım ve destek sözleşmesi (SLA) rehberimizde anlattık.
SLA Uyumu ve İlk Temasta Çözüm Oranı Nasıl Ölçülür?
İki gösterge destek kalitesinin omurgasıdır: süre hedefine uyum ve talebin ilk temasta çözülme oranı. İkisi de sistemden otomatik hesaplanır.
| Gösterge | Nasıl hesaplanır? | Örnek (temsilî) |
|---|---|---|
| SLA uyum oranı | Süre hedefini tutturan talep ÷ toplam talep | 912 ÷ 960 = %95 |
| İlk temasta çözüm oranı | Tek yanıtta çözülen talep ÷ toplam talep | 612 ÷ 960 = %63,8 |
| Ortalama ilk yanıt süresi | Tüm taleplerin ilk yanıt sürelerinin ortalaması | 1 sa 40 dk |
| Yeniden açılma oranı | Kapandıktan sonra yeniden açılan ÷ kapanan | 38 ÷ 960 = %4,0 |
Ortalamaya tek başına güvenmeyin: birkaç çok geciken talep ortalamayı bozar. Önceliğe göre ayrı ayrı bakın; P1 taleplerinde uyum oranı %100'e yakın olmalıdır.
Birden Fazla Kanal Tek Kutuda Nasıl Toplanır?
Müşteri istediği kanaldan yazar; ekip tek yerden yanıtlar. Kanalın ne olduğu önemsizdir, önemli olan her mesajın aynı talebe ve aynı müşteri kaydına bağlanmasıdır.
| Kanal | Sisteme nasıl girer? | Dikkat edilecek |
|---|---|---|
| E-posta | Destek adresine gelen her ileti talep açar | Yanıt zincirinin aynı talebe bağlanması |
| Web formu | Konu, kategori ve ek dosyayla doğrudan kayıt | Zorunlu alanlar, spam süzgeci |
| Telefon | Temsilci görüşme sırasında talep açar | Görüşme notunun kayda yazılması |
| Mesajlaşma uygulaması | Entegrasyonla konuşma talebe dönüşür | Platformun resmî kullanım koşulları |
| Müşteri portalı | Müşteri girişle talep açar ve geçmişi görür | Yetki ve kişisel veri koruması |
Kanalları sisteme bağlamak bir entegrasyon işidir; yaklaşımı ve riskleri API entegrasyonu rehberimizde anlattık.
Bilgi Tabanı Talep Yükünü Nasıl Azaltır?
Gelen taleplerin önemli bir kısmı tekrar eden sorulardır. Sık sorulanlara yazılmış kısa, aranabilir makaleler müşteriye talep açmadan cevap verir; buna self-servis (kendi kendine çözüm) denir.
Örnek (temsilî): ayda 960 talep açılmış ve 240 ziyaretçi, talep açmadan makalede çözümü bulmuş olsun. Sapma oranı 240 ÷ (960 + 240) = %20'dir. Ayrıca aynı soru için sürekli talep geliyorsa, o konu için makale yazmak ilk öncelik olmalıdır.
- Talep etiketlerinden başlayın: En sık etiketlenen beş konu, ilk beş makalenizdir.
- Kısa ve adım adım yazın: Makale, sorunun çözüm adımlarını ve gerekirse ekran görüntüsünü içermelidir.
- Makaleyi taleple bağlayın: Temsilci yanıtına tek tıkla makale ekleyebilmelidir.
- Güncel tutun: Eski makale yanlış yönlendirir; sürüm değişince gözden geçirin.
Destek Ekibi Kaç Kişi Olmalıdır?
Ekip büyüklüğü talep hacmi, ortalama işlem süresi ve kişi başına üretken saat ile hesaplanır. Üretken saat, toplantı, eğitim ve izinden sonra gerçekten talep işlemeye ayrılan süredir.
Örnek (temsilî): ayda 960 talep, talep başına ortalama 18 dakika işlem süresi ve kişi başına aylık 120 üretken saat olsun. Toplam iş yükü 960 × 18 = 17.280 dakika, yani 288 saattir; gereken kişi 288 ÷ 120 = 2,4'tür. Yarım kişilik fark, vardiya düzeniyle ya da iki kişi ve bir yarı zamanlı destekle karşılanır. Talep hacmi artıyorsa, işlem süresini kısaltan şablonlar ve bilgi tabanı yatırımı ek işe alımdan önce gelir.
Müşteri Memnuniyeti Destek Sisteminde Nasıl Ölçülür?
Talep kapandığında müşteriye tek soruluk bir değerlendirme gönderin: "Aldığınız destekten memnun kaldınız mı?" CSAT (müşteri memnuniyet skoru), olumlu yanıtların toplam yanıta oranıdır.
Örnek (temsilî): 960 kapanan talepten 210'una yanıt gelmiş ve 168'i olumlu ise CSAT 168 ÷ 210 = %80'dir; yanıt oranı 210 ÷ 960 = %21,9'dur. Düşük yanıt oranında CSAT yanıltıcı olabilir; olumsuz yanıtların nedenini okuyun, tekrar eden konuları bilgi tabanı ve süreç iyileştirmesine çevirin.
Okumanızı öneririz: İş zekâsı (BI) nedir? Göstergelerden kararlara rehber
Destek Sisteminin Geri Dönüşü Nasıl Hesaplanır?
Geri dönüş, yatırımın aylık net faydaya bölünmesiyle bulunur. Fayda; elle takip ve arama süresinin kısalmasından, tekrar eden taleplerin azalmasından ve müşteri kaybının önlenmesinden gelir; ilk hesapta yalnızca ölçülebilen süre kazancını sayın.
Örnek (temsilî): sistem, talep başına 6 dakikalık elle takip ve arama süresini ortadan kaldırsın. 960 × 6 = 5.760 dakika, yani 96 saat eder; saati ₺300'den aylık brüt fayda ₺28.800'dür. Aylık işletme maliyeti ₺6.300 ise aylık net fayda 28.800 − 6.300 = ₺22.500'dür. ₺360.000'lik yatırımın geri dönüşü 360.000 ÷ 22.500 = 16 aydır. Müşteri kaybının azalması gibi dolaylı faydalar bu hesaba katılmamıştır; gerçekleşen ölçümlerle güncelleyin.
Destek Talep Yönetim Sistemi Seçerken Nelere Bakılmalı?
Hazır programı da özel çözümü de aynı altı soruyla değerlendirin. Seçim sürecinin ağırlıklı puanlama ve demo adımlarını CRM programı nasıl seçilir rehberimizde ayrıntılı anlattık; aynı yöntem destek sistemi için de geçerlidir.
- Kanal desteği: E-posta, form, telefon ve portal tek kutuda toplanıyor mu?
- Kural motoru: Kategoriye göre otomatik atama, öncelik ve SLA sayacı tanımlanabiliyor mu?
- Müşteri geçmişi: Aynı müşterinin tüm talepleri ve satış kaydı tek ekranda görünüyor mu?
- Bilgi tabanı: Makale yazma, arama ve yanıta ekleme var mı?
- Raporlama: SLA uyumu, çözüm süresi, CSAT ve etiket bazlı rapor hazır mı?
- Yetki ve veri: Rol bazlı erişim, denetim kaydı ve veriyi dışarı alma imkânı var mı?
Destek Süreçlerinde Sık Yapılan Hatalar Nelerdir?
- Talebi sahipsiz bırakmak: Atama kuralı olmayan kutuda herkes başkasının yapacağını varsayar.
- Her talebi acil saymak: Öncelik kuralı olmayınca asıl kritik talep kaybolur.
- Bekleme nedenini yazmamak: Neden bekleniyor bilinmezse talep aylarca açık kalır.
- Aynı soruyu tekrar tekrar yanıtlamak: Bilgi tabanı ve şablon olmadan işlem süresi düşmez.
- Yalnız ortalamaya bakmak: Öncelik ve kategori kırılımı olmayan rapor sorunu gizler.
- Geri bildirimi okumamak: Memnuniyet anketi toplanıp işlenmezse iyileşme olmaz.
Okumanızı öneririz: Low-code nedir? Düşük kodlu geliştirmenin sınırları ve maliyeti
Okumanızı öneririz: Müşteri portalı nedir? Self-servis kapsamı, güvenlik ve geri dönüş rehberi
İnovabil ile Destek ve Şikâyet Yönetim Sistemi
İnovabil olarak destek ve şikâyet süreçlerini işletmenizin kendi akışına göre yazılıma taşıyoruz: talep kaydı ve kanal birleştirme, atama ve öncelik kuralları, SLA sayaçları, bilgi tabanı, müşteri portalı, CRM ve ERP bağlantıları ile raporlama. Projeye süreç haritası ve gereksinim analiziyle başlıyor, parçalı geliştirme ve kabul testiyle ilerliyoruz.
Sleepy için şikâyet ve destek yönetim sistemini geliştirdik; ayrıca depo yönetimi (WMS), sevkiyat planlama ve satın alma gibi alanlarda Karyak, Bofigo, İZBAN ve Avcılar İnşaat için özel yazılımlar yaptık. Destek akışınızı ve zorlandığınız noktayı birkaç cümleyle anlatın; önce süreç haritasını ve öncelikleri yazılı olarak çıkaralım.
Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım
Sık Sorulan Sorular
Destek talep yönetim sistemi nedir, kısaca ne işe yarar?
Gelen sorun, soru ve şikâyetlerin her birini bir talep kaydına dönüştürüp atama, öncelik, süre hedefi ve yanıt geçmişiyle izleyen yazılımdır. Her talebin bir sahibi ve geçmişi olur, ekip ne kadar hızlı ve doğru çalıştığını ölçebilir.
Help desk ile ticket sistemi aynı şey midir?
Günlük kullanımda çoğunlukla aynı şeyi anlatırlar. Help desk (yardım masası) hizmetin adı, ticket (bilet) ise her bir talep kaydıdır. Yazılım, talepleri bilet olarak açıp yaşam döngüsü boyunca izler.
Talep önceliği nasıl belirlenir?
Etki (1–3) ile aciliyet (1–3) çarpılır. Puan 6–9 ise P1, 4 ise P2, 2–3 ise P3, 1 ise P4 olur. Her önceliğe ilk yanıt ve çözüm süresi bağlanır; kural yazılı olduğu için tartışma azalır.
SLA uyum oranı nasıl hesaplanır?
Süre hedefini tutturan talep sayısı, toplam talep sayısına bölünür. Örnekte 960 talepten 912'si hedefi tuttuğu için oran 912 ÷ 960 = %95'tir. Önceliğe göre ayrı ayrı izlemek gerekir; P1 taleplerinde oran %100'e yakın olmalıdır.
Destek ekibi kaç kişi olmalı?
Talep sayısı, ortalama işlem süresi ve kişi başına üretken saat ile hesaplanır. Örnekte 960 talep × 18 dakika = 288 saat iş yükü ve kişi başına 120 saat üretken süreyle 2,4 kişi gerekir. Bilgi tabanı ve şablonlar işlem süresini kısaltarak ihtiyacı azaltır.