İçeriğe atla
Özel Yazılım

Müşteri şikâyeti telefonda çözülüyorsa aynı hata tekrar eder

Doğukan Azer ÇİFTCİ

Yazılım Mühendisi

9 dk okuma

Paylaş
Müşteri şikâyeti telefonda çözülüyorsa aynı hata tekrar eder

Fotoğraf: Ruslan Alekso / Pexels

Telefonda çözülen şikâyet çözülmüş sayılmaz; sadece kapatılmış olur. Kayıt kalmadığı için aynı hata birkaç ay sonra başka bir siparişte yeniden çıkar ve kimse bunun ikinci kez olduğunu fark etmez. Üretim yapan firmalarda şikâyet yönetiminin çökme biçimi neredeyse hep aynıdır: müşteri satışçıyı arar, satışçı üretim sorumlusuna anlatır, parça yeniden gönderilir ya da fiyattan düşülür, konu kapanır. Ortada ne bir kayıt, ne bir neden, ne de bir sorumlu vardır. Kurulması gereken şey karmaşık bir kalite sistemi değil; şikâyetin bir numara aldığı, bir partiye bağlandığı, bir nedene oturduğu ve kapanışı bir kişiye yazılı olarak düşen basit bir zincirdir.

Bu yazı, ISO belgesi almak için doküman üretmekten değil, tekrar eden hatayı görünür kılmaktan bahsediyor. Belgeye zaten aynı zincir yarıyor; ama asıl kazanç, üçüncü kez aynı yüzey hatasını konuşmamak.

Şikâyet kaydında hangi alanlar gerçekten gerekli

Kayıt formu uzadıkça doldurulmaz. Şikâyeti alan kişi çoğu zaman telefondadır ve elinde tek bir ekran vardır. O yüzden alan listesini, sonradan analiz yapmayı mümkün kılan en küçük kümede tutmak gerekir.

  • Kim bildirdi: müşteri firma, bildiren kişi ve iletişim kanalı. Aynı müşterinin farklı kişilerinden gelen şikâyetler ayrı ayrı durmalı.
  • Ne oldu: müşterinin kendi cümlesiyle tarif. Burada teknik terim düzeltmeye çalışmayın; ham ifadeyi saklayın, sınıflandırmayı ayrı alanda yapın.
  • Hangi ürün, hangi miktar: ürün kodu ve şikâyete konu adet. Toplam sevkiyatın ne kadarının etkilendiği, sonradan yapılacak her değerlendirmenin girdisidir.
  • Hangi sevkiyat ve parti: irsaliye numarası, sipariş numarası ve üretim partisi.
  • Şikâyet tipi: ölçü, yüzey, montaj uyumsuzluğu, eksik gönderi, ambalaj hasarı, gecikme gibi kısa ve sabit bir liste.
  • Talep edilen şey: değişim, iade, yerinde düzeltme, iskonto ya da sadece açıklama. Müşterinin ne istediği ile firmanın ne yaptığı çoğu zaman aynı değildir; ikisini de yazın.

Şikâyeti alan kişi bunları doldurabiliyorsa yeterlidir. Kök neden, sorumlu, aksiyon gibi alanlar sonradan kalite tarafından girilir; ilk kayıt anında bunları zorunlu tutmak, kaydın hiç açılmamasına yol açar.

Şikâyeti partiye bağlamadan analiz yapılamaz

Şikâyet kaydının tek başına anlamı sınırlıdır. Değerli olan, o şikâyetin hangi üretim partisine ve hangi sevkiyata ait olduğunun bilinmesidir. Parti bağlantısı olmadığında elinizde yalnızca müşteri memnuniyetsizliği listesi kalır; hangi hammadde lotunda, hangi vardiyada, hangi tezgâhta yoğunlaştığını göremezsiniz.

Pratikte en çok tıkanan nokta şudur: müşteri şikâyet ederken parti numarası vermez, elindeki irsaliyeyi ya da fatura tarihini söyler. Bu yüzden sistemin irsaliyeden partiye gidebilmesi gerekir. Sevkiyat kaydı hangi partiden ne kadar çıktığını tutuyorsa, şikâyeti alan kişi sadece irsaliye numarasını yazar; parti bağlantısını sistem kurar. Bu bağ kurulamıyorsa şikâyet kaydı açılmasın demeyin — kaydı yine açın, parti alanını boş bırakın ve bu boşluğun kendisini bir eksiklik olarak raporlayın. Parti bağlantısı kurulamayan şikâyet oranı, izlenebilirliğin ne durumda olduğunu gösteren en dürüst göstergedir.

