Müşteri talebi yaşam döngüsü: Ekranlardan önce haritalayın

Talep haritası olmadan ekranlar neden başarısız olur

Özenle hazırlanmış bir talep formu bile karmaşık bir sürece yol açabilir. Ekipler çoğu zaman alanları, düğmeleri ve panoları önce seçer, ardından müşteri «Gönder» düğmesine bastıktan sonra ne olacağı konusunda kimsenin anlaşmadığını fark eder.

Ekranlar tek tek anları gösterir. Müşteri talebi yaşam döngüsü ise tüm yolu ortaya koyar: Talep nereye gelir, kim inceler, hangi karar verilir, çalışma ne zaman başlar ve ne zaman tamamlanmış sayılır? Bu harita olmadan her ekran kendi içinde anlamlı görünebilir, ancak ekranlar arasındaki iş akışı belirsiz kalır.

«Devam ediyor» adlı bir duruma sahip destek formunu düşünün. Bu ifade, birinin talebi okuduğu, talebi birine atadığı, müşteriyle iletişime geçtiği veya asıl işe başladığı anlamına mı gelir? Çalışanlar aynı etiketi farklı anlamlarda kullanabilir. Müşteriler çok az ilerleme görür, yöneticiler de taleplerin nerede takıldığını anlayamaz.

Ekranlarla başlamak, devirleri de görünmez kılar. Bir talep destekten faturalandırmaya, oradan da müşteri yöneticisine gidebilir. Ekip her adımda kimin sorumlu olduğunu belirlemediyse herkes işi başka birinin yapacağını düşünebilir. Bunun sonucunda talepler, müşteri tekrar iletişime geçene kadar ortak bir kuyrukta bekler.

Talep iş akışını haritalamak, arayüz tasarımı başlamadan önce bu boşlukları ortaya çıkarır. Ekibin şu sorulara yanıt vermesi gerekir:

• Talebi başlatmak için hangi bilgiler gerekir?
• Bir sonraki eylemden kim sorumludur?
• Her kararın ardından hangi durumlara geçilebilir?
• Bir son tarih ne zaman başlar, duraklar veya sona erer?
• Talep değiştiğinde kime bildirim gitmelidir?

Harita, yanıltıcı panoların oluşmasını da engeller. «Açık» taleplerin sayısı, yeni talepleri, müşteriden bilgi bekleyen talepleri ve başka bir ekip tarafından engellenen işleri aynı anda içeriyorsa pek bir şey anlatmaz. Ayrı durumlar çalışanlara ortak bir dil, müşterilere ise daha dürüst bir güncelleme sunar.

Haritanın karmaşık olması gerekmez. Eksik bilgiler, reddedilen talepler ve yeniden açılan kayıtlar dahil olmak üzere insanların gerçekten yaptığı işi anlatması yeterlidir. Yol netleştiğinde ekranları tasarlamak kolaylaşır, çünkü her sayfanın belirli bir amacı olur: Bilgi toplamak, sorumlunun harekete geçmesine yardımcı olmak veya müşteriye talebinin hangi aşamada olduğunu göstermek.

Tek bir taleple ve net bir sonuçla başlayın

Ekibinizin en sık gördüğü taleple başlayın. Bu, ücret iadesi talebi, hasarlı teslimat bildirimi veya hesap bilgilerinde değişiklik isteği olabilir. Her müşteri ihtiyacını tek bir diyagramda haritalamaya çalışmayın. Geniş haritalar kısa sürede belirsizleşir.

Başlangıç olayını günlük ve açık bir dille yazın. Örneğin: «Müşteri, destek formu üzerinden bir sipariş için ücret iadesi talebi gönderir.» Bu ifade yaşam döngüsünün ne zaman başladığını belirler. Ayrıca daha sonra ortaya çıkabilecek yaygın bir anlaşmazlığı önler: Talep müşteri gönderdiğinde mi, destek ekibi okuduğunda mı, yoksa biri kayıt oluşturduğunda mı başlar?

