Profesyonel hizmet firmaları için talep uygulaması: pratik bir plan

Dağınık talepler neden gereksiz gecikmelere yol açar

Yeni bir müşteri talebi çoğu zaman bir e-postayla başlar, ardından yönlendirilen mesajlara, görüşme notlarına ve daha sonra güncellenen bir elektronik tabloya dağılır. Şirket adı bir yerde, projenin kapsamı başka bir yerde bulunur; verilen teslim tarihi ise gelen kutusunun derinliklerinde kaybolur. Ekip üyeleri, müşterinin daha önce başka bir çalışana verdiği bilgileri yeniden istemek zorunda kalır.

Bu küçük boşluklar hızla büyür. Bir ortak, net bir özet olmadan uygunluğu değerlendiremez. Operasyon ekibi, tahmini başlangıç tarihini bilmeden iş atayamaz. Bir kişi, takip işini bir çalışma arkadaşının yapacağını düşünürken çalışma arkadaşı talebin hâlâ incelendiğini varsayar.

Çakışma kontrollerinde risk daha da büyüktür. Firma, kapsamlı bir çalışmaya başlamadan veya taahhütte bulunmadan önce müşteriyi, ilişkili kuruluşları, karşı tarafları ve ilgili iş ayrıntılarını incelemelidir. Bu bilgiler mesajlara dağılmışsa incelemeciler resmin yalnızca bir bölümünü görebilir. Aceleyle yapılan bir kontrol, firmanın işi kabul edip edemeyeceğini etkileyen bir ilişkiyi gözden kaçırabilir.

Profesyonel hizmet firmaları için bir talep uygulaması, ilk başvurudan itibaren temel bilgileri tek bir ortak kayıtta toplar. Her talebin Yeni, Çakışma incelemesi bekleniyor, Onaylandı veya Atandı gibi net bir durumu olur. Ekip, hikâyeyi e-postalardan yeniden oluşturmak yerine güncel bilgileri görür.

Her sonraki adımın da bir sorumlusu olmalıdır. İş geliştirme koordinatörü eksik bilgileri toplayabilir, belirlenmiş bir incelemeci çakışma kontrolünü tamamlayabilir ve uygulama lideri devam edip etmeyeceğine karar verebilir. Sorumluluğun net olması, kimin harekete geçmesi gerektiği bilinmediği için umut vadeden bir talebin günlerce beklemesini önler.

İyi bir müşteri talep iş akışı basit hissettirmelidir. Sağlıklı bir karar için yeterli bağlamı toplar, talebi doğru kişilere yönlendirir ve neler olduğuna dair kısa bir geçmiş tutar. Firma işi kabul ettiğinde aynı kayıt, onaylanan kapsamı, kişileri, bütçe aralığını ve taahhütleri koruyarak teslimat ekibine aktarılabilir.

Bu ortak kayıt, araştırma ve tahmin işlerini tekrarlanabilir bir devir süreciyle değiştirir. Yöneticiler açık talepleri, her birinin nerede beklediğini ve kimin harekete geçmesi gerektiğini de görebilir.

Sürece dahil olan kişileri ve kararları haritalayın

Her talebin firma içinde izlediği yol net olmalıdır. Alanları veya ekranları oluşturmadan önce talebe kimlerin dokunduğunu ve her kişinin hangi kararı verdiğini belirleyin. Böylece herkesin başka birinin yanıt vereceğini düşündüğü ortak gelen kutusu sorunu ortadan kalkar.

Çoğu firmanın dört role ihtiyacı vardır: talebi gönderen kişi, firmanın işi üstlenip üstlenemeyeceğini kontrol eden kişi, işi onaylayan kişi ve işi teslim eden kişi. Küçük bir firmada tek kişi birden fazla rol üstlenebilir. Uygulama yine de her kararı ayrı ayrı kaydetmelidir.

Potansiyel bir müşteri, bir danışmanla görüştükten sonra proje talep formu gönderebilir. Talep koordinatörü, talebin yeterli ayrıntı içerip içermediğini kontrol eder. Çakışma incelemecisi isimleri ve ilişkili tarafları inceler. Uygulama lideri firmanın devam edip etmeyeceğine karar verir. Ardından atanan danışman onaylanan talebi, sonraki adımı ve son tarihi alır.

