Müşteri şikayet ve destek talebi takibi: WhatsApp'tan gelen sorun kaybolmasın, SLA nasıl çalışır

Müşteri şikayet takip programı arayan küçük işletmelerin çoğu bunu bir yazılım ihtiyacı olarak keşfetmez. Şöyle keşfeder: bir müşteri arar, "ben bunu geçen hafta yazmıştım" der ve kimse o mesajı bulamaz. Sonra ikinci bir müşteri arar, aynı cümleyi kurar. Üçüncüsünde artık soru değişir: "Biz haftada kaç talep alıyoruz, kaçını zamanında kapatıyoruz?" Cevap yoktur, çünkü sayılabilecek bir kayıt yoktur.

Bu rehber, günde 5 ile 50 arası destek talebi alan bir ekip için yazıldı: teknik servis, e-ticaret operasyonu, yazılım ya da ajans ekibi, bayi ağı. Ortak noktaları şu: talepler WhatsApp, telefon, e-posta ve web formundan aynı anda geliyor, hepsi farklı yerde duruyor ve hangisinin cevaplandığını kimse bütün olarak bilmiyor. Örnek senaryomuz Vardar Teknik Servis: on bir kişilik bir ekip, iklimlendirme sistemlerinin kurulumunu ve bakımını yapıyor, müşterilerinin çoğu kurumsal. (Demo verisi.)

Talebin yaşam döngüsü ve 5 kaçak noktası

Bir sorunun size ulaşmasıyla müşterinin "tamam, çözülmüş" demesi arasında altı halka var. Ve talepler bu halkaların içinde değil, aralarındaki boşluklarda kaybolur. Aşağıdaki şema Vardar Teknik Servis'in bir ayını gösteriyor.

Beş noktanın ortak özelliği şu: hiçbiri bir hata değil. Hiç kimse yanlış bir şey yapmadı, sadece bir adım hiç kaydedilmedi. Tek tek bakalım.

• 1. WhatsApp'tan gelen sorun kayda geçmedi. Türkiye'de küçük işletmelerin destek trafiğinin büyük kısmı WhatsApp'tan gelir ve bu kötü bir şey değildir: müşteri için en kolay kanal odur. Kötü olan, sorunun o kanalda kalmasıdır. Bir teknisyenin telefonundaki mesaj kimsenin listesinde yoktur, kimsenin sorumluluğunda değildir ve üzerinde süre işlemez. Kanalı değiştirmenize gerek yok, kaydı açmanız yeterli. Konuşma WhatsApp'ta devam eder, sorun sistemde durur.
• 2. Talep açıldı ama sahibi yok. Sahipsiz kayıt herkesin gördüğü, kimsenin üstlenmediği kayıttır ve istisnasız en uzun bekleyen odur. "Ekip görüyor zaten" cümlesi bir atama değildir.
• 3. Öncelik kişiye göre değişiyor. Aynı arıza sabah kritik, öğleden sonra orta olarak açılıyorsa sıralamanız çalışmaz. Öncelik bir his değil, önceden yazılmış bir tanımdır: "iş tamamen durduysa kritik" gibi.
• 4. Çözüldü ama müşteriye dönülmedi. Destekte en pahalı sessizlik budur. Sorun çözülür, kimse haber vermez, müşteri ertesi gün aynı konuyu yeniden açar. Bir kaydın çözülmesi ile kapanması arasındaki fark tam olarak budur: bildirim.
• 5. Ay sonunda kaç talep geldiği bilinmiyor. Yukarıdaki dördünün toplamı. Sayılamayan destek yükü ne planlanır, ne ekiplenir, ne de fiyatlanır. "Bu ay çok yoğunduk" cümlesi bir veri değildir.

WhatsApp trafiğini kayba uğratmadan yönetmenin ayrıntılı anlatımı WhatsApp ile müşteri takibi rehberinde; buradaki fark, o trafiğin ucundaki sorunun ayrı bir kayıt olarak yaşaması.

Döngünün her halkasında ne kaydedilmeli?

Kaçakları kapatmanın yolu daha çok gayret değil, her halkada ne kaydedileceğinin önceden belli olmasıdır. Aşağıdaki tablo bir sorunun ilk mesajdan kapanışa giderken bırakması gereken izi gösteriyor.

Bu tablonun en çok atlanan satırı beşincisidir. Çözüm notu, bugün için değil üç ay sonrası için yazılır: aynı müşteri aynı cihazla tekrar aradığında geçen sefer ne yapıldığını okuyabilmek, ikinci ziyareti gereksiz kılan tek şeydir. Notu iki cümleden uzun yazmanıza gerek yok, ama "halledildi" yazmanız da yeterli değil.

