# Şikâyet Kaydını Sahiplenme

Sayfa: https://alidemirbas.com.tr/lab/journeys/sikayet-sonrasi-iliskiyi-toparlama

Şikâyet açıldı → sorumlu ata → çöz → kapanışı doğrula

## Amaç

Yeni açılan şikâyeti doğru ekibe atayıp çözümü ve gerekiyorsa müşteri onayını takip etmek.

Hedef: Eskalasyon ve istisna · Kategori: Geri Bildirim & İletişim

## Adımlar

- **Tetikleyici**: İşlem yapılabilir sorun oluşturuldu
- **Aksiyon**: Sorun türünü, ciddiyet düzeyini, ilgili varlığı, SLA'yı ve kaynağı kaydet. Aynı temel soruna ait kopyalar iki kez işlenmek yerine burada birleştirilir
- **Karar**: Doğru sahip biliniyor mu?
  - Biliniyor: Sahibi ata ve atamayı eklenmiş şekilde kaydet - bir sorunu kimin ne zaman elinde tuttuğu, çözüm geçmişinin bir parçasıdır
  - Bilinmiyor: İş oluşturuldu → yönlendirme → atama
- **Aksiyon**: Sahibi ata ve atamayı eklenmiş şekilde kaydet - bir sorunu kimin ne zaman elinde tuttuğu, çözüm geçmişinin bir parçasıdır
- **Devir**: İş oluşturuldu → yönlendirme → atama - sahibi belirlenemeyen bir sorun
- **Bekleme**: sorunun operasyonel düzeltmesi tamamlandı olarak kaydedilene kadar - Zaman aşımı: Bekleme süresi, bu ciddiyet düzeyi için SLA eşiğidir; kaçırılması bir seviye yükseltmeye yol açar, asla müşteriye yansımaz. (configure complaint.sla_threshold)
- **Karar**: Kapanış, kişinin onayını gerektiriyor mu?
  - Onay gerekli: Onlara sormak için izin verilmiş bir kanal var mı?
  - Gerekli değil: Sorunu kapat, tüm çözüm geçmişini koruyarak: neyin yanlış olduğu, kimin sahiplendiği, ne yapıldığı, ne zaman yapıldığı ve kişinin bunu onayladığı
- **Aksiyon**: Bir seviye yükselt: bildirim gönder, ardından ekibi veya yöneticiyi dahil et, ardından öncelikli bir kuyruğa yeniden ata. Bu nedenle müşteriye yönelik hiçbir şey gönderilmez - iç gecikme bizim sorunumuzdur, onlar için yeni bir bilgi değildir
- **Karar**: Onlara sormak için izin verilmiş bir kanal var mı?
  - Bir kanal var: Bildirdikleri spesifik sorunun, gerçekte yapılan düzeltmeye göre şimdi çözülüp çözülmediğini sor. Kimseden istenmemiş bir onayı beklemek, bir onay durumu değildir; bu, onay kılığına girmiş bir zaman aşımıdır
  - Kanal yok: Sınırlı kapanış kuralı kapsamında kapat; düzeltmenin tamamlandığını ve kişinin hiçbir zaman onaylamadığını açıkça kaydet. Onaylanmış ve onaylanmamış kapanışlar farklı gerçeklerdir ve asla aynı şekilde yazılmaz - ve kapanışın, bildirimi yapan kişiye izin verilmiş bir kanal olmadığı için onaylanmamış olduğu durumlarda, bu neden sessizlik olarak değil, kendisi olarak kaydedilir
- **Aksiyon**: Sorunu kapat, tüm çözüm geçmişini koruyarak: neyin yanlış olduğu, kimin sahiplendiği, ne yapıldığı, ne zaman yapıldığı ve kişinin bunu onayladığı
- **Karar**: Yükseltme seviyeleri tükendi mi?
  - Seviye kaldı: sorunun operasyonel düzeltmesi tamamlandı olarak kaydedilene kadar
  - Tükendi: İnsan kontrolü journey'si
