Müşteriye self servis deneyimi sunmak isteyen şirketlerin ilk sorusu genelde aynıdır: Web tabanlı bir müşteri portalı yeterli mi, yoksa özel bir müşteri mobil uygulaması mı geliştirmek gerekir? Bunun tek bir doğru cevabı yok. Karar; işlem sıklığına, bağlama, cihaz kullanım alışkanlığına, güvenlik gereksinimine ve arka plandaki entegrasyon yapısına bağlıdır.

Portal, çoğu iş için güçlü bir başlangıçtır. Tarayıcıdan erişilir, dağıtımı kolaydır, ilk sürüm maliyeti daha kontrollü ilerler. Mobil uygulama ise farklı bir noktada öne çıkar: Tekrarlayan işlemler, anlık bildirim ihtiyacı, cihaz özelliklerinden yararlanma ve düşük sürtünmeli kullanım. Özellikle müşterinin ayda 1 kez değil, haftada birkaç kez hatta günde birden fazla kez işlem yaptığı senaryolarda uygulama ciddi avantaj sağlar.

Bu yazıda, müşteri portalı ile mobil uygulama arasındaki seçimi teknik ve deneyim odaklı açıdan ele alacağız. Ardından self servis işlem deneyiminin nasıl tasarlanması gerektiğini, gerçek iş akışları üzerinden somutlaştıracağız.

Müşteri portalı yerine mobil uygulama ne zaman daha mantıklıdır?

En pratik karar ölçütü kullanım sıklığıdır. Bir kullanıcı yılda 2-3 kez giriş yapıp yalnızca fatura indiriyorsa portal çoğu zaman yeterlidir. Aynı kullanıcı ayda 4 kez sipariş durumu kontrol ediyor, destek talebi açıyor, tekrar sipariş veriyor ya da saha ekibiyle anlık bilgi paylaşıyorsa mobil uygulama daha doğru bir kanal hâline gelir.

Burada tek ölçüt frekans değildir. İşlemin yapıldığı bağlam da kritiktir. Masa başında, geniş ekran gerektiren, çok alanlı formların doldurulduğu süreçler portal için daha uygundur. Hareket hâlinde tamamlanan, 30 saniye ile 2 dakika arasında bitmesi beklenen işlemler ise mobilde daha iyi performans verir. Örneğin kargo teslim onayı, servis randevusunu yeniden planlama, QR ile garanti sorgulama, bakiye yükleme veya teklif onaylama.

Şu senaryo açıklayıcıdır: Bir teknik servis şirketi, müşterilerine web portalı sunar. Portalda servis kaydı açılır, fatura görüntülenir, cihaz durumu takip edilir. İlk 6 ayın ardından analizlerde, kullanıcıların önemli bir bölümünün yalnızca "servis nerede", "teknisyen ne zaman gelecek" ve "randevumu değiştir" gibi üç ekrana yoğunlaştığı görülür. Bu tip yüksek frekanslı ve zaman duyarlı aksiyonlar için mobil uygulama, portalın aynısını küçültmekten çok daha verimli bir çözümdür.

Mobil uygulamanın belirgin üstün olduğu durumlar

  • Anlık bildirim gerekiyorsa: Push notification, e-posta ve SMS'e kıyasla daha görünür bir kanal sunar. Özellikle teslimat, onay, gecikme, tahsilat ve randevu güncellemelerinde.
  • Cihaz özellikleri sürecin parçasıysa: Kamera ile belge okuma, biyometrik giriş, konum doğrulama, QR okutma, NFC veya imza yakalama gibi ihtiyaçlarda.
  • İşlem süresi kısa tutulacaksa: 4-5 adımı geçen akışlar mobilde dikkat ister. İyi tasarlanmış bir uygulama, kayıtlı veri ve kişiselleştirilmiş kısayollarla bu süreyi düşürür.
  • Tekrarlayan işlem örüntüsü varsa: Yeniden sipariş, abonelik yönetimi, kredi limiti takibi, servis talebi tekrarı gibi düzenli aksiyonlarda.

Öte yandan her mobil ihtiyaç native uygulama anlamına gelmez. Bazı projelerde iyi tasarlanmış bir responsive portal veya PWA yeterli olabilir. Karar, teknik modaya göre değil, kullanım verisine göre verilmelidir.

Portalın güçlü kaldığı alanlar: Her şeyi uygulamaya taşımak doğru değil

Mobil uygulama güçlüdür; ama her iş akışını içine almak zorunda değildir. Özellikle 10'dan fazla veri alanı içeren karmaşık başvuru formları, detaylı rapor ekranları, çoklu dosya karşılaştırmaları veya yetki matrisi yönetimi gibi işlemler portal tarafında daha verimli kalır.