SLA nedir ve sayaç nasıl okunur?

SLA, açılımıyla hizmet seviyesi taahhüdü, bir talebe ne kadar sürede döneceğinizin yazılı halidir. Kurumsal dünyada sözleşme metnidir; küçük bir ekipte ise çok daha basit bir işe yarar: sıradaki işi kişiye sormadan belli eder. Beş açık talep varsa ve hangisine önce bakılacağı tartışılıyorsa, o ekipte SLA yoktur.

Süreyi müşteriye göre değil önceliğe göre belirlemek, küçük ekipler için tek uygulanabilir yoldur. Dört öncelik ve dört rakam yeter. Rakamları ekibin gerçekten tutabileceği kadar geniş seçin: tutulmayan bir SLA, hiç SLA olmamasından daha kötüdür, çünkü müşteriye verilip tutulmamış bir söze dönüşür.

Sayacın üç hali vardır ve üçü de listede tek bakışta görünür: yolunda (kalan süre yeşil), uyarı (sürenin son çeyreğine girildi, sarı) ve ihlal (süre doldu, kırmızı). Sayaç talep açıldığı anda başlar, öncelik değiştiğinde kalan süre yeniden hesaplanır. Dürüst bir uyarı: sayaç iş saatlerini ve tatilleri bilmez, duvardaki saati sayar. Cuma 17:00'de açılan 24 saatlik bir talep, pazartesi sabaha ihlal olarak gelir. Çözüm, hedefleri bu gerçeğe göre koymaktır: sadece hafta içi 09:00 ile 18:00 arasında çalışan bir ekipte "24 saat" pratikte "ertesi iş günü" demektir ve rakamı 48'e çekmek daha dürüst bir taahhüttür.

Kuyruk, atama ve durumlar

Sahipsiz talep sorununun çözümü herkesi her talebe bakmaya zorlamak değil, kuyruk kurmaktır. Kuyruk, kayıt sahibi olabilen ortak bir havuzdur: üyeleri kuyruğun kayıtlarını kendi kayıtları gibi görür ve düzenler. Bir talep bir kişiye atanamıyorsa bir kuyruğa atanır; ortada kalmaz. Küçük bir serviste üç kuyruk çoğu zaman yeter: Saha Ekibi, Teknik Destek, Muhasebe ve Sözleşme.

Atama kuralı ise kuyruğu otomatikleştirir: koşul yazarsınız, ilk eşleşen aktif kural sahibi belirler. Örnek kural seti şöyle olabilir:

• Öncelik Kritik ise sahibi nöbetçi teknisyen olsun.
• Kanal Web ise sahibi Teknik Destek kuyruğu olsun.
• Tip Şikayet ise sahibi doğrudan operasyon yöneticisi olsun.

Durum listesi de en az sahip kadar önemlidir, çünkü gecikme raporunuzun dürüstlüğü buna bağlıdır. Altı durum bir servis ekibinin ihtiyacını karşılar:

Altı durumun en değerlisi Müşteri Bekleniyor'dur. Onsuz, müşterinin size dönmediği talepler sizin geciktirdiğiniz talepler gibi görünür ve gecikme sayınız gerçeği anlatmayı bırakır.

İlk 7 gün: kurulum planı

Destek takibine geçişin en sık başarısız olma nedeni, geçmiş bütün yazışmaları taşımaya çalışmaktır. Taşımayın. Günde bir saat, yedi gün yeterlidir ve sekizinci gün her yeni talep sistemden çıkar.

Sekizinci günün tek kuralı var: paralel yürütme yok. İlk hafta iki yerde birden tutmak öğreticidir, ikinci hafta zararlıdır, çünkü kimse aynı şeyi iki kere yazmaz ve yazmayınca da ikisi birden güvenilmez hale gelir.

Ohana360'ta akış nasıl işliyor?

Servis360 bu döngünün tamamını üstlenir. Ne yaptığını abartmadan, ne yapmadığını da saklamadan anlatalım.

