Teklif, satın alma ve içerik onaylarında darboğaz yaratmadan yetki, bildirim ve işlem geçmişi tasarlamak.
Onayı gerektiren riski açıkça tanımlayın
Bir işlem neden onaylanıyor sorusu cevaplanmadan rol ve ekran tasarlamak doğru değildir. Finansal limit, marka riski, yasal sorumluluk veya veri güvenliği gibi gerekçeler birbirinden farklı kontrol ister.
Düşük riskli ve tekrarlanan işlemler belirli kurallar içinde otomatik geçebilir. Tutar, indirim oranı, içerik türü veya müşteri segmenti gibi eşikler kullanılarak onay yükü azaltılabilir.
- Risk türü ve seviyesi
- Onay eşiği
- Gerekli kanıt veya ek
- Karar için beklenen süre
Datauraf notu Doğru teknoloji kararı, ancak kullanıcı davranışı ve iş hedefi aynı masada değerlendirildiğinde kalıcı sonuç üretir.
Rolleri kişilere bağımlı bırakmayın
Süreç belirli bir kişinin hesabına bağlanırsa izin, görev değişimi veya yoğunluk sırasında durabilir. Onaycılar rol, departman ve gerektiğinde tutar aralığı üzerinden tanımlanmalıdır.
Vekâlet ve yönlendirme davranışı baştan planlanmalıdır. Süresi belirli vekâletler, işlem geçmişinde görünür olmalı; kritik yetkiler kontrolsüz biçimde devredilmemelidir.
Bildirim yerine karar ekranını iyileştirin
Çok sayıda e-posta göndermek onayı hızlandırmaz. Kullanıcı tek ekranda bekleyen işleri öncelik, son tarih ve risk bilgisiyle görebilmelidir. Karar vermek için gereken belge ve önceki açıklamalar aynı bağlamda sunulmalıdır.
Hatırlatmalar ilk bildirimden hemen sonra tekrarlanmamalı; işin önemine ve bekleme süresine göre kademeli çalışmalıdır. Süre aşımında bir üst role yönlendirme gerekiyorsa bu kural ekip tarafından bilinmelidir.
- Toplu bekleyen iş görünümü
- Karar bağlamı ve ekler
- Açıklamalı ret seçeneği
- Kademeli hatırlatma
İşlem geçmişini denetim kadar öğrenme için kullanın
Kim, ne zaman, hangi bilgiyle karar verdi kaydı sorun çözmeyi kolaylaştırır. Ancak geçmiş yalnız teknik günlük olarak kalmamalı; kullanıcı tarafından anlaşılır bir zaman çizelgesinde gösterilmelidir.
Onay süreleri ve sık ret nedenleri düzenli incelendiğinde süreç tasarımı geliştirilebilir. Aynı eksik nedeniyle sürekli geri dönen talepler varsa form veya başlangıç kontrolü iyileştirilmelidir.