Ardından bitiş noktasını iki taraf açısından tanımlayın. Tamamlanmış bir ücret iadesi talebi, müşterinin net bir karar alması ve karar onaylandıysa ödeme ekibinin iadeyi gerçekleştirmesi anlamına gelir. Destek ekibinin de karar, gerekçe, tutar ve tarih bilgilerini kaydetmesi gerekir. Bu ayrıntılar, «Tamamlandı» yazan bir ekrandan daha önemlidir.

Sonucu arayüzden ayrı düşünün. «Yeşil bir başarı mesajı göster» bir ekranı anlatır. «Müşteriye iade tutarını ve ödemenin beklenen tarihini içeren bir onay gönder» ise gerçekleşmesi gereken işi anlatır. Yeniden tasarım sırasında ekran değişebilir. Müşteri web portalı, mobil uygulama veya e-posta kullansa da temel iş aynı kalmalıdır.

Kısa bir tanım, tasarım başlamadan önce eksik kuralları ortaya çıkarabilir:

• Talep türü: Ödemesi yapılmış bir sipariş için ücret iadesi
• Başlangıç: Müşteri bir form gönderir veya destek ekibiyle iletişime geçer
• Bitiş: Müşteri onay veya ret kararını alır ve ekip kararı kaydeder
• İstisna: Karar verilmeden önce destek ekibi eksik sipariş bilgilerini ister

Bir müşterinin pazartesi günü mükerrer ücretlendirme bildirdiğini varsayalım. Talep, ekip ücretlendirmenin gerçekten tekrarlandığını doğrulayıp kararı gönderdikten ve varsa iadeyi kaydettikten sonra sona ermelidir. İlk yanıttan sonra kaydı kapatmak, asıl işi tamamlanmamış bırakır.

Bu yolun başlangıcı ve bitişi kesinleştiğinde ekip, tahmin yürütmeden durumları, sorumluları, son tarihleri ve bildirimleri ekleyebilir. AppMaster daha sonra bu haritayı iş süreçlerine ve ekranlara dönüştürebilir, ancak önce yapılması gereken iş haritada tanımlanmalıdır.

Bir talebin girebileceği durumları listeleyin

Bir durum, müşteri talebinin o anda nerede olduğunu herkese anlatır. Listeyi her küçük eylemi içerecek şekilde değil, işin anlamlı aşamalarını gösterecek şekilde tutun. Çalışanlar bir durumu okuduğunda bundan sonra ne yapılması gerektiğini anlayabilmelidir.

Tipik bir destek veya hizmet talebinde şu durumlar bulunabilir:

• Yeni: Sistem talebi aldı, ancak kimse henüz incelemedi.
• İnceleniyor: Bir ekip üyesi ayrıntıları kontrol eder ve talebin nasıl ele alınacağına karar verir.
• Müşteri bekleniyor: Ekip müşteriden yanıt, dosya veya onay bekler.
• Devam ediyor: Bir kişi işi üstlenmiş ve üzerinde çalışmaktadır.
• Onay veya dış işlem bekleniyor: İlerleme bir yöneticiye, tedarikçiye, ödeme sağlayıcısına veya başka bir tarafa bağlıdır.
• Çözüldü: Ekip istenen işi tamamlamıştır.
• Kapatıldı: Müşteri sonucu kabul etmiştir veya ekip, belirlenen sürenin ardından talebi kapatmıştır.

İnsanların zaten kullandığı dile yakın adlar seçin. «Müşteri bekleniyor», «Girdi bekleniyor» ifadesinden daha açıktır. «Devam ediyor» da genellikle «Aktif» ifadesinden daha anlaşılırdır. Müşteriler portalda gördükleri durumu anlamak için kurum içi bir sözlüğe ihtiyaç duymamalıdır.

Bekleme durumlarına özellikle dikkat edin. Bu durumlar ekibinizin bugün yapabileceği işleri, başka birine bağlı işlerden ayırır. Müşterinin makbuz göndermesi gerektiğinde ücret iadesi talebi «İnceleniyor» durumundan «Müşteri bekleniyor» durumuna geçebilir. Tutarın bir finans yöneticisi tarafından onaylanması gerekiyorsa talep «Onay bekleniyor» durumuna geçer. Bu gecikmeler için farklı hatırlatıcılar ve son tarih kuralları gerekir.