Müşteri sorularını iç notlardan ayırın

Müşteriler yalnızca yanıtlayabilecekleri soruları görmelidir: şirket adı, projenin amacı, son tarihler, kişiler ve beklenen bütçe aralığı. İç alanları müşteri formundan uzak tutun. Bunlar arasında risk notları, kapasite yorumları, ücretlendirme yönlendirmeleri, çakışma ayrıntıları ve firmanın kararı bulunabilir.

Bu yaklaşım hassas bilgileri korur ve formu daha anlaşılır hâle getirir. Bir müşterinin görüşmeyi başlatmak için firmanın çakışma inceleme sürecini anlaması gerekmez.

İş akışını oluşturmadan önce görüntüleme yetkilerini belirleyin:

• Talep gönderenler talep oluşturabilir ve kendi taleplerinin durumunu görebilir.
• Talep ekibi ayrıntıları düzeltebilir, eksik bilgi isteyebilir ve talepleri yönlendirebilir.
• Çakışma incelemecileri taraf adlarını görebilir ve iç not ekleyebilir.
• Uygulama liderleri bütçeleri, kapasite ayrıntılarını ve onay kararlarını görebilir.
• Teslimat ekipleri onaylanan işi ve başlamak için gereken bilgileri görebilir.

Erişim kuralları, firmanın gizli işleri nasıl ele aldığını yansıtmalıdır. Bir incelemecinin müşteri ve karşı taraf adlarına ihtiyacı olabilir, ancak önerilen ücreti görmesi gerekmeyebilir. Teslimat ekibinin imzalanan kapsamı görmesi gerekebilir, fakat çakışma notlarını görmemelidir.

Her aşamaya bir sorumlu atayın

Birden fazla kişi yardımcı olabilse de her aşamaya tek bir sorumlu atayın. Sorumlu kişi hatırlatmaları almalı ve talebi ilerletmeli, daha fazla bilgi için geri göndermeli veya kapatmalıdır. Ortak sorumluluk çoğu zaman işlerin sahipsiz kalmasına yol açar.

Basit bir akışta tamamlık kontrollerinden talep koordinatörü, incelemeden çakışma ekibi, onaydan uygulama lideri ve devir sürecinden proje yöneticisi sorumlu olabilir. Talebin hem mevcut aşamasını hem de adı belirlenmiş sorumlusunu kaydedin.

AppMaster, ekiplerin müşteri talep iş akışını genel bir form yerine kendi gerçek karar süreçlerine göre oluşturmasına yardımcı olmak için rolleri, izinleri ve devirleri görsel olarak modelleyebilir.

Toplanacak proje bağlamını seçin

Kullanışlı bir talep uygulaması, talebe dair net bir tabloyla başlar. Form, ekibe kimin incelemesi gerektiğine, işin ne kadar acil olduğuna ve sonraki adımın ne olması gerektiğine karar verecek kadar ayrıntı sağlamalıdır. Yeni bir potansiyel müşteriden firma yardım etmeyi kabul etmeden önce kapsamlı bir brif hazırlamasını istememelidir.

İşe, çalışmayı tanımlayan alanlarla başlayın: müşteri kuruluşu, proje adı ve talep edilen hizmet. Bir kişi başvuru yapsa bile şirket adı önemlidir. Çünkü ekip bu sayede ilişkili talepleri bir araya getirebilir ve çakışma kontrol sürecini başlatabilir. Hizmet türleri için kısa bir liste sunun ve listede yer almayan işler için «Diğer» seçeneği ekleyin.

Sorunun sade bir dille açıklanmasını isteyin. «Neye ihtiyacınız var ve hangi sonucu bekliyorsunuz?» gibi bir soru, «Proje ayrıntıları» başlıklı büyük bir kutudan genellikle daha iyi yanıtlar alır. Yanıt, yakın bir lansman tarihini, düzenleyici bir sorunu veya birkaç bölgede yürütülecek çalışmayı ortaya çıkarabilir.

Zamanlamayı ve kapsamı erkenden toplayın

Tarihler personel planlamasını ve yanıt önceliklerini etkiler. İstenen başlangıç tarihini, kesin son tarihi ve basit bir aciliyet seçeneğini toplayın. «En kısa sürede» gibi belirsiz seçeneklerden kaçının. «48 saat içinde», «bu hafta» veya «sabit bir son tarih yok» gibi herkesin aynı şekilde yorumlayabileceği seçenekler kullanın.

