İstisna yolu tasarımı, yeniden çalışmanın tüm süreci yavaşlatmasından önce reddedilen talepleri, eksik belgeleri ve kısmi onayları yönetmeye yardımcı olur.
Çoğu ekip işi temiz versiyonuyla başlar. Bir talep gelir, biri inceler ve onaylanır. Bu verimli hissettirir, ama gerçek işin nerede olduğunu gizler.
Mutlu yol genellikle en kısa yoldur. Form eksiksizdir, ekler vardır ve inceleyen kişi tam olarak ne yapacağını bilir. Gerçek operasyonlarda gecikmeye sebep olan nadiren bu kısımdır.
Gecikmeler bir şey eksik olduğunda, belirsiz olduğunda, geç geldiğinde veya yalnızca kısmen kabul edildiğinde başlar. Bir yönetici bütçeyi onaylayabilir ama bir kalemi reddedebilir. Finans, hiç yüklenmemiş bir vergi belgesine ihtiyaç duyabilir. Destek lideri neden alanı çok belirsiz olduğu için isteği geri gönderebilir. Bu anların her biri ekstra adımlar, ekstra mesajlar ve daha fazla bekleme oluşturur.
Bu durumlar erken planlanmazsa, insanlar anlık kararlar verir. Bir inceleyen e-posta gönderir. Başkası araç içinde bir yorum bırakır. Üçüncüsü hiçbir açıklama yapmadan isteği reddeder. Talep sahibi ne yapacağını bilemez: hatayı düzeltmeli mi, yeniden mi başlamalı, yoksa birinden yardım mı istemeli?
Bu belirsizliğin bir maliyeti vardır. Talebi gönderen kişiyi, inceleyeni ve olanı açıklamak için çağrılan herkesi yavaşlatır. Beyaz tahtada basit görünen bir iş akışı, takip sohbetlerine, yinelenen gönderimlere ve manuel devredişlere dönüşür.
Basit bir onay akışı çizmek kolaydır:
Gerçek versiyon daha zordur. Bir belge eksikse ne olur? Talebin yalnızca bir kısmı onaylanırsa ne olur? İnceleyen reddeder ama kullanıcı düzeltebiliyorsa ne olur? Bunlar sıradışı durumlar değildir. Birçok ekip için bunlar normal vakalardır.
İşte bu yüzden istisna yolu tasarımı ekranlar çizilmeden ve durumlar adlandırılmadan önce dikkat gerektirir. İstisna yolu, gerçeklik planı böldüğünde ne olacağını tanımlar ve gerçeklik bunu sık sık yapar.
Eğer dahili bir onay uygulaması inşa ediyorsanız, AppMaster gibi bir no-code platformunda bile, reddedilen ve eksik vakalar onaylanan vaka kadar özen gerektirir. Bu vakalar insanların gördüğü mesajları, atabilecekleri eylemleri ve iş akışının insanları kurtarıp kurtarmadığını belirler.
Mutlu yol niyeti gösterir. İstisna yolları ise sürecin gerçek kullanıma dayanıp dayanamayacağını gösterir.
İstisna yolu, bir talep normal şekilde ilerleyemediğinde olan şeydir. Bu nadir bir uç durum değildir. Bir isteğin gerçek dünya karmaşasıyla başa çıkmasını sağlayan kısımdır: bir talep reddedilir, form eksiktir, bir parça onaylanır ama diğer kısmı onaylanmaz veya iş takılır.
Açık bir istisna yolu düz ve anlaşılır bir dil kullanır. "Failed" gibi muğlak bir durum yerine ne olduğunu söyleyin: "Bütçe limitinin üstünde olduğu için reddedildi" veya "Kimlik belgesi bekleniyor." İnsanlar neyin yanlış olduğunu, kimin harekete geçmesi gerektiğini ve sonraki adımda ne olacağını bilmelidir.
Çoğu iş akışı birkaç öngörülebilir şekilde bozulur:
Eksik bilgi en yaygın problemlerdendir. Bir tedarikçi kaydı formunda vergi belgesi ve banka hesap numarası gerekiyorsa, bunlardan biri eksikse sistem sadece durmamalıdır. İsteği eksik olarak işaretlemeli, tam olarak neyin eksik olduğunu göstermeli ve doğru kişiye geri göndermelidir.
Kısmi onaylar da aynı derecede önemlidir. Uçuş, otel ve yemek bütçesi içeren bir seyahat talebini düşünün. Yönetici uçuşu ve oteli onaylarken yemek bütçesini kısar. Sürecin şimdi kurallara ihtiyacı vardır. Çalışan değişikliği kabul eder mi, isteği günceller mi yoksa seyahati iptal mi eder? Bunlar erken kararlaştırılmadığında sorun oluşturur.
Takılmalar da önem taşır. Atanmış inceleyen şirketten ayrıldığı, ekip yedek onaycı ayarlamadığı veya süreç bir sonraki sahibi olmayan bir adıma ulaştığı için bir talep el değmeden bekleyebilir. Teknik olarak bir şey bozulmamış olabilir, ama talep yine ilerleyemez.
Eğer bu yolları erken tasarlamazsanız, insanlar bunları e-posta, sohbet veya tablolarla idare eder. Kısa süre sonra kimse hangi versiyonun son olduğunu bilmez.
Bir satış yöneticisinin iki günlük bir konferansa katılmak için yaptığı seyahat talebini ele alın. Kağıt üzerinde akış kolay görünür: çalışan seyahat tarihlerini, tahmini maliyeti ve seyahat sebebini girer. Yönetici onaylar, finans bütçeyi doğrular ve seyahat rezervasyona geçer.
Bu akış temizdir ama eksiktir.
Şimdi aynı talebi bozun. Çalışan uçuş tahmini ve konferans bileti yükledi ama otel teklifini unuttu. Sistem yalnızca "submitted" ve "approved" durumlarını biliyorsa, insanlar çabucak takılır. Finans eksik bir talep görür, yönetici hazır olduğunu düşünebilir ve çalışan neyin eksik olduğunu bilemeyebilir.
Daha iyi bir akış, bu talebe kendi durumunu verir; örneğin "Waiting for document" veya "Needs update." Çalışancı net bir mesaj görmelidir: "Finans bölümüne ilerlemeden önce otel teklifini ekleyin." Yönetici tüm seyahati reddetmek zorunda kalmamalıdır sadece bir dosya istemek için.
Şimdi ikinci bir problem ekleyin. Yönetici seyahati onaylıyor ama tam tutarı değil. Uçuşu ve bir otel gecesini onaylıyor, ekstra atölye ücretini ve ikinci otel gecesini reddediyor.
Birçok ekip burada kısmi onay sürecine sahip olmadığını fark eder.
Eğer iş akışı talebin sadece bir kısmını onaylayamıyorsa, insanlar geçici çözümler kullanmaya başlar. Tüm talebi reddedip çalışanı yeniden göndermesini isteyebilirler. Ya da sistem sadece tek bir evet/hayır kararı sakladığı için finans yanlışlıkla tam tutarı onaylayabilir.
Daha net bir model her maliyet kalemini veya en azından onaylanan toplamı takip eder. Bir talep şöyle gösterebilir:
Bu tek örnek, onay iş akışı hatalarının genellikle dikkatsizlikten değil, eksik kurallardan kaynaklandığını gösterir. Ekranları tasarlamadan önce bu kuralları tanımlarsanız, iş akışının geri kalanı çok daha güvenilir olur.
İşi geliştirmek için iyi bir yol, talebin temiz geçmeyeceğini varsaymaktır. Bu tek değişiklik, tasarım kalitesini hızla değiştirir.
Dağınık vakalarla başlayın: form eksik, politika belirsiz, onaycı yok veya yalnızca bir kısmın ilerlemesi gerekiyor. Çoğu ekip bunları üç ana kalıba gruplayabilir:
Bu işi yönetilebilir tutar. Her uç durum için yeni bir çözüm icat etmek yerine, küçük bir kalıp seti tanımlayıp bunları her talep türüne uygulayabilirsiniz.
Sırayla çalışın.
İlk olarak, talebin durabileceği her noktayı listeleyin. Eksik belgeleri, geçersiz değerleri, politika ihlallerini, süresi geçmiş son tarihleri, yinelenen gönderimleri ve manuel incelemeyi düşünün. Eğer talep bekleyebilir, başarısız olabilir veya gönderene geri dönebilirse, bunu yazın.
Sonra, her durumda ne olacağına karar verin. Her istisna için dört basit soruyu yanıtlayın:
Örneğin, bir çalışan $600 tutarında seyahat masrafı bildirimi gönderdi. Otel fişi eksik ve bir öğün politika sınırının üstünde. Sadece mutlu yolu tasarlarsanız, talep ya takılı kalır ya da tek bir blok halinde reddedilir. İstisnaları önce tasarlarsanız, sistem eksik fiş için talebi duraklatabilir, çalışanı açık bir mesajla bilgilendirir ve izin verilen öğeleri koşullu olarak onaylanmış olarak işaretleyebilir.
İşte kısmi onay kurallarının önemi burada ortaya çıkar. Onaylanan tutarın şimdi ilerleyip ilerlemeyeceğine, geri kalan kısmın beklemede kalıp kalmayacağına ve talep sahibinin yalnızca uyuşmazlık olan kısmı mı düzenleyebileceğine yoksa tüm iddiayı yeniden mi göndermesi gerektiğine karar vermeniz gerekir.
Eğer AppMaster'da süreci kuruyorsanız, bu dalları UI'ı cilalamadan önce iş mantığında haritalandırma zamanıdır. Reddet, düzenleme için iade ve şartlı onay gibi yollar ayrı yollar olarak ele alındığında, iş akışına güvenmek çok daha kolay olur.
Son olarak, başlangıçtan bitişe bir gerçek senaryo test edin. Gerçek rakamlar, bir gerçek belge açığı ve bir politika istisnası kullanın. Bir kişi akışı bir dakika içinde okuyup sonraki adımı söyleyemiyorsa, tasarım hâlâ çok belirsizdir.
Ekranlar somut hissettirdiği için ekipler genellikle onlarla başlar. Butonları, formları ve panoları tasarlamadan önce kurallar üzerinde anlaşmazlık yaratır. Bu genellikle daha sonra sorun çıkarır çünkü arayüz, aslında kimsenin vermediği kararları gizler.
Daha iyi bir sıra basittir: durumları, devredişleri, son tarihleri ve ilerlemek için gereken kanıtları tanımlayın. Sonra ekranları buna göre oluşturun.
İstisna yolu tasarımı, kural seti küçük ve net olduğunda çok daha kolaydır. Bir talep onaylanabilir, reddedilebilir, düzeltme için geri gönderilebilir veya kısmen onaylanabilir ise, bu durumların herkes tarafından aynı şekilde anlaşılan sade adları olmalıdır. "Returned", "reopened" ve "needs changes" gibi neredeyse eş anlamlı etiketlerden kaçının, eğer gerçekten farklı davranmıyorlarsa.
Bir satın alma talebini ele alın. Yönetici açar ve teklifin eksik olduğunu fark eder. Ekip ne yapılacağını kararlaştırmamışsa, insanlar doğaçlama yapar. Bir yönetici reddeder. Başkası bekletir. Bir başkası sohbet atar ama sistemde hiçbir şey değiştirmez. Kısa sürede kimse duruma güvenmez.
Kuralı önce yazın. Bir teklif eksikse, talep "Needs documents" durumuna geçer. Gönderen sonraki adıma sahiptir. İstek beş iş günü orada kalır. Hiçbir şey gelmezse "Expired" olur ve yeni gönderim gerekir.
Bu tek kural ürünün şeklini bir mockup'tan daha iyi belirler. Artık kullanıcının ne görmesi gerektiğini, hangi hatırlatmanın gönderileceğini ve hangi geçmiş kaydının tutulacağını bilirsiniz.
Pratik bir kural seti dört soruya cevap vermelidir:
Kısmi onaylar da aynı özen gerektirir. Seyahat onaylandı ama otel maliyeti onaylanmadıysa, talep sahibi aynı kaydı mı düzenler yoksa yeni bir tane mi oluşturur? Finans yalnızca değişikliği mi inceler yoksa her şeyi yeniden mi gözden geçirir? Erken karar verilmemişse, ekran düzgün görünse bile arka planda karışıklık kalır.
Ekipler önce kuralları kararlaştırdığında, arayüz daha basit olur. Daha da önemlisi, kullanıcılar "henüz onaylanmadı" gibi bir durumla karşılaştıklarında bile ne yapacaklarını bilirler.
Kötü bir istisna mesajı her şeyi yavaşlatır. İnsanların sadece bir hatanın olduğunu bilmesi yetmez. Ne olduğunu, neyi etkilediğini ve bir sonraki adımda ne yapmaları gerektiğini bilmeliler.
İç kurallarınız açık olabilir ama ekran sadece "Error" veya "Pending review" diyorsa insanlar tahmin yürütür, yanlış dosyaları tekrar gönderir veya destek ister.
Bir tedarikçi onayı örneğini ele alın. Kullanıcı vergi belgesi, banka bilgileri ve sigorta kanıtı ile bir form gönderir. Banka bilgileri uygundur, vergi belgesi güncel değildir ve sigorta kanıtı eksiktir. Sistem sadece "Request not approved" gösteriyorsa kullanıcı için net bir sonraki adım yoktur.
Daha iyi bir mesaj şöyle der: "Banka bilgileriniz onaylandı. Nihai onay için hâlâ güncellenmiş bir vergi belgesine ve sigorta kanıtına ihtiyacımız var." Bu tek cümle neyin yapıldığını neyin yapılmadığını ayırdığı için zaman kazandırır.
İyi mesajlar genellikle dört küçük soruyu cevaplar:
Son madde önemlidir. İnsanlar sonraki adım açık olduğunda görevi tamamlama olasılığı daha yüksektir. "Eksik dosyayı yükleyip yeniden gönderin" demek, "Action required" demekten çok daha iyidir.
Muğlak etiketler endişe yaratır. "Pending review" bir kişinin beklemede olduğunu, eksik veri olduğunu veya iç bir kontrol olduğunu ifade edebilir. Sebebi biliyorsanız açıkça söyleyin. "Waiting for manager approval" ve "Waiting for proof of address" aynı şey değildir ve aynı görünmemelidir.
Bir süreç kısmi onaya izin veriyorsa, bunu durum içinde açıkça gösterin. Kısa bir döküm genellikle tek bir etiket yerine daha iyidir:
Artık kullanıcı sadece önemli olanı düzeltebilir. Tekrar başlamasına gerek yoktur.
Bu aynı zamanda yeniden gönderimin kolay bulunması gereken yerdir. Bir sonraki eylemi mesajın yanında koyun, başka bir ekranda değil. AppMaster'da kullanıcıya gösterilen durum metnini gerçek iş süreci durumlarıyla eşleştirmek, uygulamanın iş akışının tam olarak ne yaptığını söylemesine yardımcı olur.
İyi mesajlar destek taleplerini azaltır, onayları hızlandırır ve sürecin adil hissetmesini sağlar. İnsanlar reddi anladıklarında kabul etmeye daha yatkındır.
Çoğu yeniden iş, tek bir yanlış varsayımdan başlar: normal yol tasarlanması gereken ana şeydir. Mağazalar isteği gönderildi, onaylandı, tamamlandı olarak çizer ve orada durur. Sonra gerçek hayat gelir: bir dosya eksik, yönetici değişiklik istiyor veya talebin sadece bir kısmı ilerleyebiliyor.
Bu boşluk çok hızlı ekstra iş yaratır. İnsanlar manuel düzeltmeler icat eder, yan mesajlar gönderir ve durum adlarını rastgele değiştirir. Birkaç hafta sonra kimse iş akışına güvenmez çünkü her istisna özel bir vaka gibi hissettirilir.
Yaygın bir hata, ideal yolu ürün olarak kabul edip diğer her şeyi temizlik olarak görmek. Bir masraf talebinin fiş, departman onayı ve finans incelemesi gerektiğini varsayın. Fiş eksikse, talep duraklar mı, çalışana geri mi verilir yoksa reddedilir mi? Bu kural baştan net değilse ekip genellikle e-postalar ve yorumlarla yamalar yapar.
Kafa karıştırıcı durum adları başka bir yeniden işe yol açar. "In review 2" veya "Pending action" gibi etiketler zararsız görünebilir, ama insanların ne olacağını tahmin etmeye zorlar. Açık adlar hataları azaltır çünkü problemi, sahibini, sonucu veya sonraki adımı gösterir.
Sahiplik, iş akışlarının bozulduğu bir diğer yerdir. Bir talep, kime ait olmadığı bir durumda asla beklememelidir. Eğer bir vaka bekliyorsa, onu ileri taşıyacak, daha fazla bilgi isteyecek veya kapatacak biri sorumlu olmalıdır. Aksi halde sessiz gecikmeler birikir ve kullanıcılar sistemin taleplerini kaybettiğini düşünür.
Kısmi onay genellikle kötü yönetilir. Ekipler bunu tam reddetme gibi ele alır çünkü daha basit hissettirir. Ama bu sonuçlar farklı anlamlara gelir. Bir seyahat talebi uçuş, otel ve yemek istiyorsa, finans uçuşu ve oteli onaylayıp yemekleri reddedebilir. Bu durum kendi yolu, kendi mesajı ve genellikle kendi takip eylemine ihtiyaç duyar.
Kısmi onay reddetme ile birleştirildiğinde, insanlar tüm talebi yeniden gönderir, belgeleri çoğaltır ve zaten tamamlanmış incelemeleri yeniden başlatır. Bu tamamen gereksiz yeniden iştir.
Basit bir test yardımcı olur: her mutlu olmayan yol durumunu okuyun ve sorun, "Bunun sahibi kim, kullanıcı ne görüyor ve sonra ne oluyor?" Eğer cevap bulanıksa, süreç muhtemelen aynı noktada daha sonra bozulacaktır.
Ekranları inşa etmeden veya otomasyonu aktif etmeden önce dağınık vakalara bir kez daha bakın. İyi bir istisna yolu tasarımı genellikle erken verilen birkaç net karardır; kafa karışıklığı yeniden işe dönüşmeden önce alınır.
Bir istek reddedildiğinde, duraklatıldığında veya yalnızca kısmen onaylandığında, her zaman birinin ne yapacağını, kimin yapacağını ve hangi bilginin eksik olduğunu bilmesi gerekir.
Sürecinizdeki her istisna için bu hızlı kontrolleri kullanın:
Sonra basit bir test yapın. Süreci tasarlamaya yardım etmeyen birine verin. Onlara reddedilmiş bir talep ve bir eksik belge içeren bir talep verin. Bir dakika içinde ne yapacaklarını söyleyemezlerse, süreç hâlâ çok belirsizdir.
Küçük bir örnek vurgular. Bir yönetici yazılım talebini onaylarken donanım kısmını reddederse, durum sadece "Partially approved" diyorsa çalışan her şeyin ilerleyebileceğini varsayabilir. Daha iyi bir durum tam olarak neyin onaylandığını, neyin reddedildiğini ve çalışanın eksik kısmı yeniden gönderebilip göndermeyeceğini söyler.
Bu kuralları çalışır bir dahili uygulamaya dönüştürmek istiyorsanız, önce istisna durumlarını haritalandırın ve mutlu yolu sonra oluşturun. AppMaster'da bu, durumları, iş kurallarını ve gerekli alanları ekranları cilalamadan önce tanımlamak anlamına gelebilir. Bu, ideal versiyonla değil, gerçek işle ilgilenen no-code uygulamalar oluşturmanın pratik bir yoludur.
Sonraki adım basit: en sık rastlanan beş istisnanızı listeleyin, her birine bir sahip atayın ve kullanıcının görmesi gereken mesajı yazın. Bu üç parça netse, geliştirme genellikle çok daha kolay olur.
Why isn't the happy path enough for an approval workflow?Çünkü gerçek gecikmeler genellikle bir şey eksik olduğunda, belirsiz olduğunda, geciktiğinde veya yalnızca kısmen onaylandığında ortaya çıkar. Sadece temiz akışı tasarlarsanız, insanlar sorunları sohbet, e-posta ve manuel geçici çözümlerle çözmek zorunda kalır.
Which exception paths should I design first?En sık olan vakalarla başlayın: red, eksik bilgi ve kısmi onay. Ardından bir delege veya sahip yokluğu gibi takılma durumlarını ekleyin.
What statuses should an approval app have?Herkesin tek bir anlam yükleyebileceği küçük ve net durumlar kullanın. Pratik bir varsayılan küme: approved, rejected, needs documents, needs changes, partially approved ve süre kullanıyorsanız expired.
How should the process handle missing documents?Kullanıcı tam olarak neyin eksik olduğunu ve sonraki adımda ne yapması gerektiğini görmelidir. İyi bir varsayılan, isteği "Needs documents" gibi bir duruma taşımak, eksik öğeleri açıkça adlandırmak ve tüm talebi reddetmek yerine ilgili kişiye geri göndermektir.
How do I handle partial approvals without creating rework?Bunu tam reddetme yerine kendi yolu olarak ele alın. Nelerin onaylandığını, nelerin reddedildiğini, ilgili yeni onaylanmış toplamı gösterin ve isteği yapanın değişikliği kabul edip edemeyeceğini, talebi düzenleyip yeniden gönderebileceğini veya yalnızca itiraz edilen kısmı yeniden sunup sunamayacağını belirtin.
What should happen when a request gets stuck with no action?Her bekleyen durumun bir sahibi ve bir zaman kuralı olmalıdır. Bir onaycı yoksa veya bir istek çok uzun süre bekliyorsa, iş akışı durumu takibe almalı, yeniden atamalı veya süresi dolmuş saymalıdır; aksi halde istek takılı kalır.
What makes an exception message actually useful?Kısa ve spesifik olun. Kullanıcıya hangi kısmın reddedildiğini veya eksik olduğunu, hangi kısmın kabul edildiğini, bir sonraki adımda ne yüklemesi veya neyi onaylaması gerektiğini ve yeniden gönderimden sonra ne olacağını söyleyin.
Should I design the screens first or the workflow rules first?Önce kuralları tanımlayın. Durumlar, sahipler, son tarihler, gerekli dosyalar ve sonraki eylemler üzerinde anlaşın; sonra butonları ve panelleri çizin. Arayüz, zaten verilmiş kararları yansıtmalıdır.
How can I test whether my exception path is clear enough?Başlangıçtan bitişe kadar gerçekçi bir senaryoyu bir veya iki problemle—örneğin eksik bir dosya veya bir politika ihlaliyle—test edin. Yeni bir kişi bir dakikadan kısa sürede ne yapacağını söyleyemiyorsa, akış hâlâ çok belirsizdir.
How would I build this kind of workflow in AppMaster?İş mantığınızda istisna durumlarını, gerekli alanları, sahiplikleri ve dallanmaları UI'ı cilalamadan önce haritalandırın. AppMaster'da bu, durumları ve kuralları tanımlayıp sonra ekranları oluşturmak anlamına gelir.
10 Mar 2026
7 dk
08 Mar 20268 dk
07 Mar 20266 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