Yinelenen etiketlerden kaçının. «Açık», «Atandı» ve «İşleniyor» çoğu zaman aynı genel durumu anlatır. Her bir etiket sorumluyu, çalışanların yapacağı işi veya geçerli son tarihi değiştirmiyorsa tek bir durum kullanın. Daha az sayıda ve daha net iş akışı durumu ile geçişi, raporların güvenilirliğini de artırır.

Her talep için basit bir soru sorun: Aynı anda iki durumda olabilir mi? Olabiliyorsa adlar birbiriyle örtüşüyor olabilir. Her durum tek bir açık koşulu anlatana kadar adları gözden geçirin.

Geçişleri çizin ve kimin başlattığını belirtin

Bir durum adı tek başına iş akışını açıklamaz. Talebin nasıl ilerlediğini, onu kimin ilerletebileceğini ve bunun gerçekleşmesi için hangi koşulların sağlanması gerektiğini kaydedin. Böylece bir ekran düğmesinin talebi yanlış zamanda değiştirmesi önlenir.

Her geçişi sade bir cümle olarak yazın. Örneğin: «Destek temsilcisi, müşterinin sipariş numarasını eklediğini kontrol ettikten sonra talebi Yeni durumundan İnceleniyor durumuna geçirir.» Bu cümle eylemi, yapan kişiyi ve koşulu belirtir.

Basit bir haritada şu geçişler bulunabilir:

• Müşteri talep gönderir ve sistem Yeni durumunda bir talep oluşturur.
• Destek temsilcisi talebi bir uzmana atar ve durumu İnceleniyor olarak değiştirir.
• Ayrıntılar eksikse uzman talebi Müşteri bekleniyor durumuna geçirir.
• Müşterinin yanıtı talebi yeniden İnceleniyor durumuna getirir.
• Uzman işi tamamladıktan sonra talebi Çözüldü olarak işaretler.
• Müşteri veya destek lideri, onaydan sonra talebi kapatır.

Her ok için yetkili kişiyi belirtin. «Ekip» çok belirsizdir. Müşteri, destek temsilcisi, faturalandırma uzmanı, ekip lideri veya otomasyon gibi roller kullanın. Sistem kuralı da değişikliği başlatabilir. Örneğin, politikanız buna uygunsa otomasyon, 14 gün boyunca yanıt gelmediğinde talebi Müşteri bekleniyor durumundan Kapatıldı durumuna geçirebilir.

İstisnaların da kendi geçişleri olmalıdır. Müşteri Yeni durumundaki bir talebi iptal edebilir, ancak tamamlanmış bir talebi iptal edemez. Sorun tekrar ortaya çıkarsa ekip lideri Kapatıldı durumundaki talebi yeniden açabilir. Bir temsilci, talebin yanlış kişiye atanması durumunda İnceleniyor durumunu yeniden Yeni olarak değiştirebilir. Bu kurallar talep sorumluluğunu korur ve bazı durum değişikliklerinin neden kullanılamadığını açıklar.

Ekranları tasarlamadan önce yolu kutular ve oklarla çizin. İki rolün bir talebi sürekli birbirine gönderdiği ve hiç bitmeyen döngülere bakın. Çıkmazları da kontrol edin. Talep Onay bekleniyor durumuna giriyorsa onaylayanın kim olduğunu ve onaydan veya redden sonra ne olacağını tanımlayın.

AppMaster'da bu harita daha sonra iş süreci mantığına dönüşebilir; roller de her kullanıcının hangi eylemleri göreceğini belirler. Harita, yeni bir ekip üyesinin bir talebi gönderimden kapanışa kadar takip edebileceği kadar anlaşılır olmalıdır.

Her devir için sorumlu atayın

Bir talep üzerinde aktif olarak çalışılırken her zaman adı belirli bir sorumlusu olmalıdır. Bu kişinin her görevi tek başına tamamlaması gerekmez. Ancak mevcut durumu bilmeli, talebi ilerletmeli ve biri güncelleme istediğinde yanıt verebilmelidir. Ortak sorumluluk çoğu zaman kimsenin harekete geçmemesiyle sonuçlanır.