Konum, atanacak ekibi, seyahat ihtiyacını, geçerli kuralları veya teslimat biçimini etkileyebilir. Önemli olduğu durumlarda proje konumunu sorun. Ardından beklenen çıktıları sade ifadelerle toplayın: yazılı görüş, atölye çalışması, başvuru, uygulama planı, sürekli destek veya üzerinde anlaşılmış başka bir çıktı.

Pratik bir proje talep formunda genellikle şu alanlar bulunur:

• Müşteri kuruluşu ve proje adı
• Talep edilen hizmet ve kısa özet
• İstenen başlangıç tarihi, son tarih ve aciliyet
• İlgili konum veya yargı alanı
• Beklenen çıktılar ve bilinen kısıtlar

Zorunlu alanları en aza indirin

Her zorunlu alan ek bir sürtünme yaratır. Bir alanı yalnızca ekip talebi yönlendiremiyor veya değerlendiremiyorsa zorunlu yapın. Müşteri kuruluşu, talep edilen hizmet, özet ve iletişim yöntemi çoğu zaman bu ölçütü karşılar. Ayrıntılı kapsam, belgeler, bütçe ve dahili referans numaraları genellikle zorunlu olmamalıdır.

Potansiyel bir müşteri, bir çalışan anlaşmazlığı konusunda yardıma ihtiyacı olduğunu biliyor olabilir; ancak kesin çıktıyı veya son tarihi bilmiyor olabilir. Temel bilgileri göndermesine izin verin. Talep sahibi, aşırı katı bir form nedeniyle talebi kaybetmek yerine eksik ayrıntıları kısa bir takip görüşmesinde toplayabilir.

AppMaster ile ekipler koşullu alanlar kullanabilir. Uygulama, konumları yalnızca seçilen hizmet için önemli olduğunda sorabilir veya talep sahibi konuyu acil olarak işaretlediğinde son tarihin neden acil olduğunu sorabilir. Böylece form kısa kalırken incelemeciler ihtiyaç duydukları bağlamı alır.

Müşteri kişilerini taleple bağlantılı tutun

Bir talep nadiren yalnızca bir kişiden gelir. İlk e-posta operasyon yöneticisinden gelebilir; finans lideri işi onaylayabilir ve bölüm başkanı nihai kararı verebilir. Bu kişileri gelen kutularına ve notlara dağıtmak yerine aynı talebe bağlayın.

Birincil kişiyle başlayın. Ad soyad, iş e-postası, telefon numarası, görev unvanı ve tercih edilen iletişim yöntemini toplayın. Çalışanlar geri aramadan önce eski mesajları aramak yerine bu ayrıntıları talep kaydının üst kısmında görebilmelidir.

Her kişinin rolünü kaydedin

Görüşme ilerledikçe çalışanların kişi eklemesine izin verin. Her kişi hem kuruluşa hem de proje talebine bağlanmalıdır.

Yararlı etiketler şunlardır:

• Ana kişi veya günlük koordinatör
• Kapsam ya da zamanlamadan sorumlu karar verici
• Faturalama kişisi
• Erişim veya gereksinimler için teknik kişi
• Sözleşmeler için hukuk veya satın alma kişisi

Bu etiketler, onay yetkisi olmayan birine teklif gönderme veya yalnızca toplantı talep eden kişiye fatura gönderme gibi yaygın devir hatalarını önler. Bir kişi birden fazla role sahip olabilir; gerektiğinde birden fazla etikete izin verin.

Örneğin operasyon direktörü Maya bir projeyi anlatırken bütçeyi onaylayacak CFO'yu ve sistem sorularını yanıtlayacak BT yöneticisini belirtebilir. Bu üç kişiyi tek bir talep altında kaydetmek, iş ilerlediğinde finans ekibinin ve proje liderinin doğru kişilere ulaşmasını sağlar.

Yeni kayıt oluşturmadan önce kuruluşu kontrol edin

