Beyaz Eşya · Yetkili Servis Ağı
Bir servis ağı gün boyu birbirine soru sorar. Asıl mesele, bu soruların nereye gittiğidir.
BSH'nin yetkili servis ağında üç yılda 93.695 talep kayıt altına alındı. Bugün iş günü başına ortalama 155 talep, 338 kişi tarafından karşılanıyor.
Talep Yönetimi nedir?
Kurum içi taleplerin tek yerden açıldığı, bir sahibe düştüğü ve kapanana kadar izlendiği modül. BSH kurulumunda kullanıcı kitlesi merkez değil saha: yetkili servis noktaları, teknisyenler, bölge sorumluları.
Tek bir fikir üzerine kurulu: bir talep, bir mesaj değil bir kayıttır. Doğar, bir sahibi olur, el değiştirir, üzerine not yazılır, dosya eklenir ve bir gün kapanır. Bütün bu yolculuk görünür ve geriye dönük okunabilir olmalıdır.
Zorluk: trafik görünüyordu, kaydı yoktu.
Yetkili servis noktası merkeze yazar: “Bu fişi iptal edebilir miyiz?” Teknisyen bölge sorumlusuna yazar: “Bu ürünün garanti kaydı yanlış görünüyor.” Bölge controlling'e yazar: “Tahsilat havuzunda hata var.”
Bu trafiğin tamamı e-posta, telefon ve WhatsApp üzerinden yürüdüğünde üç şey olur:
- Talep kaybolur. Cevap bekleyen mesaj, gelen kutusunda yüzlerce mailin arasına karışır. Kimse kötü niyetli değildir; sadece görünmez olmuştur.
- Kimin işi olduğu belirsizleşir. “Ben senin ilettiğini sanmıştım” cümlesi, kurumsal hafızanın olmadığı her yerde aynı sıklıkta duyulur.
- Ölçemezsiniz. Kaç talep geldiğini, ne kadar sürede kapandığını, hangi konunun tekrar tekrar geldiğini kimse bilmez. Bilmediğiniz şeyi iyileştiremezsiniz.
BSH'nin servis ağında bu trafiğin hacmi küçük değildi: bugün ölçtüğümüzde iş günü başına ortalama 155 talep çıkıyor. Yani her iş günü, 155 ayrı konunun bir yerlerde takip ediliyor olması gerekiyordu.
Çözüm: talep bir mesaj değil, bir kayıt.
Kurulum üç adımda yapılandırıldı.
1. Konu haritası çıkarıldı. Servis ağının merkeze ne sorduğu tek tek listelendi ve kategori ağacına dönüştürüldü. Bugün sistemde 604 kategori tanımlı, 319'u aktif kullanımda. Bu bir fazlalık değil, tam tersi: ne kadar ince kırılım, o kadar doğru adresleme demek. Başlıklar sahanın kendi diliyle yazıldı.
2. Her kategoriye sorumlu atandı. Talep artık “merkeze” değil, o konunun sahibine düşüyor. Bugün 338 kişi talep karşılıyor. Kimse gelen kutusunu tarayarak kendi işini aramıyor; iş kendisine geliyor.
3. Süre taahhüdü tanımlandı. Her kategorinin tahmini çözüm süresi var. Ekranda kalan süre yazıyor ve süre aşıldığında kırmızıya dönüyor. Kimsenin rapor çekmesine gerek kalmadan geciken iş kendini gösteriyor.
Uygulamada: bir talebin akışı
Bir yetkili servis noktası “Ek garanti olmasına rağmen kapatılan iş emri” kategorisinde talep açar, fiş numarasını ve ekran görüntüsünü ekler. Talep, o kategorinin sorumlusuna düşer. Sorumlu talebi işleme alır, gerekirse talep sahibine soru sorar, konu başka bir birimi ilgilendiriyorsa yönlendirir. Her adım, kimin yaptığı ve ne not düştüğüyle birlikte işlem geçmişine yazılır. Talep kapandığında talep sahibi memnuniyet puanı verir.
Bu akışın gerçek hayattaki karşılığı ölçülebilir:
- Sistemde 326.439 işlem adımı kayıtlı — talep başına ortalama 3,5 adım. Tipik bir talep, açılıp kapanana kadar üç buçuk kez el değiştiriyor ya da üzerine not düşülüyor. Bu adımların hiçbiri kimsenin hafızasında değil.
- Taleplerin %35,5'inde ek dosya var; toplam 40.346 belge talebin kendi kaydına bağlı duruyor. Fiş görüntüsü, arıza formu, ekran görüntüsü — hepsi aylar sonra aynı yerden bulunabiliyor.
- Taleplerin %18,3'ü en az bir kez yönlendirilmiş; toplam 135.434 yönlendirme. Bu “yanlış kapıya çalınan zil” sayısı değil; doğru kişiye ulaşana kadar talebin kaybolmadan yol alması demek.
- Yoğun dönemlerde sistem geri çekilmedi: en yoğun ay Ekim 2025'te 3.947 talep.
Vekâlet mekanizması da işin sürekliliğini koruyor: sorumlu izne çıktığında talepleri vekiline düşüyor, kimse “o kişi yok” diye beklemiyor.
Kategori ağacı sahadan çıkar
Bu tür projelerde en sık yapılan hata, kategorileri departman isimlerinden türetmektir: “IT”, “Lojistik”, “Finans”. Kullanıcı ise departman adıyla düşünmez; derdiyle düşünür. “Fişim kapanmıyor” diyen bir teknisyen, bunun controlling'in mi lojistiğin mi işi olduğunu bilmek zorunda değildir — bilmesi de gerekmez.
BSH kurulumunda kategoriler sahanın cümleleriyle yazıldı. Sonucu rakamda görünüyor: en yoğun beş kategori toplam hacmin üçte birini taşıyor.
| Kategori | Talep |
|---|---|
| Sipariş İptal Talebi — Servis Lojistik | 10.856 |
| ENR — Ürün bilgileri düzeltme | 7.145 |
| Ek garanti olmasına rağmen kapatılan iş emri | 5.339 |
| Tahsilat Hata Havuzu — Controlling | 4.486 |
| YS Teknisyen — İşe giriş | 2.971 |
Bu tablo aynı zamanda bir iyileştirme haritasıdır: on binden fazla sipariş iptali talebi geliyorsa, asıl soru “bu talepleri nasıl daha hızlı karşılarız” değil, “sipariş iptalini neden bu kadar sık konuşuyoruz” olur.
Talep Yönetimi'nin en değerli çıktısı çözülen talepler değil, sorulmaya başlanan sorulardır.
Sonuçlar
Hiçbir talep kaybolmuyor. Kapanma oranı %98,9. Sistemde şu an işlem bekleyen yalnızca 972 talep var — üç yılda biriken 93 binin içinde. Geri kalanı sonuca bağlanmış durumda.
Üçte biri aynı gün çözülüyor. Taleplerin %33,4'ü açıldığı gün, %61,5'i üç gün içinde kapanıyor. Ortalama kapanış süresi 8,2 gün — bu ortalamayı yukarı çeken, tedarik veya üçüncü taraf beklentisi olan uzun kuyruk.
Kullanıcı memnun. Talep sahiplerinin verdiği 2.481 puanlamada ortalama 3,94/5; puanlamaların %70,4'ü tam puan. Bu, sistemin kendisine değil aldıkları hizmete verilen not — ve o hizmetin ölçülebilir hale gelmiş olmasına.
Kurumsal hafıza oluştu. Üç yıllık 326 bin işlem adımı ve 40 bin belge aranabilir durumda. Bir yıl önceki bir kararın neden alındığı, kimin ne yazdığı bugün beş saniyede bulunuyor.
Sistem ölçekle büyüdü. 2024'te 28.137, 2025'te 35.206 talep. Kullanım arttıkça süreç bozulmadı; aksine kategori ağacı zenginleşti ve adresleme keskinleşti.
Değerlendirme
Talep Yönetimi bir bilet sistemi değil, bir sorumluluk sistemidir. Farkı şurada: bilet sistemi işi kuyruğa alır, sorumluluk sistemi işi bir kişiye bağlar.
BSH vakasında üç tasarım kararı belirleyici oldu:
- Talep, kategorinin sorumlusuna düşer — havuza değil. Havuzdaki iş kimsenin işidir, yani kimsenin değil.
- Süre, kategoriye tanımlanır — talebe değil. “Fiş iptali 2 gün, teknisyen işe giriş 5 gün” demek, tek tek talep başında pazarlık yapmayı ortadan kaldırır.
- Yönlendirme bir kaçış değil, kayıtlı bir devirdir. Kim kime, hangi notla devretti — hepsi görünür. Bu şeffaflık, yönlendirmeyi sorumluluktan kaçma aracı olmaktan çıkarır.
Infinity Talep Yönetimi, hâlihazırda InfinityLMS kullanan kurumlarda ek bir sistem kurmadan devreye alınır. Kullanıcılar aynı platformda, aynı şifreyle taleplerini açar; yöneticiler aynı panelden süreci izler. Modülü inceleyin →
Tüm veriler 11 Eylül 2026 itibarıyla canlı sistemden ölçülmüştür. Kişisel veri içermez; kullanıcı adı, e-posta ve talep içeriği kullanılmamıştır.
Kurumunuzdaki talep trafiğini haritalayalım.
Hangi konuların kategori olması gerektiğini birlikte çıkaralım, pilot bir birimle başlayalım.