Talep ilerledikçe sorumlu değişebilir. Yeni bir talepten destek temsilcisi, incelemeden uzman, müşteriye gönderilecek son yanıttan da müşteri yöneticisi sorumlu olabilir. Çalışanların kimin harekete geçmesi gerektiğini tahmin etmemesi için her değişikliği haritaya ekleyin.

Talebin sorumlusunu inceleyen ve onaylayan kişilerden ayrı tutun. Bir finans lideri ücret iadesini onaylayabilir, ancak talebin sorumlusu yine destek temsilcisi olabilir. Temsilci onay ister, yanıtı takip eder ve sonucu müşteriye bildirir. Finans lideri yalnızca «Onayla» düğmesine bastığı için sonraki tüm takip işlerini üstlenmemelidir.

Her devirde aktif sorumluyu ve ekibi, sorumluluk değişikliğini başlatan olayı, bir sonraki geçişten önce yapılması gereken işi ve sorumlu müsait değilse görevi devralacak kişiyi kaydedin.

Gecikme yaşanmadan önce izin ve yoklukları planlayın. Bir ekip kuyruğu, belirlenmiş bir yedek kişi veya talepleri belirli bir süreden sonra yeniden atayan bir kural kullanın. Bir uzman izinliyse başka bir kişi talebi kendi kuyruğunda görmelidir. Talep yanıt veremeyen bir sorumluya bağlı olarak beklememelidir.

Uygulamada sorumluluğu görünür kılın. Özel sohbetler ve e-posta zincirleri çalışmayı destekleyebilir, ancak iş akışını tanımlamamalıdır. Her talep kaydı mevcut sorumluyu, önceki devri, atama zamanını ve yeniden atama nedenini göstermelidir. Yöneticiler çok uzun süre bekleyen talepleri fark edebilir, müşteriye dönük çalışanlar da mesajlar arasında arama yapmadan güncelleme verebilir.

Örneğin bir müşteri faturalandırma hatası bildirdiğinde, finansın incelemesi gerektiğini doğrulayana kadar talebin sorumlusu destek temsilcisidir. Ardından finans analisti incelemeden sorumlu olur. Finans kararı kaydettiğinde sorumluluk, müşteriye yanıt vermesi ve talebi kapatması için desteğe döner. Böylece iki kişinin farklı yanıtlar göndermesi veya ikisinin de diğerinin yanıt verdiğini sanması önlenir.

Bir uygulamada iş akışını oluştururken sorumlu değişikliklerini durum geçişinin parçası yapın. AppMaster, durum değişikliğini, atama kuralını ve denetim kaydını tek bir iş sürecinde birleştirebilir. Bu yaklaşım ekip büyüdükçe sorumluluğun net kalmasına yardımcı olur.

İşe uygun son tarihler belirleyin

Bir talebin çoğu zaman iki son tarihe ihtiyacı vardır. Yanıt son tarihi, bir destek temsilcisinin talebi okuduğunu ve daha fazla bilgiye ihtiyaç duyduğunu bildirmek gibi ilk anlamlı yanıtı kapsar. Tamamlama son tarihi ise ekibin talebi çözdüğü veya üzerinde anlaşılan sonucu sunduğu anı kapsar.

Bu tarihleri ayrı tutmak yaygın bir sorunu önler: Müşteri hızlı bir alındı onayı alır, ancak talep günlerce işleme alınmadan kalır. Bir erişim talebi dört iş saati içinde yanıtlanmayı ve iki iş günü içinde tamamlanmayı gerektirebilir. Karmaşık bir faturalandırma anlaşmazlığı için yanıt süresi bir iş günü, tamamlama süresi ise daha uzun olabilir.

Her saatin tam olarak ne zaman başladığını yazın. Birçok ekip yanıt süresini sistem talebi aldığı anda başlatır. Tamamlama süresi aynı anda başlayabilir veya ancak ekip çalışmak için yeterli bilgiye ulaştığında başlayabilir. Tek bir kural seçin ve bunu tutarlı biçimde uygulayın.

