# Yapay Zekâ Gerekli mi, Yoksa Yanlış Sorunu mu Çözüyoruz?

> Geciken su siparişleri üzerinden AI, süreç iyileştirme ve ürün yönetimi: Çağrı merkezi KPI’ları düzelirken müşterinin sorunu neden devam edebilir?

> **TL;DR:** Yapay zekâ, müşterinin şikâyetine daha hızlı yanıt vermemizi sağlayabilir. Ama şikâyete yol açan sorun devam ediyorsa, çağrı merkezindeki iyileşmeyi bütün sürecin başarısı sayamayız. Ürün ve proje yöneticileri, bir çözümü ne kadar hızlı geliştirebildikleri kadar hangi sorunu çözdüklerine de bakmalı. Bazen ilk yapılacak iş yeni bir AI sistemi kurmak değil, müşteriyi aramak zorunda bırakan aksaklığı gidermektir.

Mobil uygulamadan su siparişi veriyorum. Normalde iki saat içinde gelmesini beklediğim sipariş bazen iki gün sonra geliyor. Bazen de hiç gelmiyor. Ben çağrı merkezini arıyorum, şikâyet bırakıyorum. Bayiye ilettiklerini söylüyorlar. Ardından yine bekliyorum.

Bunu defalarca yaşadım ve hâlâ yaşıyorum. Şirketin gerçek adını kullanmayacağım, burada ona “Bayat Su” diyelim. Anlattığım teslimat sorunu kendi deneyimim. Birazdan kuracağım yapay zekâ senaryosu ise varsayımsal; şirketin böyle bir sistem kullandığını veya bu sonuçları elde ettiğini söylemiyorum.

Bayat Su'nun sipariş durumunu telefonda anlatan, iki saati geçen gecikmelerde bayiye otomatik bildirim gönderen ve WhatsApp şikâyetlerini yanıtlayan bir AI sistemi kurduğunu düşünelim. Müşteri temsilcisine ulaşmak için beklemem gerekmiyor. Sistem saniyeler içinde yanıt veriyor.

Fakat bugün verdiğim su siparişi hâlâ yarın öğleden sonra gelebiliyorsa, müşteri olarak benim sorunum ne kadar çözülmüş oluyor?

## Çağrı merkezinin göstergeleri düzelirken teslimat gecikebilir

Bu varsayımsal projenin üç ay sonraki sunumunda gayet iyi görünen sonuçlar yer alabilir. Yapay zekânın yanıtladığı talep sayısı artmış, telefonda bekleme süresi kısalmış, çalışanlara aktarılan çağrılar azalmış olabilir. Belki kadro ihtiyacındaki azalma da tasarruf olarak anlatılır.

Bunlar uydurma kazanımlar olmak zorunda değil. Bekleme süresinin kısalması bana da yarar. Çalışanların aynı sipariş sorusunu tekrar tekrar yanıtlamak zorunda kalmaması da anlamlıdır. Ancak bu ölçümler, suyun zamanında teslim edildiğini göstermiyor.

Çağrı merkezinden sorumlu ekip kendi hedefini tutturmuş olabilir. Ben ise siparişim gelecek mi, yeniden aramam gerekecek mi diye düşünmeye devam ederim. Üstelik şikâyeti yanıtlamak sistemde “talep çözüldü” diye kaydediliyorsa, işletmenin gördüğü sonuçla benim yaşadığım sonuç iyice ayrılır.

Şikâyetin yanıtlanması, siparişin tamamlanması ve müşterinin belirsizliğinin giderilmesi ayrı ayrı izlenmeli. Birincisi iyileşirken diğer ikisi yerinde sayabilir.

## Müşteriyi aramak zorunda bırakan ne?

Bayat Su'daki gecikmenin nedenini dışarıdan bilmiyorum. Sipariş bayiye geç mi ulaşıyor? Bayinin teslimat kapasitesi mi yetersiz? Uygulamada gösterilen süre, sahadaki koşullarla uyuşmuyor mu? Geciken siparişin sorumluluğunu kimse üstlenmiyor mu? Bunlar teşhis değil, incelenmesi gereken olasılıklar.

Bu soruların cevabı hangi müdahalenin işe yarayacağını değiştirir. Siparişler belirli bir adımda bekliyorsa, önce o adımın neden ilerlemediğine bakmak gerekir. Uygulama yerine getirilemeyecek bir teslimat süresi gösteriyorsa, müşteriye verilen söz de yeniden ele alınmalıdır. Bazen yetkiyi netleştirmek veya kapasiteye göre sipariş kabul etmek, yeni bir yapay zekâ sisteminden daha doğrudan bir çözüm olabilir.

Aynı şey otomatik bayi bildirimi için de geçerli. Bildirimi alan kişinin ne yapacağı, hangi yetkiye sahip olduğu ve çözülemeyen siparişin kime taşınacağı belli değilse, daha çok bildirim göndermek teslimatı hızlandırmayabilir. Bildirim bir eylemi başlatıyorsa değer kazanır; yalnızca “ilettik” cevabını otomatikleştirmekle yetinmemeliyiz.

Gecikmeyi önleyebildiğimiz siparişlerde, o gecikme yüzünden yapılan aramaya da ihtiyaç kalmayabilir. Böylece çağrı merkezi yükünü, müşterinin sorununu gidererek azaltmış oluruz. Bunun ne kadarını yapabildiğimizi de teslimat verisinden görmemiz gerekir.

## Hızlı prototip, doğru önceliği kendiliğinden göstermiyor

