Yeniden İşlemeyi Azaltan İş Formları İçin Veri Doğrulama Kuralları

İş formları neden yeniden iş çıkarır

Bir form tamamlanmış gibi görünebilir ama formu alan kişi için yine de işe yaramaz olabilir. Birisi telefon numarası olmadan müşteri talebi gönderir, teslimat tarihini sipariş tarihinden önce girer veya veritabanında zaten bulunan bir şirketi yeniden oluşturur. Sonraki ekip durmak, durumu araştırmak ve düzeltme istemek zorunda kalır.

Bu küçük eksikler zamanla büyür. Bir satış koordinatörü eksik bütçe aralığını öğrenmek için on dakika harcayabilir. Bir destek yöneticisi talebi onayladıktan sonra, kayıt hizmet ekibine ulaştığında iletişim e-postasında bir yazım hatası olduğunu fark edebilir. Bir hata başka bir ekibe devredildikten veya onaydan geçtikten sonra birkaç kişinin kaydı yeniden açması, ilgili belgeleri güncellemesi ve değişikliği açıklaması gerekebilir.

Bu hataların çoğuna kötü form tasarımı yol açar. Bir alanda «Ayrıntılar» yazıyorsa insanlar önemli olduğunu düşündükleri her şeyi girer. «Hesap adı» ve «müşteri adı» gibi iki alan birbirine benziyorsa çalışanlar bunları farklı şekillerde kullanabilir. İnsanlar göremedikleri kurallara uyamaz.

İyi iş formları için veri doğrulama kuralları, kişi formu hâlâ açıkken eksik, tutarsız ve yinelenen bilgileri yakalar. Tarih seçici belirsiz tarih girişlerini önler. Zorunlu bir iletişim yöntemi, sonuçsuz kalan talepleri engeller. Yinelenen kayıt kontrolü, aynı müşteri için iki kayıt oluşturulmasını durdurabilir.

Amaç, başka bir kişinin hemen kullanabileceği bilgileri toplamaktır. Bu, her alanı zorunlu yapmak anlamına gelmez. Talebi başka bir mesajlaşma turuna gerek kalmadan yönlendirmek, onaylamak, yerine getirmek veya desteklemek için gereken ayrıntıları istemek anlamına gelir.

Örneğin bir operasyon talep formu, talep sahibinin departmanını, ihtiyaç duyulan hizmeti ve son tarihi isteyebilir. Kişi belirli bir hizmeti seçtikten sonra ek sorular gösterebilir. Böylece form kısa kalırken operasyon ekibi ilk seferde işlem yapabileceği bir kayıt alır.

İnsanların ihtiyaç duyduğu bilgilerle başlayın

Bir iş formu, birinin karar vermek veya bir görevi tamamlamak için kullanacağı bilgileri toplamalıdır. Daha sonra işe yarayabilecek uzun bir bilgi listesinden değil, sürecin sonundaki işlemden başlayın.

Bir müşteri talep formu, destek ekibinin işi atamasına, öncelik belirlemesine ve müşteriyle iletişim kurmasına yardımcı olabilir. Müşterinin adı, bir iletişim yöntemi, talep türü, açık bir açıklama ve belki de hesap numarası gerekir. Ekip bu yanıtı kullanmayacaksa «Bizi nasıl duydunuz?» sorusunun formda yeri yoktur.

Her gönderimin desteklemesi gereken kararları yazın. Bunlar bir sorumlu atamak, masrafı onaylamak, servis ziyaretini planlamak, fatura oluşturmak veya tekrarlanan bir sorunu raporlamak olabilir. Ardından bu kararları etkileyen alanları belirleyin.

Bir yönetici seyahat masraflarını onaylıyorsa tutara, masraf kategorisine, seyahat tarihlerine ve bütçe sorumlusuna ihtiyaç duyabilir. Çalışanın masa numarasına muhtemelen ihtiyacı yoktur. Kullanılmayan alanları kaldırmak formu doldurmayı hızlandırır ve dikkatsiz girişleri azaltır.