Aynı şey ters yönde de işler. Bir partide sorun tespit edildiğinde, o partiden hangi müşterilere ne kadar gittiğini görebilmek gerekir. Bu görünürlük yoksa geri çağırma ya da önden bilgilendirme kararı tahminle verilir.

Kök neden aramak ile sorumlu aramak aynı şey değil

Kök neden analizi, kayıt sisteminin en kolay çöken parçasıdır. Çünkü çoğu firmada bu alan pratikte suçlu bulma alanına dönüşür ve doldurulan cevaplar “operatör dikkatsizliği” ya da “insan hatası” olur. Bu cevap hiçbir zaman kök neden değildir; olsa olsa olayın en son halkasıdır. Operatörün neden hata yapabildiğini soran ikinci bir adım yoksa analiz orada biter.

Kök neden alanını işler kılmanın birkaç basit yolu var:

  • Nedeni kategorileyin: yöntem, malzeme, makine, ölçüm, bilgi akışı, tedarikçi gibi az sayıda sabit sınıf. Serbest metin analiz edilemez; sınıf edilir. Serbest metni açıklama olarak yanına koyun.
  • “Neden buraya kadar geldi” sorusunu ayrı sorun: hata üretimde oluşmuş olabilir ama kontrolden geçip müşteriye ulaşmışsa iki ayrı zayıflık vardır. Oluşma nedeni ve kaçma nedeni ayrı yazılmalı.
  • Analizi kaydı açan kişiye bırakmayın: satışçı müşterinin dediğini yazar; nedeni üretim ve kalite birlikte girer. Aynı formu iki farklı rolün farklı zamanlarda doldurması normaldir.
  • Boş bırakmaya izin verin, ama görünür bırakın: nedeni bulunamayan şikâyetler ayrı bir listede dursun. Bu liste büyüyorsa sorun analiz disiplinindedir.

Düzeltici faaliyet kapanmadan şikâyet kapanmaz

Şikâyetin kapanışı ile düzeltici faaliyetin kapanışı iki ayrı şeydir. Müşteriye yeni parça gönderilmiş ve müşteri tatmin olmuş olabilir; bu, hatanın bir daha çıkmayacağı anlamına gelmez. Bu yüzden kayıtta iki ayrı durum tutulur: müşteriye dönük çözüm ve içeriye dönük önlem.

Düzeltici faaliyetin işlemesi için üç şey yeterlidir: ne yapılacağı, kimin yapacağı ve ne zamana kadar. Sorumlu bir ekip değil bir kişi olmalı; “üretim” sorumlu yazıldığında kimse sorumlu değildir. Tarih geçtiğinde kaydın kendiliğinden gecikmiş duruma düşmesi ve o kişinin listesinde durması gerekir. Aksiyon türlerini de ayırmakta fayda var: geçici önlem (ek kontrol, ayıklama) ile kalıcı önlem (fikstür değişikliği, iş talimatı güncellemesi, tedarikçi şartnamesi) aynı satırda tutulursa, geçici önlem kalıcı sanılır ve iş orada kalır.

Son adım genellikle atlanır: etkinlik doğrulama. Önlem alındıktan sonra bir süre geçmeli ve aynı ürün ya da süreçte hatanın tekrar edip etmediğine bakılmalı. Doğrulama yapılmadan kapatılan faaliyetler, tekrar eden şikâyetlerin ana kaynağıdır. Kayıtta “kapandı” ile “doğrulandı” ayrı durumlar olsun.

Aynı şikâyetin tekrar ettiğini nasıl görürsünüz

Tekrarı görmek, kayıt tutmanın asıl sebebidir ve tek başına listeleme yetmez. Bir şikâyetin tekrar olduğunu anlamak için en az üç kırılımdan bakabilmek gerekir: aynı müşteriden gelen aynı tipteki şikâyetler, aynı ürün kodunda görülen aynı tipteki şikâyetler ve aynı kök neden sınıfına düşen şikâyetler. Üçüncüsü en değerlisidir, çünkü farklı ürünlerde ve farklı müşterilerde görünen tek bir yapısal sorunu ortaya çıkarır.

