Yazıcı Arızasında Bekleme Süresini Düşürmek: AI Agent ve Otomatik Destek Nasıl Çalışır

Yazıcı arızalarında asıl maliyet cihazda değil, talebin açılması ile ilk yanıt arasında geçen ölü zamanda gizlidir. Bu yazı, AI agent ve servis masası otomasyonunun bu bekleme süresini somut olarak nasıl kısalttığını IT müdürü gözüyle ele alır.

30 Haziran 2026·yazar: Yilmaz Sarac
Bir yazıcının durması nadiren bir tek kullanıcıyı etkiler. Muhasebede tek bir cihazın hata kodu vermesi, ay sonu fatura koşusunun durması, deponun irsaliye basamaması ya da hasta taburu çıktı alamayan bir poliklinik anlamına gelebilir. IT müdürü olarak sizin için asıl sorun cihazın kendisi değildir; sorun, talebin açılması ile birinin gerçekten müdahaleye başlaması arasında geçen ölü zamandır. Bu yazıda o ölü zamanı, yani bekleme süresini, AI agent ve servis masası otomasyonunun nasıl düşürdüğünü somut adımlarla ele alıyoruz. ## Bekleme süresi nerede birikir Klasik yazıcı destek akışında kayıp zaman tek bir yerde değil, birçok küçük noktada birikir. Kullanıcı önce kime yazacağını bulmaya çalışır: ortak posta kutusu mu, telefon mu, koridordaki BT masası mı. Sonra hatayı tarif eder ama cihaz seri numarasını, model bilgisini ya da ekrandaki hata kodunu çoğu zaman vermez. Talebi alan kişi eksik bilgiyi tamamlamak için geri yazar. Bu gidip gelme, arıza henüz teşhis bile edilmeden saatleri yiyebilir. MPS dilinde bu ölü zamanın ölçülen karşılığı **ilk yanıt süresi** ve **MTTR** (ortalama onarım süresi) kavramlarıdır. İlk yanıt süresi, talep açıldıktan sonra ekibin ilk anlamlı temasına kadar geçen süredir. MTTR ise talebin açılışı ile kapanışı arasındaki toplam süredir. Bekleme süresini düşürmek demek, önce bu iki metriğin hesaplanabilir hale gelmesi, sonra da akışın ilk yanıt tarafından kısaltılması demektir. ## AI agent burada ne yapar, ne yapmaz Burada netlik önemli. Bir AI agent sihirli bir teşhis motoru değildir. Yaptığı şey, ilk temas anını yapılandırmak ve hızlandırmaktır. Kullanıcı talebi açarken agent doğru soruları doğru sırayla sorar: hangi cihaz, hangi seri numara, ekranda hangi hata kodu var, sorun yeni mi yoksa tekrar mı ediyor. Böylece teknisyene ulaşan talep, eksik değil tamamlanmış bir talep olur. Printage tarafında bu asistan **rehber temelli** çalışır. Yani önceden tanımlanmış sorun giderme rehberlerine (TroubleshootingGuide) dayanır; serbest çağrışımlı bir model değildir, kurumsal bir vektör arama da değildir. Kullanıcının tarif ettiği belirti, ilgili rehber adımına bağlanır ve çoğu basit vakada (kağıt sıkışması, toner uyarısı, kuyrukta takılı iş) kullanıcı teknisyeni beklemeden ilk müdahaleyi kendisi yapabilir. Yapamadığı durumda ise talep, artık tüm bağlamıyla birlikte doğru role aktarılır. Vektör temelli bilgi tabanı araması TYS Dijital Performans tarafında KnowledgeBase katmanında bulunur; Printage asistanının çalışma biçimi bundan ayrıdır ve onu rehber yapısından ibaret olarak konumlandırmak doğru olur. ## Çok rollü servis masası: talebin geçmesi gereken yol Bekleme süresini gerçekte düşüren şey, tek bir akıllı kutu değil, talebin üzerinden geçtiği yapının kendisidir. Printage çok rollü ve çok kiracılı bir servis masası olarak kuruludur: müşteri, teknisyen, admin ve superadmin rolleri ayrıdır. Bir kullanıcı talebi açtığında cihaz seri numarası, hata kodu ve öncelik bilgisiyle birlikte sisteme düşer. Talep, dosya yükleme alanı sayesinde bir ekran görüntüsü ya da fotoğrafla zenginleştirilebilir; bu, teknisyenin uzaktan teşhisini hızlandırır. Talep açıldıktan sonra otomatik e-posta bildirimi devreye girer, böylece kullanıcı talebinin alındığını koridorda birini kovalamadan görür. Talebe **token ile erişim** sayesinde, hesap açmadan da kişi kendi talebinin durumunu takip edebilir. Dashboard üzerinde her talep Beklemede, Müdahale ve Tamamlandı durumları arasında görünür kalır. IT müdürü için bunun anlamı şudur: hangi talep ne kadar süredir beklemede, hangisi müdahaleye geçmiş, anlık olarak görülür. ## Metrikleri uydurmadan: ölçülen ile yol haritasında olanı ayırmak Bu noktada dürüst olmak gerekir. Printage talep yaşam döngüsündeki ham zaman damgalarını tutar; yani bir talebin ne zaman açıldığı, ne zaman müdahaleye geçtiği ve ne zaman kapandığı kayıtlıdır. Bu ham veriyle ilk yanıt süresi, MTTR ve SLA uyumu **hesaplanabilir** metriklerdir. Raporlama tarafında veriler CSV (Excel uyumlu) olarak dışarı alınabilir, böylece bu KPI çerçevesi kendi tablonuzda kurulabilir. Ancak abartmamak gerekir: SLA eşiklerinin otomatik takibi ve ihlal anında uyarı gönderimi şu an için kodlu bir özellik değildir, yol haritasındadır. Native xlsx ya da PDF çıktısı yerine bugün CSV vardır. Online ödeme, muhasebe ya da B2B/B2C satış akışı Printage içinde yer almaz; bunlar TYS Dijital Performans paket katmanında konumlanır. Printage kurulu ve deploy edilebilir bir üründür; ama burada size canlı müşteri sayısı ya da yüzdesel bir başarı iddiası sunmuyoruz, çünkü doğru olan, ürünün ne yaptığını olduğu gibi anlatmaktır. ## IT müdürü için pratik sonuç Sektör verileri yardım masası vakalarında bekleme ve geri-bildirim döngüsünün toplam çözüm süresinin önemli bir bölümünü oluşturduğunu gösterir. Buradaki kazanç noktası nettir: talebi en baştan tam ve yapılandırılmış toplamak, doğru role otomatik yönlendirmek ve durumu şeffaf tutmak. AI agent bu zinciri hızlandıran ilk halkadır; çok rollü servis masası ise talebin kaybolmadan ilerlemesini sağlayan iskelettir. İkisi birlikte, cihazı değil, cihaz çevresindeki ölü zamanı hedef alır. Bir IT müdürü olarak değerlendirmeniz gereken soru şudur: talebiniz bugün nerede bekliyor ve o beklemeyi ölçebiliyor musunuz.

Diğer Yazılar

Kendi analiziniz için hazır mısınız?

Markanızın yapay zeka sistemlerinde nasıl temsil edildiğini öğrenin ve hedefe yönelik adım atın.

Analizi Başlat