Kuralları oluşturmadan önce geçerli bir gönderimi günlük dille açıklayın: «Ekip, talep sahibiyle iletişim kurabilir, sorunu anlayabilir, talebi doğru kişiye atayabilir ve varsa son tarihi görebilir.» Bu yaklaşım, eksikleri alan alan hazırlanan bir kontrol listesinden daha iyi ortaya çıkarabilir.

Bu yaklaşım, gereğinden katı zorunlu alan doğrulamasını da önler. Bir alanı veritabanında boş bir sütun olduğu için değil, sonraki kişi yanıt olmadan işini yapamayacağı için zorunlu tutun. Telefon desteği talebi telefon numarası gerektirebilir. Yalnızca e-posta üzerinden alınan bir talep gerektirmeyebilir.

AppMaster ile ekipler ihtiyaç duydukları verileri modelleyebilir ve gerçek sürece uygun bir form oluşturabilir. Küçük başlayın, formu talepleri gönderen ve inceleyen kişilerle test edin, ardından gerçek bir görev gerektirdiğinde alan ekleyin. Temiz veri, daha az ve daha iyi soruyla başlar.

Zorunlu alanları dikkatle belirleyin

Bir zorunlu alan formda yer almayı hak etmelidir. Yanıt olmadan sonraki işlem tamamlanamıyorsa alanı zorunlu yapın. Bir müşteri talebinde iletişim adı, yanıt verilecek bir yol ve talep türü gerekli olabilir. İş unvanı veya ikincil telefon numarası genellikle gerekli değildir.

Çok fazla zorunlu alan kötü veri üretir. İnsanlar formu gönderebilmek için «Yok», rastgele rakamlar veya kopyalanmış metinler yazar. Böylece kuralın önlemeyi amaçladığı temizlik işi ortaya çıkar.

Bir kişi Gönder düğmesine basmadan önce hangi alanların zorunlu olduğunu gösterin. «E-posta adresi (zorunlu)» gibi açık bir etiket kullanın ve bunu tutarlı biçimde uygulayın. Yalnızca renge güvenmeyin.

Geçerli bir girişin nasıl göründüğünü alanın yanında açıklayın. Kısa bir örnek, önlenebilir hataları azaltır:

• «İş e-postası (zorunlu): [email protected]»
• «Sipariş numarası (zorunlu): makbuzunuzdaki 8 haneli numarayı kullanın»
• «Tercih edilen iletişim tarihi (zorunlu): gelecekteki bir tarihi seçin»

Zorunlu alan doğrulaması formun amacına uygun olmalıdır. Destek ekibi ekran görüntüsünü yalnızca teknik sorunlarda ihtiyaç duyuyorsa kişi «Teknik sorun» seçeneğini belirledikten sonra bunu isteyin. Her müşteriden dosya yüklemesini istemek süreci zorlaştırır ve çalışanlara ilgisiz ekler bırakır.

Aynı mantığı koşullu alanlarda da kullanın. Ticari bir müşterinin şirket adı ve vergi numarası girmesi gerekebilir, bireysel müşterinin ise gerekmez. Bu ayrıntıları yalnızca kişi işletme olduğunu belirttikten sonra zorunlu tutun.

Formu AppMaster'da oluşturuyorsanız zorunlu alan kurallarını form akışına ve iş mantığına bağlayabilirsiniz. Yayınlamadan önce her yolu test edin: zorunlu alanı boş bırakın, geçersiz biçimde bir değer girin ve koşullu alanları gösteren seçenekler arasında geçiş yapın. Yalnızca ekibinizin kullanacağı bilgileri isteyin.

Çelişkileri yakalayan alanlar arası kontroller ekleyin

Bir alan tek başına doğru görünebilir, ancak başka bir yanıtla karşılaştırıldığında hatalı bir talep oluşturabilir. Alanlar arası doğrulama, form ilerlemeden önce bu ilişkileri kontrol eder.