Duraklamaları da aynı özenle tanımlayın. Talep müşterinin yanıtını, onaylı bir üçüncü tarafı veya planlı bir bakım aralığını beklerken süre durabilir. Eksik bilgi geldiğinde veya engel ortadan kalktığında süre yeniden başlamalıdır. Atanan kişi meşgul ya da izinli olduğu için son tarihi durdurmayın. Sorumlu veya yönetici işi başka birine devretmelidir.

Son tarih yaklaşmadan önce eskalasyon ekleyin. İzin verilen sürenin yüzde 75'inde sorumluya gönderilen bir hatırlatıcı, harekete geçmek için zaman bırakır. Yüzde 90'da yöneticiyi veya bir sonraki sorumlu ekibi bilgilendirin. Son tarih aşılırsa talebi gecikmiş olarak işaretleyin ve sonraki adımı belirtin.

Basit bir politika şöyle işleyebilir:

• Yanıt süresi müşteri talebi gönderdiğinde başlar.
• Ekip belirli bir soru sorduktan ve talep Müşteri bekleniyor durumuna girdikten sonra tamamlama süresi durur.
• Müşteri yanıt verdiğinde süre yeniden başlar ve talep mevcut sorumlusuna döner.
• Son tarih yaklaşırken sorumluya bir hatırlatıcı, ardından yöneticiye bir eskalasyon gönderilir.
• Gecikmiş talep için yönetici bir telafi planı belirler ve müşteriyi bilgilendirir.

Herkes bu sürecin arkasındaki programı kabul ediyorsa iş saatlerini kullanın. Haftanın yedi günü yardım sözü veren bir ekip, her akşam süreyi sessizce durdurmamalıdır. Destek pazartesiden cumaya çalışıyorsa iş akışı kurallarında çalışma saatlerini, tatilleri ve saat dilimini tanımlayın. Net kurallar, son tarih bildirimlerini müşteriler ve çalışanlar için adil hale getirir.

Gürültü oluşturmadan bildirimleri planlayın

Bildirimler tek bir pratik soruya yanıt vermelidir: Birinin bunu şimdi bilmesi veya bir şey yapması gerekiyor mu? Gerekmiyorsa güncellemeyi talep kaydında tutun. Gürültülü bir gelen kutusu, çalışanlara ve müşterilere önemli mesajları da görmezden gelmeyi öğretir.

Talep onları etkileyen bir şekilde değiştiğinde müşterilere mesaj gönderin. Yaygın anlar şunlardır: Talebin alındığını onaylamak, daha fazla bilgi istemek, talebi onaylamak veya reddetmek, vaat edilen tamamlama tarihini değiştirmek ve işi tamamlamak. Bir çalışan yazım hatasını düzelttiğinde, kurum içi not eklediğinde veya beklenen sonucu değiştirmeden görevi başka birine atadığında müşteriye bildirim göndermeyin.

Kurum içi uyarıların da bir sorumlusu ve harekete geçme nedeni olmalıdır. Talep «İnceleme gerekiyor» durumuna geçtiğinde inceleyene bildirim gönderin. Müşteri bir soruya yanıt verdiğinde takipten sorumlu kişiyi bilgilendirin. Bu olayların ikisi için de tüm ekibin uyarı almasına gerek yoktur.

Mesajları sade ve net tutun. Talebi adlandırın, mevcut durumu belirtin ve bundan sonra ne olacağını açıklayın. Örneğin:

• Müşteri: «Ekipman talebiniz #1842 numarasıyla alındı. Salı gününe kadar inceleyeceğiz.»
• İnceleyen: «#1842 numaralı talep için salı günü saat 15.00'e kadar onayınız gerekiyor.»
• Müşteri: «#1842 numaralı talebiniz onaylandı. Ekibimiz teslimatı planlayacak ve cuma gününe kadar sizi bilgilendirecek.»