• Talep kaydı: her talep otomatik bir numara alır (00001001 biçiminde, org sayacından). Kayıt alanları: Konu, Tip (Soru, Sorun, Talep, Şikayet), Öncelik (Düşük, Orta, Yüksek, Kritik), Kanal (Telefon, E-posta, Web, Sosyal Medya), Şirket, Kişi, Durum ve Açıklama. Tip ve Kanal listeleri Nesne Yöneticisi'nden düzenlenir; WhatsApp ya da Portal gibi değerleri kendiniz eklersiniz. Durum ve Öncelik ise sisteme bağlı listelerdir, çünkü SLA hesabı ve kapanış akışı onlara dayanır.
• SLA hedefleri: Servis360 ana sayfasındaki Uygulama Ayarları kartından açılır (yalnız yöneticiler görür) ve üç sekmesi vardır: SLA Hedefleri, Kuyruklar ve Atama, Web-to-Case. SLA sekmesinde dört önceliğin saat hedefini yazarsınız; varsayılanlar kritik 4, yüksek 8, orta 24, düşük 48 saattir. Değişiklik bütün açık taleplerin kalan süre ve ihlal hesabına anında yansır.
• SLA sayacı: talebin açılış anından itibaren işler. Listede ve kayıt sayfasında "3s 12d kaldı" biçiminde görünür, sürenin son %25'inde uyarı rengine döner, süre dolduğunda SLA İhlali olur. Talep Çözüldü ya da Kapalı'ya geçtiğinde sayaç durur ve rozet SLA Karşılandı ya da SLA İhlali olarak sabitlenir.
• Liste ve kanban: Talepler sekmesi tam donanımlı bir liste görünümüdür (Talep No, Konu, Şirket, Öncelik, Durum, SLA, Kanal kolonları; çift tıkla satır içi düzenleme, süzgeçler, toplu öncelik ve durum değiştirme). Aynı sekmede kanban görünümüne geçebilirsiniz: kolonlar durumlar, kartlarda numara, SLA rozeti, konu, öncelik ve kanal var; kartı sürükleyerek durum değiştirirsiniz.
• Kuyruklar ve atama: Uygulama Ayarları'nın ikinci sekmesi. Kuyruk oluşturur, üye eklersiniz; atama kuralları koşul listesiyle yazılır ve ilk eşleşen aktif kural sahibi belirler. Sahibi bilinçli olarak seçilmiş bir kayda kural dokunmaz. Kurallar web formundan gelen taleplerde de çalışır.
• Web-to-Case: üçüncü sekmede sitenize gömeceğiniz hazır bir form kodu durur (konu, ad, e-posta, mesaj alanları ve görünmez bir bot tuzağı). Formdan gelen kayıt kanal Web, öncelik Orta, durum Yeni olarak açılır; yöneticilere e-posta gider, bildirim merkezine düşer, mobil push çıkar ve atama kuralları çalışır. Formu dolduran kişiye de talep numarası gösterilir. Uç nokta IP başına hız sınırlıdır. Token'ı yenilerseniz sitedeki eski form çalışmayı bırakır, kodu güncellemeniz gerekir.
• Portal360'tan gelen talep: Portal360 açıksa müşteriniz kendi hesabıyla portala girer ve Taleplerim sekmesinden + Yeni Talep ile konu ve açıklama girer. Kayıt Servis360'ta kanal Portal, durum Yeni, öncelik Orta ve portal kullanıcısının şirketi ile açılır; ekibinize "Portaldan yeni talep" bildirimi düşer ve kayıt tetikli akışlarınız bu talepte de çalışır. Portal kullanıcısı ayrıca kendi taleplerinin durumunu ve varsa çözüm notunu görür, yani "ne oldu bizim işe" telefonu azalır.
• Önerilen Makaleler: Bilgi360 açıkken talep sayfasına gelen kart, konudaki kelimeleri yayındaki makalelerin başlık, özet ve kategorilerinde arar ve en iyi eşleşen üç makaleyi önerir. Makaleyi talebe bağlar, gerekirse bağlantıyı kaldırırsınız. Dürüst olalım: bu bir anahtar kelime eşleşmesidir, yapay zeka değil. Makale başlıklarınız müşterinin kullandığı kelimeleri içeriyorsa çok iyi çalışır, içermiyorsa hiç çalışmaz.
• Kayıttan e-posta: talep sayfasında E-posta kartı varsayılan olarak açıktır. Şablon seçip yazarsınız, mesaj kaydın konuşmasına ve aktivite zaman tüneline tamamlanmış bir e-posta olarak düşer, imzanız sona eklenir. Böylece "müşteriye en son ne söyledik" sorusunun cevabı kayıtta durur.
• Çözüm ve kapanış: kayıt sayfasındaki Talebi Çöz düğmesi (ya da aşama çubuğundan Çözüldü seçmek) çözüm notunu zorunlu tutan bir pencere açar. Not kaydedilir, çözüm zamanı yazılır ve talep listede Çözüldü olarak görünür. Not olmadan kapanış yoktur.
• Ana sayfa: Servis360 ana sayfasında dört blok var. SLA şeridi ihlaldeki açık talepleri en üstte gösterir. Dikkat İsteyen Talepler listesi açık talepleri sebebe göre sıralar: SLA aşıldı, kritik öncelik, 7 günden uzun süredir açık, atanmamış. Obje envanteri kartları her sekmenin kayıt sayısını ve durum dağılımını verir; dilime tıklayınca o dilimin filtreli listesi açılır. Uygulama Ayarları kartı ise yalnız yöneticilere görünür.
• Bildirimler: zil menüsünde ayrı bir Canlı SLA İhlalleri kartı vardır; ihlalleri tek tek görüldü işaretlersiniz, böylece aynı kayıt iki kişi tarafından iki kez ele alınmaz.
• Dahil değil: WhatsApp'tan gelen mesajın kendiliğinden talebe dönüşmesi, e-postadan otomatik talep açma (email-to-case), telefon santrali entegrasyonu, canlı sohbet penceresi, iş saatleri ve resmî tatil takvimine göre SLA sayacının durdurulması, ilk yanıt süresinin otomatik ölçülmesi. Talep kaydındaki İlk Yanıt alanı vardır ama kendiliğinden dolmaz; ölçmek isterseniz elle yazmanız gerekir.