Tarihler yaygın bir örnektir. Form, bitiş tarihinin başlangıç tarihinden önce olmasını reddetmelidir. İzin talebinde, işe dönüş tarihinin seçilen izin süresi içinde kalması da uyarı vermelidir. Kişi ayrıntıları hâlâ hatırlıyorken düzeltebilmesi için mesajı alanların yanında gösterin.

Harcama kuralları da aynı yaklaşımı gerektirir. Bir çalışan 2.500 ABD doları tutarında satın alma talebi giriyor ve normal sınır 1.000 ABD dolarıysa form bir iş gerekçesi ve onay sorumlusu isteyebilir. Bu alanları gönderimden sonra beklemek yerine tutar sınırı aşar aşmaz gösterin.

Teslimat ayrıntıları da kontrol edilmelidir. «Müşteriye gönder» seçeneğini belirleyen kişi eksiksiz bir teslimat adresi vermelidir. «Müşteri gelip alacak» seçilirse adres kaybolmalı veya isteğe bağlı hâle gelmelidir. İlgisiz alanlar kafa karıştırıcı verileri teşvik eder.

Yararlı alanlar arası doğrulama kuralları şunlardır:

• Başlangıç tarihi, bitiş tarihinden önce olmalıdır.
• Belirli bir tutarın üzerindeki talepler gerekçe gerektirir.
• Kurye teslimatı sokak, şehir, posta kodu ve ülke bilgilerini gerektirir.
• «Bireysel» ve «Şirket hesabı» seçenekleri aynı anda geçerli olamaz.
• Tercih edilen iletişim yöntemi, buna karşılık gelen bir telefon numarası veya e-posta adresi gerektirir.

AppMaster gibi kodsuz bir araçta ekipler bu kontrolleri form mantığına veya uygulama kaydı kaydetmeden önce çalışan bir iş sürecine yerleştirebilir. Önemli kurallar sunucuda da çalışmalıdır. Böylece içe aktarımlar, API istekleri ve mobil uygulamalar da aynı kurallara uyar.

Her kontrolü gerçek bir iş kararına bağlayın. Çalışanlar bir istisnayı daha sonra zarar vermeden ele alabiliyorsa formu engellemeyin. Çelişkili yanıtlar iadelere, uyumluluk sorunlarına veya gereksiz takip işlerine yol açıyorsa bunları gönderimden önce yakalayın.

Yinelenen kayıtların yayılmasını önleyin

Yinelenen kayıtlar küçük hataları sürekli bir işe dönüştürür. Aynı talebi iki kez gönderen bir müşteri iki yanıt alabilir. Bir faturanın iki sürümü finans ekibinin kafasını karıştırabilir. Yinelenen kayıtlar raporlara veya dışa aktarımlara ulaştığında birinin kayıtları elle karşılaştırması gerekir.

Bir kaydı tanımlayan alanları seçin. Fatura numarası yalnızca bir kez bulunmalıdır. Paylaşılan gelen kutuları istisna gerektirse de müşteri e-postası çoğu zaman tekil olmalıdır. Servis talebi için müşteri, talep türü ve referans numarasını birleştiren bir kontrol yararlı olabilir.

Yeni girişleri kaydetmeden önce mevcut kayıtlarla karşılaştırın. Fatura numaraları, sipariş kimlikleri ve çalışan kimlikleri için tam eşleşme iyi çalışır. İsimler ve adresler daha esnek bir karşılaştırma gerektirir, çünkü insanlar bunları farklı biçimlerde girebilir. «Maya Chen» ve «Maya C. Chen» aynı kişiyi ifade ediyor olabilir, ancak form bunu kesin kabul etmemelidir.

Açıklama yapmadan formu engellemek yerine olası eşleşmeleri gösterin. Açık bir mesaj şöyle olabilir: «Bu e-posta adresine sahip bir müşteri zaten var. Yeni bir müşteri oluşturmadan önce aşağıdaki kaydı inceleyin.» Çalışanların karar vermesine yetecek adı, e-postayı, şirketi ve oluşturulma tarihini gösterin.