B2B yapılarda bu ayrım daha net hissedilir. Satın almacı bir kullanıcı telefondan hızlı onay vermek isteyebilir; fakat 200 satırlık sipariş detayını, fiyat farklarını ve teslim planını çoğu zaman masaüstünde inceler. Burada doğru yaklaşım kanal ayrımı yapmaktır. Mobil uygulama aksiyon odaklı olur. Portal ise analiz, yönetim ve detay ekranlarını taşır.

Başarılı projelerde sık görülen model şudur: İlk fazda portal kurulur, kullanıcı davranışı ölçülür, ardından en çok kullanılan 5-7 işlem mobil uygulamaya özel olarak yeniden tasarlanır. Bu yaklaşım hem geliştirme riskini düşürür hem de gereksiz ekran üretimini engeller.

Self servis işlem deneyimi nasıl tasarlanır?

Self servis deneyim, müşterinin destek ekibine ihtiyaç duymadan bir işi güvenle tamamlayabilmesidir. Buradaki ana metrik ekran sayısı değil, tamamlanma oranıdır. Bir akış 3 ekrandan oluşabilir ama anlaşılmazsa başarısız olur. Başka bir akış 6 ekran sürer; adımlar nettir, veri otomatik gelir, kullanıcı hata yapmaz. İşte o akış daha iyidir.

İlk tasarım prensibi, müşteri niyetini ekrana çevirmektir. Kullanıcı "profil düzenle" demek istemez; "teslimat adresimi değiştir" demek ister. "Destek talebi" demek istemez; "arıza kaydı aç" ister. Menü dili, iç organizasyona göre değil, müşteri hedeflerine göre kurulmalıdır.

İyi bir self servis akışın omurgası

  • Tek amaçlı ekranlar: Her ekranda tek bir ana görev olmalı. Örneğin sadece randevu tarihi seçme.
  • Önceden dolu veri: Ad, adres, son sipariş, kayıtlı araç, cihaz seri numarası gibi alanlar yeniden yazdırılmamalı.
  • Durum görünürlüğü: "Talebiniz alındı - inceleniyor - ekip atandı - tamamlandı" gibi net süreç adımları.
  • Geri dönülebilir işlem: Özellikle randevu, sipariş, ödeme ve abonelik yönetiminde iptal/değişiklik yolu görünür olmalı.
  • Hata önleme: Hata mesajı yalnızca kırmızı metinden ibaret değildir. Tarih seçilemeyen günü en baştan pasif göstermek daha etkilidir.

Somut bir örnek verelim. Sigorta yenileme akışında kullanıcıdan poliçe numarası, T.C. kimlik numarası, araç plakası ve iletişim bilgisi ayrı ayrı isteniyorsa mobil deneyim ağırlaşır. Oysa giriş yapan kullanıcı için poliçe ve plaka sistem tarafından zaten bilinir. Kullanıcı yalnızca teklifleri görür, 1-2 seçim yapar, ödeme adımına geçer. Akış süresi birkaç dakikadan 45-60 saniye bandına inebilir. Kesin süre projeye göre değişir, fakat tasarım mantığı değişmez: Gereksiz veri girişini kaldır.

Müşteri mobil uygulaması için temel UX kararları

Mobilde ekran küçük, dikkat sınırlı, bağlantı kalitesi değişkendir. Tasarımın bu gerçeklere göre kurulması gerekir. Masaüstündeki portal menüsünü alt alta dizmek, mobil uygulama tasarımı değildir.

Navigasyon ve ana ekran kurgusu

Ana ekranda 4 ila 6 ana işlem, çoğu senaryoda yeterlidir. Fazlası keşfedilebilirliği düşürür. Kalan öğeler "Tümü" veya görev bazlı kısa yollar altında gruplanabilir. Eğer kullanıcıların büyük bölümü aynı iki işlemi yapıyorsa, bu aksiyonlar ekranın üst bölümünde sabit konumda olmalıdır. Örneğin "Tekrar Sipariş Ver" ve "Siparişimi Takip Et".

Kimlik doğrulama ve güven

Mobil uygulama hız sağlar; ama güvenlikten taviz vermez. Biyometrik giriş, cihaz eşleştirme, tek kullanımlık doğrulama kodu ve riskli işlemlerde ek onay katmanı birlikte düşünülmelidir. Örneğin profil görüntüleme ile banka hesabı değiştirme aynı güvenlik düzeyinde olmamalı. Kritik işlemlerde son 90 saniye içinde yeniden doğrulama istenmesi yerinde olabilir.

Offline ve zayıf bağlantı davranışı