Akışı 95 saniyede görmek isterseniz:

Hangi uyarıları otomatiğe alırsınız?

Akış motorunda talepler için üç hazır şablon var ve üçü de ilk hafta içinde açılmaya değer:

• Kritik talep, acil arama görevi: kayıt tetikli akış. Öncelik Kritik olan bir talep açıldığında sahibine bugün vadeli bir arama görevi açar ve bildirim gönderir.
• 3 gün açık kalan talep, bildirim: zamanlı yollu akış. Talep açıldıktan üç gün sonra hâlâ kapanmadıysa bildirim ve push gönderir. Sessizce yaşlanan kayıtları yakalayan uyarı budur.
• Talep kapanınca memnuniyet anketi: durum Kapalı'ya döndüğünde Anket360'taki bir anketi gönderir. Burada dürüst bir ayrıntı var: akış alıcıyı kaydın e-posta alanından okur ve talep kaydında standart bir e-posta alanı yoktur. Bu haliyle akış anketi doğrudan göndermek yerine sorumluya "anketi gönder" görevi açar. Doğrudan gönderim isterseniz talebe bir e-posta özel alanı ekleyip talep açılırken doldurmanız gerekir.

Kalan uyarıları aynı ekranda kendiniz kurarsınız. Zamanlanmış akışların tarih koşulları üç seçenek sunar: "bugünden önce (geçmiş)", "önümüzdeki X gün içinde" ve "X günden eski". Eskalasyon kademeleri de böyle kurulur: örneğin "durum Yeni ve oluşturulma 2 günden eski" koşuluyla yöneticiye bildirim. Hatırlatmayı sistemin işi haline getirmenin genel mantığı otomatik müşteri hatırlatma sistemi yazısında ayrıntılı anlatılıyor.

Hangi raporları kurarsınız?

Rapor listesinde talepler için iki hazır rapor gelir: Duruma Göre Talepler ve Önceliğe Göre Talepler. Gerisini Raporlar ekranından siz kurar, bir dashboard'a yerleştirir ve isterseniz e-posta aboneliği açarsınız. Talep objesinde raporlanabilir alanlar şunlardır: Konu, Durum, Öncelik, Kanal, Talep No ve Oluşturulma tarihi. Tarih alanı gün, hafta, takvim ayı, çeyrek ve yıl bazında gruplanabilir.

İki dürüst sınır: birincisi, SLA ihlali ve çözüm süresi rapor oluşturucuda alan değildir; ikisi de hesaplanan değerlerdir. İhlalleri ana sayfadaki SLA şeridinden ve bildirim merkezindeki Canlı SLA İhlalleri kartından izlersiniz. Aylık bir ihlal sayısı istiyorsanız talep listesini dışa aktarıp tabloda ayırmanız gerekir. İkincisi, kanal kırılımını rapor oluşturucuda güvenilir biçimde alamazsınız; kanal dağılımı için liste görünümünde Kanal kolonuna göre süzüp saymak ya da dışa aktarmak daha doğru sonuç verir.

Destek tarafını kurarken müşteri kayıtlarınız hâlâ tablolarda duruyorsa geçişe oradan başlamak mantıklı: Excel ile müşteri takibi rehberi hazır bir şablon ve taşıma sırası veriyor. Güncel rakamlar fiyatlandırma sayfasında, kendi verinizle denemek için demo talebi açabilirsiniz.

Sık sorulan sorular