Benzer kayıtlar gerçekten farklı olduğunda çalışanların devam edebilmesi için bilinçli bir yol da sunun. İki kişi aynı ortak iş e-postasını kullanabilir veya iki müşterinin adı aynı olabilir. Mevcut kaydı kullanma, yine de yeni kayıt oluşturma ya da ayrıntıları düzenleyip yeniden kontrol etme seçeneklerini sunun.

Yinelenen kayıtlar ciddi takip işi çıkarıyorsa bir gerekçe isteyin. Örneğin muhasebe ekibi, aynı vergi numarasına sahip ikinci bir tedarikçi oluşturmadan önce çalışanlardan not girmelerini isteyebilir.

AppMaster'da Data Designer içinde tekil alanlar tanımlayabilir ve kayıt oluşturmadan önce eşleşme aramak için bir Business Process kullanabilirsiniz. Süreç, olası eşleşmeleri web veya mobil forma döndürebilir ve kullanıcı farkı onayladıktan sonra yeni girişi kaydedebilir. Böylece karar görünür kalır ve kayıt kümesi daha temiz olur.

İnsanların işlem yapabileceği düzeltme mesajları yazın

Bir form hatası, kişinin sorunu birkaç saniye içinde düzeltmesine yardımcı olmalıdır. «Geçersiz giriş» gibi belirsiz uyarılar, insanları sorunu aramaya ve çözümü tahmin etmeye zorlar. İyi form hata mesajları alanı belirtir, kuralı açıklar ve kullanılabilir bir örnek verir.

Her mesajı ilgilenilmesi gereken alanın yanında gösterin. Formun üstünde bir özet de varsa bunu yalnızca hatalı alanlara yönlendirmek için kullanın. Kullanıcıları küçük bir bildirimi bulmak için uzun bir sayfayı taramaya zorlamayın.

Bir sonraki işlemi açıklayan sade bir dil kullanın. «ERR-104» gibi dahili kodlar geliştiriciye yardımcı olabilir, ancak müşteri talebi giren satış koordinatörüne hiçbir şey anlatmaz.

• «Geçerli bir iş e-postası girin, örneğin [email protected]» yazın, «Geçersiz e-posta biçimi» yazmayın.
• «Bitiş tarihi, başlangıç tarihiyle aynı veya daha sonraki bir tarih olmalıdır» yazın, «Tarih aralığı hatası» yazmayın.
• «Bu e-postaya sahip bir müşteri zaten var. Yeni kayıt oluşturmadan önce müşteriyi arayın» yazın, «Yinelenen kayıt» yazmayın.
• «0'dan büyük bir tutar girin» yazın, «Değer aralık dışında» yazmayın.

Yararlı bir mesaj, kişiyi suçlamadan sorunu açıklar. «Hesap numarasının 8 haneli olması gerektiği için talebinizi kaydedemedik» ifadesi, «Yanlış hesap numarası girdiniz» ifadesinden daha anlaşılırdır.

Form hata bulduğunda geçerli girişleri koruyun. 14 alanı dolduran bir kişi yalnızca hatalı alanı düzeltmek zorunda kalmalıdır. Doğrulama hatasından sonra sayfayı temizlemek, 20 saniyelik düzeltmeyi tekrarlanan bir işe dönüştürür.

Mesajları masaüstünde ve mobilde kontrol edin. Masaüstünde alanın yanında duran bir not telefonda alanın çok aşağısında kalabilir. Veri giren kişi mesajı ihtiyaç duyduğu yerde görebilmelidir.

AppMaster, ekiplerin form alanlarını görsel iş mantığına bağlamasına ve bir kural başarısız olduğunda anlaşılır mesajlar göstermesine yardımcı olur. Bir müşteri talep formu, kullanıcıdan eksik iletişim yöntemini düzeltmesini isterken talep ayrıntılarını koruyabilir. Böylece tekrar yazma ve formu yarıda bırakma azalır.

Doğrulama kurallarını adım adım oluşturun