Türkiye'de saha, lojistik, servis ve dağıtım senaryolarında bağlantı kalitesi sabit değildir. Bu nedenle uygulama, internet kesildiğinde tamamen işlevsiz görünmemeli. Son görüntülenen siparişlerin yerel önbellekte tutulması, yüklenen formun kaybolmaması, yeniden deneme mekanizmasının görünür olması önemlidir. Basit bir "Bağlantı hatası" ekranı çoğu durumda yetersiz kalır.

Teknik mimari: Portal ve uygulama aynı arka uca dayanmalı

Kurumsal projelerde en sık yapılan hatalardan biri, mobil uygulamayı arka planda ayrı bir dünya gibi kurgulamaktır. Oysa sürdürülebilir yapı; portal, mobil uygulama, çağrı merkezi ekranı ve hatta bayi panelinin aynı iş servislerinden beslenmesidir. Bunu sağlamak için API-first yaklaşım kritik rol oynar.

Örneğin sipariş durumu, ödeme geçmişi, adres yönetimi ve destek kayıtları için REST veya GraphQL tabanlı servis katmanı kurulabilir. Yetkilendirme tarafında OAuth 2.0 / OpenID Connect benzeri standartlar tercih edilir. Olay bazlı bildirimlerde webhook ya da mesaj kuyruğu altyapısı devreye girer. Böylece tek bir iş kuralı hem portala hem uygulamaya tutarlı biçimde yansır.

Basit bir örnek uç nokta yapısı şöyle olabilir:

GET /api/v1/customers/me/orders
GET /api/v1/customers/me/tickets
POST /api/v1/customers/me/appointments
PATCH /api/v1/customers/me/profile

Bu yaklaşımın faydası yalnızca geliştirme hızı değildir. Loglama, performans izleme, oran sınırlama ve versiyonlama da daha yönetilebilir hâle gelir. Yeni bir kanal eklendiğinde sıfırdan iş mantığı yazmak gerekmez.

Doğru kararı vermek için hangi veriler izlenmeli?

"Müşteriler mobil istiyor" ifadesi tek başına bir karar kriteri değildir. Seçim, ölçülebilir sinyallere dayanmalı. İlk bakılacak veriler şunlardır: aktif kullanıcı başına aylık işlem sayısı, en sık kullanılan 10 görev, görev tamamlama süresi, yarıda bırakma oranı, mobil web trafik payı ve destek merkezine gelen tekrar eden talepler.

Pratik bir eşik yaklaşımı kullanılabilir. Eğer belirli bir işlem kullanıcıların büyük kısmı tarafından ayda en az 2 kez yapılıyor, çağrı merkezi bu işlem için yoğun yük alıyor ve işlem mobil webde yüksek terk oranı üretiyorsa uygulama yatırımı güçlü bir adaydır. Tersi durumda portal optimizasyonu daha doğru olabilir.

Ayrıca platform kararı da verilmelidir. iOS ve Android native mi geliştirilecek, yoksa çapraz platform mu seçilecek? Burada cihaz entegrasyonu seviyesi, performans beklentisi, ekip yetkinliği ve bakım planı belirleyicidir. Örneğin yoğun kamera, Bluetooth, NFC veya arka plan işlemi kullanan senaryolarda native yaklaşım daha güvenli olabilir.

Yaygın hata: Portalı küçültüp uygulama sanmak

En maliyetli UX hatalarından biri budur. Portalda bulunan 20 menüyü aynen mobil uygulamaya taşımak, kullanıcıya seçenek sunmak değil, yük bindirmektir. Mobil uygulama farklı bir ürün gibi ele alınmalıdır. Başarılı ekipler önce görevleri sıralar, ardından gerçekten mobil bağlama uygun olanları seçer.

İyi bir ilk sürüm çoğu zaman sınırlıdır. Mesela yalnızca 6 temel işlem içerir: giriş, profil doğrulama, sipariş takibi, destek talebi, randevu yönetimi, bildirim merkezi. Sonraki sürümler kullanıcı verisine göre genişler. Bu yöntem hem geliştirme süresini kontrol altında tutar hem de ürünün gerçek değerini erken göstermeyi sağlar.

Özetle seçim, portal mı uygulama mı sorusundan biraz daha büyüktür. Asıl soru şudur: Müşteri hangi işi, hangi bağlamda, kaç saniyede tamamlamak istiyor? Eğer cevap sık tekrar eden, anlık, cihaz destekli ve kısa akışlı işlemleri işaret ediyorsa müşteri mobil uygulaması güçlü bir yatırımdır. Daha detaylı, belge yoğun ve masaüstü odaklı süreçlerde ise portal ana kanal olarak kalmalıdır. En verimli model ise çoğu zaman ikisinin birlikte, ortak API ve net rol paylaşımıyla çalıştığı yapıdır.