Zamanlama, metin kadar önemlidir. Son tarih hatırlatıcısı, sorumlu kişiye harekete geçebileceği kadar erken ulaşmalıdır, son tarihten beş dakika önce değil. İki günlük bir inceleme aralığı için genellikle son günün öncesinde bir hatırlatıcı ve süre geçtikten sonra bir hatırlatıcı yeterlidir. Sorumlu işi tamamladığında uygulama bekleyen hatırlatıcıları durdurmalıdır.

Bildirim kurallarını haritada her geçişin yanına kaydedin. Mesajı kimin alacağını, hangi olayın mesajı başlatacağını, hangi kanalın kullanılacağını ve uygulamanın bir hatırlatıcıya ihtiyaç duyup duymadığını belirtin. Böylece bir ekran oluşturulmadan veya otomasyon yazılmadan önce davranış netleşir.

Basit bir müşteri talebini baştan sona izleyin

Bir müşteri destek formu üzerinden mükerrer ücretlendirme bildirir. Form, #4821 numaralı talebi Yeni durumunda oluşturur ve destek kuyruğuna atar. Müşteri, talep numarasını ve ekibin konuyu bir iş günü içinde inceleyeceğini belirten anında bir onay alır.

Bir destek temsilcisi talebi açar, sipariş ve ödeme kaydını kontrol eder, ardından durumu İnceleniyor olarak değiştirir. Talebin sorumlusu bu temsilcidir. Ödeme kayıtlarında yeterli ayrıntı yoksa temsilci Müşteri bekleniyor seçeneğini belirler ve banka ekstresinin ekran görüntüsünü veya kartın son dört hanesini ister.

Bu durum için bir son tarih gerekir. Uygulama üç gün sonra müşteriye hatırlatma gönderebilir ve yanıt gelmezse yedi gün sonra talebi kapatabilir. Müşteri eksik bilgileri eklediğinde temsilciye bildirim gitmelidir. Böylece talep kuyrukta fark edilmeden kalmaz.

Müşteri yanıt verdiğinde talep yeniden İnceleniyor durumuna döner ve mümkünse aynı temsilciye atanır. Süreklilik önemlidir, çünkü yeni bir temsilcinin aynı soruları tekrar sorması gerekmez.

Temsilci mükerrer ücretlendirmeyi doğrularsa talebi «İade kararı» durumuna geçirir ve bir finans inceleyicisine atar. Finansın iade talebini onaylamak veya reddetmek için iki iş günü vardır. Son tarihten bir gün önce gönderilen hatırlatıcı, müşterinin güncelleme istemesine gerek kalmadan inceleyene harekete geçme zamanı verir.

Finans inceleyicisi kararı kaydeder. Onaylanan talep, ödeme ekibinin iadeyi gerçekleştirdiği ve referans numarasını girdiği «İade işlemi» durumuna geçer. Reddedilen talep, temsilcinin müşteriye açıkça aktarabileceği gerekçeyle desteğe döner.

Destek, son mesajı ancak ekip iadeyi gerçekleştirdikten veya ret gerekçesini açıkladıktan sonra gönderir. Ardından temsilci durumu Kapatıldı olarak değiştirir. Müşteri sonuçla birlikte kapanış bildirimini alır; ekip ise her sorumluyu, kararı, son tarihi ve mesajı kaydeder.

Bu harita yaygın bir boşluğu önler: Bir ekranda tamamlanmış görünen, ancak başka bir ekibin kuyruğunda hâlâ işlem bekleyen talep.

İş akışını karıştıran yaygın hatalar

Çoğu talep iş akışı, etiketler onları tasarlayan kişilere açık geldiği, ancak her gün kullanan kişilere açık olmadığı için karmaşıklaşır. «Beklemede» adlı bir durum müşterinin yanıt vermediği, yöneticinin işi onaylaması gerektiği veya teknisyenin parça beklediği anlamına gelebilir. Bu durumların her biri farklı bir sonraki adım gerektirir.

Belirsiz etiketleri bekleme nedenini açıklayan durumlarla değiştirin. «Müşteri ayrıntıları bekleniyor» talep sahibine ne yapması gerektiğini söyler. «Yönetici onayı bekleniyor» ise ilerlemeyi neyin engellediğini yöneticiye gösterir. Ekip bir sonraki adımın kimde olduğunu söyleyemiyorsa durumu yeniden adlandırın veya kaldırın.