Basit bir alan haritasıyla başlayın. Her alan için neden toplandığını, doğruluğundan kimin sorumlu olduğunu ve hangi kuralın uygulanacağını yazın. Satış operasyonları sorumlusu müşteri hesap bilgilerinden, destek yöneticisi ise talep kategorileri ve öncelik seçeneklerinden sorumlu olabilir. Bu, kimsenin açıklayamayacağı veya sürdüremeyeceği kuralları önler.

İlk sürümü küçük tutun. Her olası girişi denetlemeye çalışmak yerine en pahalı düzeltmeleri önleyen kuralları ekleyin. Bir müşteri talep formunda bu, iletişim e-postasını zorunlu tutmak, istenen tarihin gönderim tarihinden sonra olduğunu kontrol etmek ve aynı hesapta açık bir talep olup olmadığını aramak olabilir.

Bir sonraki kuralı eklemeden önce tek bir kural oluşturup test edin. Eksiksiz geçerli bir giriş, eksik zorunlu değer içeren bir giriş, bitiş tarihinin başlangıç tarihinden önce olması gibi iki çelişkili alan ve mevcut bir kayıtla eşleşen bir giriş test edin.

Her testten sonra ne olduğunu izleyin. Form tam olarak hangi alanı gösteriyor mu? Daha önce girilen bilgileri koruyor mu? Kullanıcı bir iş arkadaşına sormadan düzeltmeyi anlayabiliyor mu?

Ardından formu normal işlerinde kullanan kişilerden denemelerini isteyin. Yinelenen bir müşteri talebini kaydetmek veya eksik telefon numarasıyla acil bir kayıt göndermek gibi gerçekçi görevler verin. Geri bildirimleri, kuralların çok erken devreye girdiğini veya etiketlerin anlaşılmadığını sıkça ortaya çıkarır.

AppMaster'da kontrolleri görsel form alanlarına ve iş süreçlerine bağlayabilir, ardından sürümden önce akışı test edebilirsiniz. Her kuralın, sorumlusunun ve testte kullanılan örneklerin kısa bir kaydını tutun. Bir politika veya iş akışı değiştiğinde ekip geçici bir çözüm eklemek yerine doğru kuralı güncelleyebilir.

Form kullanıcılarını zorlayan hatalar

Kötü doğrulama, insanların sorunu nasıl düzelteceğini açıklamadan işi tamamlamasını engeller. İyi iş formları için veri doğrulama kuralları kayıt kalitesini korur ve kullanıcılara net bir ilerleme yolu sunar.

Her alanı zorunlu yapmak

Ekipler bazen birinin bu bilgiye ileride ihtiyaç duyabileceğini düşünerek her alanı zorunlu işaretler. Bu, formu dolduran kişiyi yavaşlatır ve «Yok» veya «00000» gibi uydurma yanıtları teşvik eder. Bu değerler boş bir alandan daha fazla temizlik işi çıkarır.

Bir alanı yalnızca süreç onsuz devam edemiyorsa zorunlu tutun. Müşteri talebinde iletişim adı, e-posta adresi ve talep türü gerekebilir. İlk aşamada ikincil telefon numarası, şirket büyüklüğü veya teslimat tercihi muhtemelen gerekmez. Ek ayrıntıları, bir kararı etkiledikleri zaman isteyin.

İnsanları yönlendirme olmadan durdurmak

«Geçersiz giriş» mesajı kullanıcıya bir şeyin başarısız olduğunu söyler, ancak bundan sonra ne yapacağını anlatmaz. Hatayı alanın yanında gösterin, sorunu açıkça adlandırın ve kabul edilen biçimi açıklayın.

«Şirket e-postası girin, örneğin [email protected]» yazın, «E-posta hatası» yazmayın. Bitiş tarihi başlangıç tarihinden önceyse «Başlangıç tarihinden sonraki veya aynı günü seçin» deyin. Bu talimatlar tekrar denemeleri ve destek taleplerini azaltır.

Alanlar arası doğrulama da dikkatli bir dil gerektirir. Form, seçilen teslimat yönteminin girilen adresle uyumlu olup olmadığını kontrol edebilir, ancak tüm gönderimi genel bir uyarıyla reddetmek yerine çelişkiyi açıklamalıdır.