Çalışanlardan yeni kayıt oluşturmadan önce kuruluşu aramalarını isteyin. Şirket adı, e-posta alan adı ve mümkünse telefon numarası üzerinden eşleştirme yapın. Böylece «Acme Ltd» ve «Acme Limited» gibi küçük farklılıkların tek bir müşteriyi iki kayda bölmesi önlenir.

Kuruluş zaten varsa yeni talebi ona bağlayın ve kişilerin güncel olduğunu doğrulayın. Kuruluş yoksa onu bir kez oluşturun ve başvuru kaynağını kaydedin. Bu, müşteri talep iş akışını daha düzenli tutar ve geçmiş işleri, açık talepleri ve kişi geçmişini bulmayı kolaylaştırır.

AppMaster'ın Data Designer aracı, kuruluşları, kişileri ve talepleri birbirine bağlı kayıtlar olarak modelleyebilir. Çalışanlar, ilk taleple olan bağlantıyı kaybetmeden web veya mobil form üzerinden kişi ekleyebilir.

Takip edilebilir bir çakışma incelemesi oluşturun

Bir çakışma kontrolü, tek bir metin kutusundan ve e-posta zincirinden fazlasını gerektirir. Talep uygulaması, incelemecilerin yeni bir talebi mevcut ve geçmiş çalışmalarla karşılaştırabilmesi için yeterli bağlam sağlayacak isimleri toplamalıdır.

Potansiyel müşteriyi, ilişkili kuruluşları, ana kişileri, biliniyorsa karşı tarafları ve iş ya da proje adını sorun. Ana şirket, eski yönetici veya ortak girişim gibi sıra dışı ilişkiler için kısa bir serbest metin alanı ekleyin.

Çakışma bilgilerini genel talep ayrıntılarından ayrı tutun. Çakışma kayıtları, proje açıklamalarından veya bütçe aralıklarından daha sıkı erişim gerektirir. Bu kayıtları kontrolleri yapan ve onay kararlarını veren kişilerle sınırlayın.

İnceleme durumunu görünür kılın

Her talebe, inceleme ilerledikçe değişen görünür bir durum verin. Çalışanların sırada kimin olduğunu bilmesi gerekiyorsa «İnceleniyor» gibi belirsiz etiketlerden kaçının.

• Beklemede: Talep, incelemecinin başlayabileceği kadar bilgi içeriyor.
• Çakışma yok: İncelemeci, işi engelleyen bir çakışma bulmadı.
• Takip gerekiyor: İncelemeci daha fazla bilgi veya onay bekliyor.
• Engellendi: Firma, çakışma kuralları nedeniyle talebi kabul edemez.

Talep sahibinin hassas arama sonuçlarına erişmesi gerekmez. Talebin ilerleyip ilerleyemeyeceğini, daha fazla bilgi gerekip gerekmediğini veya durması gerektiğini bilmesi gerekir. Uygulama, iç notları kısıtlayıp müşteriye basit bir durum gösterebilir.

Kısa bir karar kaydı bırakın

Her karar, incelemecinin adı, tarih, durum ve sade bir gerekçeyle kalıcı bir kayıt oluşturmalıdır. Örneğin: «14 Mayıs'ta J. Patel tarafından çakışma yok olarak işaretlendi. Bir bağlı kuruluşla ilgili önceki çalışma 2022'de sona ermiş, güncel bir karşı taraf işi bulunamadı.»

Bu kayıt, proje lideri talebin neden durduğunu sorduğunda veya başka bir incelemeci süreci devraldığında zaman kazandırır. Gerekçeyi kısa ve nesnel tutun. Çakışma kontrolü kararı açıklamalı, ikinci bir dosyaya dönüşmemelidir.

Bir iş akışı kuralını netleştirin: durum «Çakışma yok» olmadan çalışanlar teslimat işini atayamamalı, müşteri çalışma alanı açamamalı veya faturalandırılabilir işe başlayamamalıdır. Bir incelemeci «Takip gerekiyor» seçerse uygulama talebi, örneğin bir marka adının arkasındaki tüzel kişiyi sorma gibi belirli bir soruyla geri göndermelidir.

AppMaster bunu kısıtlı erişimli bir çakışma tablosu, role dayalı erişim ve her talebi doğru incelemeciye yönlendiren görsel Business Process Editor ile destekleyebilir.

Talebi teklife dönüştürmeden bütçeyi sorun