Sorumluluk da sık karşılaşılan bir sorundur. Bir talep destek, finans ve operasyon ekiplerini ilgilendirebilir, ancak birkaç kişinin adını yazmak ortak sorumluluk oluşturmaz. Her aktif durum için tek bir sorumlu belirleyin. Bu kişi başkalarından görüş alabilir, ancak talebi ilerletmekten veya gecikmeyi açıklamaktan sorumlu kalır.

Bir son tarihe mutlaka bir eylem bağlayın. Yalnızca hatırlatıcı gönderen bir son tarih, kimse yanıt vermediğinde pek işe yaramaz. Süre dolduğunda ne olacağını belirleyin: Sorumluyu uyarın, yöneticiye eskale edin veya talebi inceleme kuyruğuna taşıyın. Eylemi gecikmenin etkisine göre seçin.

Bir durum yararlı görünüyor diye ekran oluşturmayın. Her ekran net bir görevi, kararı veya devri desteklemelidir. «Kalite incelemesi» ekranı, biri belirli ölçütleri kontrol edip talebi onaylıyor veya gerekçeyle geri gönderiyorsa anlamlıdır. Ekip bu eylemi açıkça anlatamıyorsa belirsizliği başka bir sayfanın arkasına saklamak yerine durumu kaldırın.

Ekranları tasarlamadan önce yaşam döngüsünün her bölümünü şu dört soruyla test edin:

• Bu durum tam olarak ne anlama geliyor?
• Talep bu durumdayken sorumlusu kim?
• Talebi bir sonraki duruma hangi olay geçiriyor?
• Son tarih aşılırsa ne oluyor?

Bu kontrol boşlukları erken ortaya çıkarır. Ayrıca talep iş akışını bir uygulamaya dönüştürmeyi kolaylaştırır, çünkü her durumun bir amacı, sorumlusu ve belirlenmiş bir eylemi olur.

Ekran tasarımından önce hızlı bir kontrol yapın

Bir talep haritası, herhangi biri bir UI builder açmadan önce basit bir incelemeden geçebilmelidir. Haritayı yoğun bir salı günü gerçek bir taleple ilgilenen bir çalışanmış gibi okuyun. Bundan sonra ne olacağını anlayamıyorsanız bir ekran bu boşluğu kapatamaz.

Her duruma açık bir görev ve en az bir çıkış yolu verin. «Müşteri bekleniyor», ekibin bilgiye ihtiyaç duyduğu anlamına gelir. Bu nedenle müşteri yanıt verdiğinde, talebi iptal ettiğinde veya belirlenen yanıt tarihini kaçırdığında farklı bir geçiş olmalıdır. Ekip orada tam olarak hangi işi yaptığını bilmiyorsa «Devam ediyor» gibi yalnızca genel bir durumu anlatan durumlardan kaçının.

Her geçişi, neyin başlattığını ve kimin kullanabileceğini sorarak inceleyin. Destek temsilcisi yanıt gönderdikten sonra talebi çözüldü olarak işaretleyebilir. Müşteri talebi yeniden açabilir. Sistem kuralı, 14 gün boyunca yanıt gelmediğinde talebi kapatabilir. Kişilerin talepleri yanlışlıkla değiştirmemesi için bu izinleri yazılı hale getirin.

Şu kontrol listesini kullanın:

• Her durumun bir amacı, çıkış yolu ve mantıklı bir sonraki durumu vardır.
• Her geçişte onu başlatan olay ve buna izin verilen kişi veya kural belirtilmiştir.
• Her açık talebin tek bir sorumlusu ve bir son tarihi veya yanıt süresi vardır.
• Her müşteri güncellemesi, müşteriyi etkileyen bir durum değişikliğinde gerçekleşir.
• Her gecikme yolu, kimin uyarılacağını ve ne yapması gerektiğini belirtir.