Pratik bir düzenleme: kayıt açılırken sistem, aynı müşteri ve aynı ürün kodunda geçmişte kapanmış şikâyet varsa bunu ekranda göstersin. Kaydı açan kişi böylece ilk andan “bu ikinci kez” bilgisiyle çalışır ve şikâyeti önceki kayda bağlayabilir. Tekrar eden şikâyetin ayrı bir işaretle durması, yönetim toplantısında konuşulacak listeyi kendiliğinden üretir.

Aylık bakılacak şey uzun rapor değil, birkaç kısa listedir: açık şikâyetler, tarihi geçmiş düzeltici faaliyetler, kök nedeni girilmemiş kayıtlar ve tekrar işaretli olanlar. Bu dört liste kısa kalıyorsa sistem çalışıyordur.

Ana sanayi düzeltici faaliyet raporu istediğinde ne olur

Otomotiv, beyaz eşya ya da savunma tarafına çalışan bir tedarikçiyseniz, şikâyetin ardından resmi bir rapor talebi gelir. İstenen format firmadan firmaya değişse de sorulan şeyler ortaktır: olayın tanımı, etkilenen miktar ve parti, alınan acil önlem, kök neden, kalıcı önlem, etkinlik doğrulaması ve benzer ürünlere yayılım değerlendirmesi. Bu bilgiler kayıt sırasında toplanmışsa rapor derlemek birkaç saatlik iştir; toplanmamışsa geriye dönük hatırlamaya çalışmak günler alır ve çoğu alan tahminle doldurulur.

Bu yüzden şikâyet kaydının alanlarını, talep edilen rapor başlıklarıyla aynı mantıkta kurmak işi çok kolaylaştırır. Amaç kaydı ağırlaştırmak değil; zaten sorulacak olan soruların cevabını olayın sıcağında, doğru bilinen anda yazmaktır. Bir de şu var: raporun müşteriye hangi tarihte, kim tarafından, hangi içerikle gönderildiği de kayda düşmeli. Müşteriye ne cevap verildiğinin bilinmemesi, şikâyetin kendisi kadar sorun yaratır — özellikle satışçı değiştiğinde.

Kaydı kim açar, sistem kimin masasında durur

Şikâyet çoğunlukla satışa gelir, ama kalite tarafından yönetilir. Bu ayrım netleştirilmezse kayıt ya hiç açılmaz ya da iki yerde birden tutulur. İşleyen kurgu genellikle şudur: kaydı ilk temas noktası açar, çünkü en hızlı odur; nedeni ve aksiyonu kalite ile üretim doldurur; müşteriye dönüşü yine satış yapar ama kapanış bilgisini sistemden alır.

Kaydın açılmasını kolaylaştırmak, disiplinden daha çok işe yarar. Telefon kapanmadan doldurulabilecek kadar kısa bir ekran, mobilden erişilebilir olması ve zorunlu alanların azlığı, “sonra girerim” ile kaybolan kayıtları büyük ölçüde önler. Küçük bir firmada bunun elektronik tablo ile başlaması da mümkündür; ama parti bağlantısı, gecikme takibi ve tekrar uyarısı istendiği anda tablo yetmemeye başlar.

Kısaca

  • Telefonda çözülen şikâyet kayıt bırakmaz; kayıt yoksa tekrar da görünmez.
  • Kayıt kısa olsun ama mutlaka sevkiyat ve parti bağlantısı kurulsun; bağ kurulamayan kayıtların oranı ayrıca izlensin.
  • Kök nedeni serbest metin yerine sabit sınıflarla tutun; oluşma nedeni ile kaçma nedenini ayrı yazın.
  • Düzeltici faaliyette tek bir sorumlu kişi ve tarih olsun; “kapandı” ile “etkinliği doğrulandı” ayrı durumlar olarak dursun.
  • Tekrar eden şikâyeti müşteri, ürün ve kök neden kırılımlarında görün; kayıt açılırken geçmiş şikâyet ekranda çıksın.
  • Rapor istendiğinde derlenecek bilgiler, olayın sıcağında toplanmışsa iş birkaç saatlik; toplanmamışsa tahmine dönüşür.