Bütçe sorusu, çalışanların bir talebin firmanın genellikle kabul ettiği işlere uyup uymadığını anlamasına yardımcı olur. Bu soru bir fiyat vaadi içermemelidir. İlk talep aşamasında saatleri, kapsam değişikliklerini, uzman desteğini veya son tarih baskısını tahmin etmek için genellikle yeterli ayrıntı bulunmaz.

Firmanın kabul ettiği işlere uygun aralıklar kullanın. Bir danışmanlık firması «10.000 $ altı», «10.000 ila 25.000 $», «25.000 ila 75.000 $» ve «75.000 $ üzeri» seçeneklerini sunabilir. Müşterinin hızlıca yanıtlayabileceği kadar geniş aralıklar seçin.

Alanı açıklayan kısa bir not ekleyin: «Bu aralık, talebinizi doğru ekibe yönlendirmemize yardımcı olur. Teklif veya ücret sözleşmesi değildir.» Müşteri bütçe düzeyini belirtebilir, firma da işi yine gerektiği gibi değerlendirebilir.

Dış harcamalar çalışmayı sık sık etkiliyorsa bütçenin yalnızca firma ücretlerini mi yoksa dış masrafları da mı kapsadığını sorun. Bu masraflar başvuru ücretlerini, seyahati, uzman yüklenicileri, yazılımları veya diğer tedarikçileri içerebilir.

Tahmini aralığı, gerekiyorsa para birimini, bütçe onay durumunu ve limitler ya da satın alma kurallarıyla ilgili notu toplayın. Çalışanların ayrıntılı tahmin gerektiren talepleri işaretleyebilmesi de gerekir. Örneğin bir potansiyel müşteri en yüksek aralığı seçip geniş ve tanımsız bir proje anlattığında talep koordinatörü «Tahmin gerekli» seçeneğini işaretleyebilir.

İlk bütçe yanıtını müşteri talep iş akışında tutun, ancak nihai teklifi ayrı bir kayda kaydedin. Talep yanıtı erken niyeti gösterir. Teklif ise üzerinde anlaşılmış kapsamı, varsayımları, oranları, maliyetleri ve onayı kaydeder. Bunları karıştırmak, ilk görüşmeden sonra kapsam değiştiğinde karmaşaya yol açar.

Talep akışını adım adım kurun

Net bir talep uygulaması, her talebi aynı küçük kararlar dizisinden geçirmelidir. Çalışanlar talebin kime ait olduğunu, neyin incelenmesi gerektiğini ve ne zaman harekete geçileceğini görebilmelidir.

Bir talep kaydıyla başlayın

Her potansiyel iş için bir kayıt oluşturun. Referans numarasını, müşteri veya kuruluş adını, talep edilen hizmeti ve talep sahibini ekleyin. İlk durumu «Yeni» olarak belirleyin. Böylece ekip incelenmemiş işleri aktif taleplerden ayırabilir.

Gerçek karar noktalarını anlatan durumlar kullanın:

• Yeni: Firma talebi aldı, ancak henüz kimse incelemedi.
• İnceleniyor: Bir kişi kapsamı, kişileri ve çakışmaları kontrol ediyor.
• Müşteri bekleniyor: Ekip eksik ayrıntıları bekliyor.
• Onaylandı: Firma teklif hazırlayabilir veya projeyi açabilir.
• Reddedildi: Firma işi üstlenmeyecek.

Listeyi kısa tutun. Çalışanlar birkaç saniye içinde bir durum seçemiyorsa etiketlerin üzerinde çalışılması gerekir.

Yönlendirin, atayın ve bildirim gönderin

Bir kişi talebi oluşturduktan sonra, daha önce toplanan ayrıntıları kullanarak talebi yönlendirin. Vergi talebi vergi yöneticisine, çalışanlarla ilgili bir konu ise başka bir incelemeciye gönderilebilir. Birden fazla ofisi olan firmalar talepleri konuma göre de yönlendirebilir.

İncelemeciye bir son tarih verin ve sonraki adım için adı belirli tek bir kişi atayın. Ortak ekip gelen kutusu görünürlük sağlar, ancak sorumluluk oluşturmaz.