Yapay zekâ yardımıyla çalışan bir ekranı veya sesli yanıt demosunu daha kısa sürede hazırlayabiliyoruz. Demo toplantıda gösterilebiliyor, denenebiliyor ve bütçesi konuşulabiliyor. Bayinin kapasitesini, iş paylaşımını veya teslimat taahhüdünü değiştirmek ise farklı ekipleri aynı masaya getirmeyi gerektirebilir.

Görünür bir yazılımı yapmak, dağınık bir operasyon sorununu çözmekten daha kolay ilerliyorsa, önceliği de yazılıma verme eğilimimiz olabilir. Ürün ve proje yöneticilerinin bu noktada durup çözümün neyi değiştireceğini sorması gerekir.

Ürün yöneticisi, “Müşteri sipariş durumunu daha hızlı öğrensin” hedefinin ihtiyacın ne kadarını karşıladığını incelemeli. Proje yöneticisi de sistemin zamanında devreye alınmasıyla beklenen işletme sonucunun ortaya çıkmasını ayrı takip etmeli. Teslimat tarafındaki değişikliğin sahibi başka bir ekip olabilir; yine de bağımlılığı proje planında görünür tutmak gerekir.

Örneğin projeye şu başarı cümlesiyle başlamak farklı bir tartışma açar: “Geciken siparişleri ve aynı sipariş için tekrar iletişime geçme ihtiyacını azaltmak istiyoruz.” Böyle yazınca seçenekler sesli yanıt sistemiyle sınırlı kalmaz. Süreç değişikliği, mevcut yazılımda küçük bir düzenleme veya ikisinin birlikte yapılması da aynı hedef üzerinden değerlendirilebilir.

## Başarı sunumunda hangi sonuçları görmek isterim?

Bu projeyi değerlendirirken yanıt süresinin yanında, zamanında teslim edilen siparişlerin oranını ve gecikmelerin ne kadar sürdüğünü görmek isterim. Aynı sipariş için kaç kez arandığı, kaç siparişin hiç teslim edilmediği ve iptal edildiği de müşteri tarafındaki sonucu anlamaya yardım eder.

Bu verileri sipariş hacmiyle birlikte okumak gerekir. Daha az sipariş alınan bir dönemde çağrıların azalması, projenin başarısını tek başına göstermez. Müşteri yanıt alamayacağını düşünüp aramaktan vazgeçmiş de olabilir. Bu yüzden çağrı sayısı düştüğünde, siparişlerin ve müşterilerin başına ne geldiğini de incelemeliyiz.

Küçük bir denemede önce tek bir bölgede veya bayide aksaklığın nedenini araştırıp süreç değişikliğinin sonucunu izleyebiliriz. Ardından hâlâ karşılanmayan bilgi ihtiyacı varsa, AI desteğini o ihtiyaç için değerlendirebiliriz. Her denemeyi geniş bir dönüşüm projesine çevirmek zorunda değiliz.

## Yapay zekâyı nerede kullanacağımıza nasıl karar verelim?

Teslimat sorununun çözümü zaman alabilir. Bu sırada müşteriye doğru bilgi vermek, gerçekleşebilir bir teslimat zamanı sunmak veya iptal talebini sonuçlandırmak değerli işlerdir. AI bunlara yardımcı olabilir. Ancak bilgi ve işlem yetkisi eksikse, sistem de müşteriye güvenilir bir çözüm sunamaz.

Benim eleştirim, müşterinin yaşadığı aksaklık sürerken daha hızlı yanıt vermeyi yeterli başarı saymamıza. Enfeksiyonu tedavi etmeden ağrı kesiciyle yetinmeye benziyor. Ağrının azalması işe yarar; tedavinin yapılıp yapılmadığını ayrıca bilmemiz gerekir.

Ürün yol haritasında seçtiğimiz çözümün gerekçesi de görünmeli. Beklediğimiz sonuç, sorumlu ekip ve kararı yeniden değerlendireceğimiz koşul belli olursa, sonraki etkileyici demo bizi kolayca başka yöne çekmez.

Yapay zekâ müşteriye saniyeler içinde cevap verebilir. Ama o müşterinin bizi neden aramak zorunda kaldığını sorgulamıyorsak, sorunu çözmek yerine şikâyetleri daha verimli karşılayan bir sistem kurmuş olabiliriz. Başarı, kaç şikâyeti yapay zekâyla yanıtladığımız kadar, kaç müşterinin şikâyet etmesine gerek bırakmadığımızla da ölçülmeli.

## Yararlı okumalar

[Reforge: AI çağında ürün yöneticisinin rolü](https://www.reforge.com/blog/more-valuable-less-protected), prototip üretmek kolaylaşırken problem tanımının ve ekiplerin ortak anlayışının neden önem kazandığını tartışıyor. 31 Temmuz 2026 tarihli yazı bir etkinlik özeti ve eğitim tanıtımıyla bağlantılı; bağımsız bir verimlilik ölçümü sunmuyor. Buradaki su siparişi deneyiminin veya varsayımsal projenin kanıtı değil, ürün önceliklendirme tartışmasını genişleten bir okuma.

---

Language: Turkish
License: CC BY 4.0
License URL: https://creativecommons.org/licenses/by/4.0/
Scope: Evren Bal-authored text, unless this article expressly states otherwise.
Excluded: Third-party material, quoted excerpts, logos, and separately marked images retain their own rights.
Attribution: Credit Evren Bal, link to the canonical source and license, and indicate changes.
Source: https://evrenbal.com/tr/yapay-zeka-gerekli-mi