- **Aksiyon**: Bildirdikleri spesifik sorunun, gerçekte yapılan düzeltmeye göre şimdi çözülüp çözülmediğini sor. Kimseden istenmemiş bir onayı beklemek, bir onay durumu değildir; bu, onay kılığına girmiş bir zaman aşımıdır
- **Aksiyon**: Sınırlı kapanış kuralı kapsamında kapat; düzeltmenin tamamlandığını ve kişinin hiçbir zaman onaylamadığını açıkça kaydet. Onaylanmış ve onaylanmamış kapanışlar farklı gerçeklerdir ve asla aynı şekilde yazılmaz - ve kapanışın, bildirimi yapan kişiye izin verilmiş bir kanal olmadığı için onaylanmamış olduğu durumlarda, bu neden sessizlik olarak değil, kendisi olarak kaydedilir
- **Çıkış**: çözüldü ve onaylandı - aynı sorunun tekrar ortaya çıkması, bu sorunu yeniden açmak yerine ona bağlı yeni bir sorun olarak ele alınır
- **Devir**: İnsan kontrolü journey'si - yükseltme basamaklarını aşan bir sorun
- **Bekleme**: kişi sorunun çözüldüğünü onaylayana ya da sorunun çözülmediğini söyleyene kadar - Zaman aşımı: Kişiye onaylaması için sınırlı bir süre tanınır; bu sürenin ötesinde sorun, çözüldü olarak değil, hiç onaylanmadı olarak kaydedilerek sınırlı kapanış kuralı kapsamında kapatılır. (örnek: 5-10 gün; configure complaint.closure_window)
- **Çıkış**: operasyonel olarak düzeltildi - aynı sorunla ilgili daha sonraki her temas, bunun hiç doğrulanmadığını bilerek başlar; ayrımın kaydedilmesinin nedeni de budur
- **Karar**: Ne dediler?
  - Çözüldü: Sorunu kapat, tüm çözüm geçmişini koruyarak: neyin yanlış olduğu, kimin sahiplendiği, ne yapıldığı, ne zaman yapıldığı ve kişinin bunu onayladığı
  - Hâlâ düzelmedi: Yeniden açma sınırına ulaşıldı mı?
- **Karar**: Yeniden açma sınırına ulaşıldı mı?
  - Ulaşılmadı: sorunun operasyonel düzeltmesi tamamlandı olarak kaydedilene kadar
  - Ulaşıldı: Bir seviye yükselt: bildirim gönder, ardından ekibi veya yöneticiyi dahil et, ardından öncelikli bir kuyruğa yeniden ata. Bu nedenle müşteriye yönelik hiçbir şey gönderilmez - iç gecikme bizim sorunumuzdur, onlar için yeni bir bilgi değildir

## Koruma kuralları

- Sorumlu atanmadıysa kaydı sahipsiz bırakma.
- Müşteri onayı gerekiyorsa onay gelmeden kesin kapanış varsayma.

## Temel kural

Şikâyet, sorumlusu ve kapanış koşulu netleşene kadar açık kalır.

## Ne zaman kurulmalı?

Açılan şikâyet kayıtlarının bir bölümü sahipsiz bekliyor, SLA aşımları sessizce geçiyor ya da raporlarda operasyonel düzeltme ile müşterinin doğruladığı kapanış aynı şey sayılıyorsa bu journey'yi kur. Önce şikâyetin tür, önem derecesi ve ilgili kayıtla resmî olarak açıldığından, sorun türü ve kayıttan sahibin türetilebildiğinden, her önem derecesi için SLA eşiğinin tanımlı olduğundan ve onay sorusu için izinli bir iletişim kanalının kayıtlı olduğundan emin ol. Kayıtlar yalnızca olumsuz duygu puanından ya da henüz sonuçlanmamış destek görüşmelerinden açılıyorsa önce tetikleyicinin kaynağını düzelt; bu journey tespit edilmiş bir operasyonel hatayı takip eder.

## Nasıl kurulmalı?

- **Tetikleyici ve giriş**: Sistemde doğrulanmış, türü, önem derecesi ve ilgili kaydı olan bir sorun resmî olarak açıldığında journey başlar. Buradaki tek müşteri mesajı onay sorusu olduğu için rastgele bir kontrol grubu ayırma; sonucu girişteki tüm şikâyet kayıtları üzerinden ölç.
- **Kimler girmemeli**: Tek bir şikâyet kaydı tek bir journey örneğidir. Aynı temel soruna ait kopyalar girişte birleştirilir, ikinci bir kayıt açılmaz; yalnızca olumsuz duygu puanı ya da henüz bir hataya varmamış destek görüşmesi journey'yi başlatmaz.
- **Zamanlama ve kanallar**: Sahip biliniyorsa atanır ve operasyonel düzeltme kaydedilene kadar, o önem derecesinin SLA eşiği boyunca beklenir; süre dolarsa bir seviye yükseltilir ve müşteriye hiçbir şey gönderilmez. Düzeltme sonrası onay gerekiyorsa ve izinli bir kanal varsa e-posta ya da uygulama içi mesajla onay sorusu gider.
- **Çıkış ve devir**: Sahibi belirlenemeyen kayıt İş atama journey'sine, yükseltme basamakları tükenen kayıt İnsan kontrolü journey'sine devredilir. Kayıt ya çözüldü ve onaylandı olarak ya da onay penceresi dolduğunda veya izinli kanal yokken operasyonel olarak düzeltildi olarak kapanır.
- **Sıklık ve izin**: Onay sorusu her düzeltmeden sonra bir kez ve yalnızca sorun yazışması için izinli, ulaşılabilir bir kanal varsa gider; müşteri hâlâ düzelmedi derse kayıt yeniden açma sınırına kadar çözüme döner, sınırda yükseltilir. Etkileşim onay penceresini uzatmaz; atama ve yükseltme insana düşer, kayıt tüm geçmişiyle devredilir.