Devirlerde sorumluluğu kontrol edin, çünkü karışıklık çoğu zaman burada başlar. Bir destek temsilcisi teknik bir sorunu mühendisliğe gönderiyorsa talebe yeni bir sorumlu atanmalıdır. İlk temsilci izleyici olarak kalabilir, ancak iki kişi de diğerinin yanıt vereceğini düşünmemelidir.

Son tarih bildirimlerini pratik tutun. Son tarihten önce kurum içi bir hatırlatıcı gönderin, ardından yalnızca talep açık kalırsa eskale edin. Müşterilere girdilerine ihtiyaç duyduğunuzda, talep başka bir ekibe geçtiğinde ve ekip talebi çözdüğünde veya kapattığında bilgi verin. Her kurum içi not için müşteriyi uyarmayın.

Harita kâğıt üzerinde net göründüğünde ekranların da açık bir görevi olur: Doğru durumu, eylemleri, sorumluyu ve son tarihi doğru kişiye göstermek.

Haritayı bir uygulamaya dönüştürün

Müşteri talebi yaşam döngüsü netleştiğinde haritanın her parçasının uygulamada doğrudan bir karşılığı olur. Durumlar bir durum alanına, sorumlular atanmış kullanıcılara veya ekiplere, son tarihler tarih ve saat alanlarına dönüşür. Geçişler de «Ata», «Ayrıntıları iste», «Çöz» ve «Yeniden aç» gibi eylemlere dönüşür.

İlk sürümü sade tutun. Bir talep ekranında genellikle müşteri, talep türü, açıklama, mevcut durum, atanmış sorumlu, son tarih, etkinlik geçmişi ve dosyalar bulunmalıdır. Ayrı bir kuyruk, her kişinin ilgilenmesi gereken talepleri göstermelidir.

İş akışı yalnızca bir etiketi göstermekle kalmamalı, eylemleri de kontrol etmelidir. Destek temsilcisi talebi Yeni durumundan İnceleniyor durumuna geçirebilir. Yalnızca atanmış çözüm sorumlusu talebi Çözüldü olarak işaretleyebilir. Müşteri çözümden sonra yanıt verirse uygulama talebi yeniden açıp uygun kuyruğa döndürebilir.

Her ekranı oluşturmadan önce çalışan bir taslağı gerçek talepleri alan ve çözen kişilerle test edin. Onlardan sıradan bir talebi, acil bir talebi ve eksik bilgileri olan bir talebi tamamlamalarını isteyin. Eylemi bulamadıkları, talebin sorumlusunu bilmedikleri veya bir soru sormak için uygulamadan çıkmaları gereken anları gözlemleyin.

Bu geri bildirimleri ekranın yanı sıra haritayı düzeltmek için de kullanın. İki ekibin kafasını karıştıran bir devir için «Onay bekleniyor» gibi bir durum gerekebilir. Çok uzun süre bekleyen bir talep için daha net bir son tarih veya sorumluya gönderilecek bir hatırlatıcı gerekebilir. Her küçük etkinliği anlatmak için yeni durumlar eklemeyin. Çok fazla seçenek iş akışını takip etmeyi zorlaştırır.

AppMaster, bu tasarımı no-code bir talep uygulamasına dönüştürebilir. Data Designer; talepleri, kullanıcıları, ekipleri, son tarihleri ve durum geçmişini modelleyebilir. Business Process Editor; atamaları, durum değişikliklerini, hatırlatıcıları ve eskalasyonları tanımlayabilir. Web veya yerel mobil ekranlar da talep kuyruklarını, ayrıntı görünümlerini ve yönetici raporlarını destekleyebilir.

Tek bir talep türü ve küçük bir kullanıcı grubuyla başlayın. Bu kişiler geçici çözümlere başvurmadan talep oluşturabildiğinde, atayabildiğinde, güncelleyebildiğinde ve kapatabildiğinde sıradaki talep türünü ekleyin. Böylece yalnızca güzel görünen, ancak insanların ne yapacağını bilemediği ekranlar yerine yoğun bir iş günündeki gerçek çalışmayı destekleyen bir uygulama elde edersiniz.