Bildirimler her zaman «Çakışma incelemesini tamamla» veya «Bütçe ayrıntılarını iste» gibi bir eyleme yönlendirmelidir. Yeni bir atama olduğunda incelemeciyi, son tarih geçtiğinde ise talep koordinatörünü bilgilendirin.

Onaylanan işi sonraki sürece aktarın

Firma bir talebi onayladığında daha önce toplanan bilgileri koruyun. Kişi listesi, proje özeti, bütçe aralığı ve inceleme notları teklif veya aktif proje kaydına aktarılmalıdır. Çalışanlar aynı bilgileri başka bir forma yeniden yazmak zorunda kalmamalıdır.

AppMaster gibi kodsuz bir platform, bu akışı talep formu, durum alanları, iş kuralları ve role dayalı ekranlarla oluşturabilir. Devir süreci otomatik olarak teklif kaydı oluşturup sorumlusunu atayabilir; ilk talep kaydı da onay geçmişini korur.

Akışı müşterilerle paylaşmadan önce gerçekçi taleplerle test edin. Eksik bilgileri olan, olası çakışma içeren ve onaylanan birer talep ekleyin. Bu örnekler belirsiz durumları, eksik yönlendirme kurallarını ve yanlış kişiye gönderilen bildirimleri ortaya çıkarır.

Örnek: ilk temastan devre kadar bir talep

Bir danışmanlık firması, Northline Foods'un operasyon direktörü Maya Chen'den bir e-posta alır. Şirketi bölgesel olarak büyümeyi planlamaktadır ve yeni pazarları, tedarikçileri ve işletme maliyetlerini değerlendirmek için yardım istemektedir. E-postayı farklı kişilere yönlendirmek yerine koordinatör tek bir talep kaydı açar.

Koordinatör Maya'yı ana kişi olarak ekler, ardından harcamaları onaylayacak Northline finans yöneticisini ve günlük soruları yönetecek proje yöneticisini ekler. Talep formu büyüme bölgesini, iş hedefini, planlanan lansman tarihini ve ilk kısıtları toplar. Maya hedef tarih olarak 30 Eylül'ü, 75.000 ila 100.000 $ arasında bir çalışma bütçesini belirtir ve firmanın ilk öneriyi dört hafta içinde sunması gerektiğini not eder.

Herhangi biri keşif görüşmesi planlamadan önce uygulama talebi bir çakışma incelemecisine gönderir. İncelemeci, aynı bölgedeki rakip gıda distribütörleri, tedarikçiler ve pazara giriş projeleriyle ilgili mevcut ve yakın tarihli müşteri çalışmalarını kontrol eder. Sonucu ve çalışmaya getirilen sınırlamaları talep kaydına ekler.

İncelemeci talebi onaylarsa koordinatör durumu «Keşfe hazır» olarak değiştirir. İncelemeci hukuk veya yönetim desteğine ihtiyaç duyarsa talep uygun inceleme durumunda kalır ve ekip görüşmenin neden planlanmadığını görebilir. Böylece hevesli bir satış görüşmesi çakışma kontrol sürecinin önüne geçmez.

Koordinatör daha sonra perakende ve tedarik zinciri büyümesi konusunda deneyimli bir uygulama lideri atar. Lider, müşteri kişileri, istenen sonuç, son tarih, bütçe aralığı ve çakışma kararı dahil olmak üzere talebin tamamını alır. Keşif görüşmesinden sonra lider aynı kaydı kapsam notları ve teklif kararıyla günceller.

AppMaster ile oluşturulan bir uygulama, formu, inceleme durumunu, atamaları ve takip çalışmalarını e-posta zincirleri ile elektronik tablolara bölmek yerine tek bir kodsuz uygulamada tutabilir.

Kaçınılması gereken yaygın talep hataları

Bir talep uygulaması ilk incelemeyi kolaylaştırmalı, ikinci bir işe dönüştürmemelidir. Sorunların çoğu belirsiz sorulardan, yetkinin net olmamasından veya gönderildikten sonra kaybolan taleplerden kaynaklanır.

Çok erken aşamada fazla bilgi istemek

Uzun serbest metin alanları yavaş ve tutarsız incelemelere yol açar. Çalışanların hizmet türüne, aciliyete, sektöre veya beklenen başlangıç tarihine ihtiyacı varsa mümkün olduğunda kısa bir liste sunun. Seçeneklere uymayan ayrıntılar için isteğe bağlı tek bir not alanı bırakın.