Sıkça Sorulan Sorular

Her müşteri memnuniyetsizliği şikâyet kaydı açılmasını gerektirir mi?
Kayıt eşiğini yüksek tutarsanız veri toplanmaz, çok düşük tutarsanız sistem gürültüye boğulur. Pratik bir ayrım şudur: ürünün ya da sevkiyatın şartnameye uymadığı iddiası varsa kayıt açılır, bu iddia sonradan haksız çıksa bile. Bilgi talebi, fiyat itirazı ya da genel memnuniyetsizlik ayrı bir yerde tutulabilir. Haksız çıkan şikâyetleri silmeyin; 'doğrulanmadı' sonucuyla kapatın, çünkü bu kayıtlar da müşteri algısı hakkında bilgi verir.
Şikâyet kaydını Excel ile yürütmek yeterli olur mu?
Küçük hacimde ve tek kişi doldurduğu sürece başlangıç için olabilir. Sınırlar hızlı gelir: aynı dosyayı birkaç kişi aynı anda kullanamaz, gecikmiş aksiyonlar kendiliğinden uyarı vermez, sevkiyat ve parti verisiyle bağ kurulamaz, geçmiş şikâyetin tekrar olduğunu kayıt anında gösteremez. Elektronik tabloyla başlayacaksanız alan yapısını baştan doğru kurun; taşınması gereken şey dosya değil, alanların anlamıdır.
Kök neden analizini kim yapmalı, kalite biriminde kimse yoksa ne olur?
Ayrı bir kalite birimi olmayan firmalarda bu iş genellikle üretim sorumlusuna düşer, ki bu kendi işini denetlemek anlamına geldiği için zayıf bir kurgudur. Uygulanabilir bir çözüm, analizi tek kişiye bırakmak yerine kısa bir toplantıya bağlamaktır: haftada bir, açık şikâyetler üretim ve satış birlikte gözden geçirilir. Kararın yazılı düşmesi, kimin yazdığından daha önemlidir.
Şikâyeti sipariş yerine partiye bağlamak neden daha önemli?
Sipariş bağlantısı ticari tarafı çözer, kimin ne aldığını gösterir. Partiye bağlanmadığında ise hatanın üretimdeki kaynağı görünmez: aynı hammadde lotunun başka siparişlere de gittiğini, sorunun belirli bir vardiyada ya da tezgâhta yoğunlaştığını göremezsiniz. İdeal olan ikisinin birden tutulmasıdır; sevkiyat kaydı hangi siparişe hangi partiden mal çıktığını tutuyorsa bu bağ kendiliğinden kurulur.
Müşteriye gönderilen cevabın da sistemde durması gerekir mi?
Evet, ve bu en sık atlanan parçadır. Müşteriye ne söylendiğinin kayıtta olmaması, aynı konu tekrar açıldığında firmanın kendi kendisiyle çelişmesine yol açar. Özellikle taahhüt içeren cevaplar — yeniden kontrol sözü, süreç değişikliği vaadi — mutlaka kayıtta dursun. Satış temsilcisi değiştiğinde geriye kalan tek şey bu kayıtlardır.
Düzeltici faaliyetin işe yaradığını nasıl anlarız?
Tek ölçüt, aynı kök neden sınıfındaki şikâyetlerin sonraki dönemde tekrar edip etmediğidir. Bunu görebilmek için önlemin uygulandığı tarihin kayıtlı olması ve o tarihten sonraki şikâyetlerin ayrıca izlenmesi gerekir. Belirli bir süre ya da belirli sayıda parti sonrası bakılmalı; hemen ertesi gün kapatılan doğrulama gerçek doğrulama değildir. Tekrar çıkarsa faaliyet kapatılmaz, yeniden açılır.

Yazar

Doğukan Azer ÇİFTCİ

Yazılım Mühendisi

QuantKOD’da yazılım mühendisi. Ölçeklenebilir mimariler, özel yazılım geliştirme ve doğru teknoloji seçimleri üzerine yazıyor.

İlgili yazılar

Hazır mı, özel mi? Birlikte karar verelim

Süreçlerinizi kısa bir görüşmede dinleyip, ihtiyacınıza en uygun çözümü ve yol haritasını dürüstçe çıkaralım.