Yinelenen kayıt tespiti de benzer sorunlara yol açabilir. E-posta adresleri, isimler ve şirket bilgileri mevcut bir kayda benzeyebilir, ancak aynı kişiyi göstermeyebilir. Yalnızca yakın bir eşleşme bulundu diye gönderimi engellemeyin. Olası kaydı gösterin ve inceleme seçeneği sunun.

Bir formu yayınlamadan önce sürece aşina olmayan birinden eksik, çelişkili ve neredeyse yinelenen bilgiler girmesini isteyin. Birkaç saniye içinde hatayı nasıl düzelteceğini anlayamıyorsa kuralı veya mesajını gözden geçirin.

Yayınlamadan önce hızlı kontroller

Bir form tamamlanmış görünebilir ama yine de hatalı kayıtlar oluşturabilir. İnsanlar forma güvenmeden önce sıradan ve dağınık girişlerle test edin. Formu oluşturmayan bir iş arkadaşınızdan da denemesini isteyin. Bu kişi belirsiz etiketleri ve kafa karıştıran hata mesajlarını, kuralları yazan kişiden daha hızlı fark edebilir.

Her zorunlu alanı sırayla boş bırakın. Form yalnızca gerçekten gerekli bir bilgi eksik olduğunda gönderimi engellemelidir. Tam alanı göstermeli ve kişinin ne girmesi gerektiğini söylemelidir. «Güncelleme gönderebilmemiz için iletişim e-postası girin» ifadesi, «Geçersiz giriş» ifadesinden daha açıktır.

Birbirine bağlı alanları gerçekçi kombinasyonlarla test edin. Teslimat bitiş tarihi başlangıç tarihinden önce olmamalıdır. Kullanıcı tercih edilen iletişim yöntemi olarak «E-posta»yı seçtiğinde e-posta alanı zorunlu hâle gelmelidir.

Yayınlamadan önce formu eksik bilgilerle, uyuşmayan ilişkili ayrıntılarla ve daha önce var olan bir e-posta, müşteri kimliği veya referans numarasıyla gönderin. Her düzeltme mesajını bağlam olmadan okuyun ve sonraki işlemin açık olup olmadığına karar verin. Formu ekibinizin ve müşterilerinizin kullandığı cihaz türlerinde test edin.

Aynı telefon numarasının boşluksuz yazılması veya şirket adında küçük bir yazım değişikliği olması gibi tam ve yakın yinelenen eşleşmeleri de deneyin. Form, olası yinelenen kayıtlar konusunda kullanıcıları uyarmalı ve mevcut kaydı incelemelerine izin vermelidir. Girdilerini sessizce silmemelidir.

Formu AppMaster'da oluşturuyorsanız web veya mobil arayüzü, gönderimi yöneten iş sürecini ve sonunda oluşturulan veritabanı kaydını test edin. Yalnızca tek bir ekranda çalışan bir kural, içe aktarımlardan veya başka bir uygulama ekranından gelen hatalı verileri durdurmaz.

Başarısız testleri yazın ve sürümden önce düzeltin. Gerçekçi kontroller için harcanan on dakika, form kullanıma açıldıktan sonra saatlerce sürecek temizlik işini önleyebilir.

Örnek: müşteri talep formu

Bir satış koordinatörü, hizmet teklifi isteyen Northline Foods şirketinden bir telefon alır. Müşteri talep formunu açar ve şirket adını, iletişim kişisini, istenen hizmeti, teslimat tarihini ve kısa bir açıklamayı girer.

Form kaydetmeden önce telefon numarası veya e-posta adresi ister. Koordinatör ikisini de girmemiştir ve form şu mesajı gösterir: «Ekibin bu müşteriyle iletişim kurabilmesi için bir e-posta adresi veya telefon numarası ekleyin.» Koordinatör e-posta adresini ekler ve devam eder. Mesaj hem sorunu hem de çözümü açıklar.