## Başarı nasıl ölçülmeli?

**Doğrulanan kapanış oranı**: Journey'nin amacı sahipli bir çözüm ve müşterinin doğruladığı bir kapanıştır; operasyonel düzeltmenin kaydedilmiş olması ya da onay sorusunun teslim edilmiş olması tek başına bunu göstermez. Girişte açılan tüm şikâyet kayıtları içinde, aynı takip süresinde çözüldü ve onaylandı olarak kapananların payı. Burada klasik kontrol grubu uygulanmaz; onay gerekmeyen kapanışları ayrı bir satırda göster ve mesajın teslimi ya da yanıtsız kalması paydayı değiştirmesin.

Ayrıca izle:

- **Çözüm oranı**: Açılan kayıtlar içinde operasyonel düzeltmesi SLA eşiği içinde kaydedilenlerin payı; onaydan önceki ara adımı ve yükseltmeye gitmeden kapanan işi gösterir.
- **Sahipsiz ve yükseltilen kayıt payı**: Sahibi belirlenemeyip devredilen kayıtlarla en az bir seviye yükseltilen kayıtları ayrı izle; ikisi de yükseliyorsa sorun atama kuralında ya da ekip kapasitesindedir.
- **Onaysız kapanış ve yeniden açma**: Onay penceresi dolduğu için ya da izinli kanal olmadığı için onaysız kapanan kayıtları ve müşterinin hâlâ düzelmedi dediği yeniden açmaları ayrı say; ikinci kümenin artması düzeltmenin gerçek sorunu kapatmadığını söyler.
- **Onay sorusu şikâyeti ve izin kapatma**: Onay sorusu gönderilen kişilerde e-posta aboneliğinden çıkma, uygulama içi mesaj tercihini kapatma ve destek başvurularını izle; onay istemek yeni bir şikâyet üretmemeli.

## Sonuç yorumlanırken nelere dikkat edilmeli?

- Doğrulanan kapanış oranını onaysız kapanışlarla birlikte oku: toplam kapanış artarken doğrulanan pay düşüyorsa kayıtlar hızlı değil sessiz kapanıyordur. Onay gerekiyorsa onay gelmeden kesin kapanış varsayma; yanıtsız kalan kayıt doğrulanmış memnuniyet değil, onaylanmamış kapanıştır.
- Sonuç bu SLA eşikleri, bu onay penceresi ve bu yeniden açma sınırı için geçerlidir. Sahipsiz devredilen ya da yükseltme basamaklarını aşıp İnsan kontrolü journey'sine giden kaydın sonucu o journey'ye yazılır; sahipsiz bırakılan bir kayıt bu journey'nin çözümü sayılmaz.
- Onaylı kapanış nadir bir sonuçsa ve kayıt sayısı azsa aylık oranlar oynar; iki dönemi ya da iki ekibi karşılaştırmadan önce [örneklem büyüklüğü hesaplayıcısıyla](https://alidemirbas.com.tr/hesaplayicilar/orneklem-buyuklugu-hesaplama) mevcut kapanış oranı ve görmek istediğin en küçük farka göre kaç kayıt gerektiğini hesapla, takip süresini onay penceresinin tamamını kapsayacak kadar uzun tut.

## Sık Sorulan Sorular

### Şikâyet kaydı açıldığında ilk sorumlu kim olmalı?

Sorunu çözebilecek doğru sahibi belirle ve atamayı kaydet. Sahip bilinmiyorsa iş atama yoluna geç, kaydı sahipsiz kapatma. Bu journey çözüm kaydını ve gerekiyorsa müşteri onayını izler. Sorumlunun atanması ile çözümün gerçekleşmesini ayrı tut.

### Müşteri yanıt vermediğinde şikâyet çözüldü sayılır mı?

Yanıt yokluğu çözüm onayı değildir. Operasyonel düzeltme kaydı ile müşterinin doğruladığı kapanışı ayrı raporla. Bu akışta onay gerekliliği ve iletişim yolu kontrol edilir. Yanıt alınamayan durumu doğrulanmış memnuniyet gibi etiketleme.

### Müşteri sorunun devam ettiğini söylerse ne yapılmalı?

Kaydı geçmişini koruyarak yeniden değerlendirmeye al. Aynı otomatik soruyu sınırsız tekrarlamak yerine tanımlı yeniden açma ve eskalasyon yolunu kullan. Sınır aşıldığında insan incelemesine geç. Önceki çözüm ve temasları yeni sorumluya aktar.