Durum Takip Ekranları ve İlerleme Bildirimleri: Ne Kadar, Ne Zaman

Kargosunu bekleyen bir kullanıcı gün içinde takip sayfasını beş kere açıyorsa sorun kargoda değil, ekrandadır. Durum panelleri ve ilerleme bildirimleri aynı soruyu cevaplamak için var: benim işim ne durumda, ne zaman biter. İkisini kurarken asıl mesele hangi bilgiyi göstereceğin değil, aynı bilginin iki farklı yerden farklı görünmesini nasıl engelleyeceğin.

Panel neyin yerine geçiyor

Bir takip ekranının başarısı, destek hattına düşmeyen çağrılarla ölçülür. Kullanıcı paneli açtığında aradığı tek şey vardır: sürecin bittiği ya da biteceği an. Ekran bu soruya dokunmadan sadece işleminiz devam ediyor yazıyorsa çağrıyı önlememiş, birkaç saat ertelemiş olur. Peki tahmini tarihi vermeye cesaret edemiyorsan ne yaparsın? En azından bir sonraki adımın ne olduğunu ve kimin sırasında beklediğini yaz. Evrak kontrolünde, ortalama 2 iş günü cümlesi, boş bir ilerleme çubuğundan fazlasını anlatır.

Ekran ile bildirim tek olaydan doğmalı

Klasik hata şu: panel veritabanındaki sipariş tablosunu okur, bildirimler ise gece çalışan ayrı bir görevle gönderilir. Kullanıcı saat 23.00'te kargoya verildi mesajını alır, siteye girer, ekranda hâlâ hazırlanıyor yazar. Bu noktadan sonra sistemin söylediği hiçbir şeye güvenmez.

Doğru kurgu, durum değişikliğini tek bir yerde tek bir olay olarak yazmak: kayıt düşer, panelin okuduğu görünüm de gönderilecek mesaj da o olaydan türer (aynı bilgiyi iki ayrı zamanlanmış göreve bağlayan sistem er geç kullanıcıya yalan söyler). Gecikme olacaksa da doğru yönde olsun; mesaj panelden sonra gitsin, önce değil. Kullanıcı bildirimi görüp siteye koştuğunda ekranın hazır olması gerekir.

Kaç bildirim fazladır

Kaynak metinlerin çoğu iki tavsiyeyi yan yana verir: her aşamada proaktif bilgilendir, bir yandan da bildirim fazlalığından kaçın. Bunlar birlikte uygulanamaz, çünkü gönderilen mesaj sayısı aşama sayısıyla kanal sayısının çarpımıdır. Beş aşamalı bir sipariş akışını SMS, e-posta ve mobil bildirimle desteklersen tek sipariş için 15 mesaj gider. İki ürün ayrı ayrı kargolanırsa 30.

Çıkış yolu aşama sayısını kısmak değil, kanalı tekleştirmek. Varsayılan tek kanal olsun, kullanıcı isterse ikinciyi açsın. Aynı olay için birden fazla gönderim yapılmasını da kodda engelle: olay kimliği başına tek mesaj kuralı, üç ayrı servisin aynı haberi ayrı ayrı duyurmasından çok daha ucuz bir çözüm. Bir de kullanıcının hiç ilgilenmediği ara adımlar var; depo içi transferi haber vermenin kimseye faydası yok.

İç durum ile kullanıcı durumu aynı şey değil

Arka tarafta on dört ayrı hâli olan bir süreç, kullanıcıya dört hâl olarak görünmeli. Bu bir görünüm tercihi değil, açık bir eşleme tablosu olarak yaşamalı: hangi iç kod hangi kullanıcı metnine karşılık geliyor, tek yerde yazılı olsun. Aksi hâlde ekibe yeni bir iç durum eklendiğinde panel ya boş kalır ya da kullanıcı son bilinen adımda saatlerce takılı görünür. Böyle bir eşleme yoksa, sisteme her yeni özellik takip ekranını biraz daha bozar.

Metinler de kullanıcının kelimeleriyle yazılmalı. ODEME_ONAY_BEKLIYOR değil, Ödemeniz bankadan onay bekliyor. İç süreç kodunu ekrana koyan her sistem, o kodu soran bir destek çağrısı üretir.

Kötü günü de tasarla

Takip ekranları iyi senaryoya göre tasarlanır, oysa kullanıcı en çok işler ters gittiğinde bakar. Referans numarası bulunamadığında Bilgi yanlış demek yerine nereye bakılacağını söyle: onay e-postasındaki on haneli numara, başında sipariş tarihi olmadan. Süreç uzadığında sessiz kalma; haftalık inceleme sırasında, sizden önce 40 başvuru var gibi düşük ayrıntılı bir mesaj bile kullanıcıyı destek hattından uzak tutar. Gecikme, iade ve iptal gibi hâllerin ekranda bir karşılığı yoksa kullanıcı o boşluğu telefonla doldurur.

Geçmiş kaydı ve kanallar arası tutarlılık

Her durum değişikliğini zaman damgasıyla sakla ve kullanıcıya göster. Bu, şikâyet çözümünde iki tarafın da aynı kayda bakmasını sağlar; "bana haber verilmedi" tartışması, gönderim kaydı ortadayken beş dakikada biter. Çağrı merkezindeki temsilcinin ekranı da kullanıcının gördüğü panelle aynı kaynaktan okumalı, ayrı bir yönetim arayüzünden değil.

Özetle iş, tek bir olay akışı kurmaya ve o akışı kullanıcının anlayacağı dört beş hâle indirmeye bakıyor. Bunu yapan bir sistemde bildirim sayısını azaltmak kolaydır, çünkü ekran zaten güvenilirdir; yapmayan bir sistemde ne kadar mesaj gönderirsen gönder kullanıcı yine telefonu eline alır.