Ardından kurulum hizmetini seçer ve ertesi gün için teslimat tarihi belirler. Bu hizmet için beş iş günü hazırlık gerekir. Alanlar arası doğrulama kontrolü hizmeti tarihle karşılaştırır ve şu mesajı gösterir: «Kurulum için en az beş iş günü gerekir. 18 Haziran veya sonrasını seçin ya da daha kısa hazırlık süresi olan bir hizmet belirleyin.» Koordinatör, imkânsız bir tarih vaat edilmeden önce talebi düzeltebilir.

Form bir müşteri kaydı oluşturmadan önce yinelenen kayıt tespiti, şirket adını, e-posta alan adını ve telefon numarasını mevcut kayıtlarla karşılaştırır. Aynı ana telefon numarasına sahip «Northline Food Ltd» kaydını bulur. Form mevcut müşteriyi gösterir ve koordinatörün bu kaydı açıp talebi eklemesine ya da bunun farklı bir tüzel kişiliğe veya iletişim numarasına sahip yeni bir müşteri olduğunu onaylamasına izin verir.

Koordinatör mevcut kaydı açar, bunun aynı şirket olduğunu görür ve talebi kayda ekler. Satış ekibi artık tek bir müşteri profiline, ulaşılabilir bir iletişim kişisine ve yerine getirebileceği bir teslimat tarihine sahiptir.

Daha iyi doğrulamayı bir sonraki formunuza taşıyın

Düzenli olarak düzeltme gerektiren bir form seçin. Müşteri talep formu, masraf bildirimi veya satış adayı formu, çok sayıda sıra dışı durum içeren nadir bir süreçten genellikle daha iyi bir başlangıçtır. Her gün 50 kişinin kullandığı bir formu düzeltmek, şaşırtıcı miktarda takip işini ortadan kaldırabilir.

Birisi hatalı bir giriş gönderdikten sonra ne olduğunu yazın. Belki bir destek görevlisinin hesap numarasını istemek için talep sahibine e-posta göndermesi gerekir veya finans ekibi onaylı dönem dışındaki tarihleri içeren masraf bildirimlerini geri gönderir. En yaygın düzeltmeleri iş formları için açık veri doğrulama kurallarına dönüştürün.

İnsanların anında düzeltebileceği hataları önleyen kurallarla başlayın: sonraki adım için gereken bilgileri zorunlu tutun, tarih aralıkları gibi ilişkili değerleri kontrol edin, kayıt oluşturmadan önce mevcut bir e-postayı veya fatura numarasını arayın ve sorunları alanın yanında sade bir dille açıklayın.

Formu yayınladıktan sonra kullanıcıların gördüğü hataları inceleyin. Tekrarlanan bir hata, kuralın çalıştığını gösterebilir, ancak etiketin, talimatın veya alan sırasının insanları şaşırttığı anlamına da gelebilir. Çok sayıda kullanıcı iş e-postası yerine kişisel e-posta giriyorsa bunu sonradan reddetmekle kalmayın, gönderimden önce «Şirket e-posta adresinizi girin» deyin.

Gerçek iş istisnelerini göz önünde bulundurun. Onaylı müşterilerden oluşan küçük bir grup için boş satın alma siparişi numarası kabul edilebilir. Çalışanları daha sonra kayıtları elle düzenlemeye zorlamak yerine bu gruba görünür bir istisna yolu sunun.

AppMaster, ekiplerin kodsuz iş formları oluşturmasına, veri alanları tanımlamasına ve birden fazla alanı ilgilendiren kontroller için görsel iş süreçleri kullanmasına yardımcı olur. Aynı proje kaydı saklayabilir, API sunabilir ve çalışanlara web veya mobil arayüz sağlayabilir.

Bu hafta tekrarlanan bir düzeltme işini seçin ve form aşamasında durdurun. Değişiklikten sonra ne sıklıkta ortaya çıktığını ölçün. Bu sayı, kuralın çalışanların zamanını kurtarıp kurtarmadığını veya daha anlaşılır bir istisnaya ihtiyaç duyup duymadığını gösterir.