Hizmet kategorisi, iş türü, son tarih, bütçe aralığı ve kısa özet, incelemecilere tek bir geniş sorudan daha düzenli bir başlangıç sağlar. Müşteri talep iş akışı, firma talebin uygun olduğunu gördükten sonra takip ayrıntılarını toplayabilir.

Kararları sorumlusuz bırakmak

Her yeni talebe incelemesi, ilerletmesi veya firmanın işi neden üstlenmeyeceğini açıklaması gereken adı belirli bir kişi atayın. Uygulama bu kişinin adını ve mevcut durumu göstermelidir.

Çakışma kararları daha sıkı kontrol gerektirir. Ekip üyeleri olası çakışmaları işaretleyebilir ve ilgili kişileri ekleyebilir; ancak yalnızca yetkili incelemeciler çakışma olmadığını onaylamalı, talebi reddetmeli veya daha fazla bilgi istemelidir. Kararı, incelemeciyi, tarihi ve notları kaydedin.

Gönderilmiş bir proje talep formunu onaylanmış iş olarak görmeyin. Gönderim, firmanın bilgileri aldığı anlamına gelir. Onay için çakışma incelemesi, kapsam görüşmesi ve gerekli iç kontrollerin ardından ayrı bir durum değişikliği gerekir.

Eski soruları sonsuza kadar tutmak

Her yeni soru makul göründüğü için formlar büyümeye eğilimlidir. Birkaç ay sonra form uzar ve insanlar alanları atlamaya veya aceleyle yanıtlamaya başlar. Alanları, talepleri değerlendiren ve devirden sonra verileri kullanan kişilerle birlikte düzenli olarak gözden geçirin.

Karar vermek, işi yönlendirmek, çakışmaları kontrol etmek veya teklif hazırlamak için kimsenin kullanmadığı soruları kaldırın. Bir alan yalnızca tek bir uygulama alanı için geçerliyse talep sahibi o alanı seçtiğinde gösterin. AppMaster, diğer herkes için ekranı sade tutan koşullu akışları destekler.

Net sorumluluğa sahip kısa bir form, insanların aceleyle doldurduğu ayrıntılı bir formdan daha iyi bilgi üretir.

Yayına almadan önce hızlı kontroller

Talep uygulamasını firma genelinde paylaşmadan önce formun bilinçli bir ilk inceleme için yeterli bağlamı topladığını doğrulayın: müşterinin ihtiyacı, hizmet alanı, ilgili konum veya yargı alanı, zamanlama, bütçe aralığı ve ana kişinin ayrıntıları.

Bir test talebi açın ve onu bir incelemeci gibi takip edin. Çakışma kontrol sürecinde görünür bir durum, adı belirli bir incelemeci ve kaydedilmiş bir karar bulunmalıdır. Her talebin ayrıca bir güncel sorumlusu ve son tarihi olmalıdır. İş geliştirmeden uygulama liderine veya teslimat ekibine geçerken sorumlu değişebilir, ancak uygulama her zaman sıradaki kişinin kim olduğunu göstermelidir.

Birden fazla kişi, yakın bir son tarih, olası bir çakışma ve eksik bütçe içeren gerçekçi bir test senaryosu kullanın. Uygulamanın talebi doğru incelemeciye gönderdiğini, çakışma onayından önce devri engellediğini ve notları aynı kayıtta tuttuğunu kontrol edin. Çalışanlardan akışı denemelerini isteyin, ardından kafa karıştıran etiketleri ve gereksiz alanları düzeltin.

Temel bir proje talep formundan fazlasına ihtiyaç duyan bir talep uygulaması için AppMaster, formlar, iş kuralları ve web veya mobil erişim sunan tek bir kodsuz çalışma alanı sağlar. Ekipler talep ve kişi kayıtlarını modelleyebilir, görsel Business Process Editor ile inceleme adımları oluşturabilir ve ayrı elektronik tabloları sürdürmeden uygulama üretebilir.

Ekibinizin tutarlı biçimde izleyebileceği en küçük akışla başlayın. Alanları ve kuralları yalnızca bunların bir kararı veya sonraki eylemi nasıl etkilediğini çalışanlar açıklayabiliyorsa ekleyin.